适用于中到大值的键值存储

我们有一个系统存储(一位数)数百万张图像,大小从8KB到500KB不等,中位数大约为15KB,平均为30KB.总数据集目前约为100GB.我们希望基于图像的散列来访问图像(这可以被改变,但是它需要可以从图像计算以便检查图像是否已经有效地存在于数据存储中 - 处理图像使得两个如果它们是逐字节相同的,则像素是像素对像素相同的.持久性(显然)很重要.

目前我们将它们全部存储为目录中的文件 - 内核缓存目录列表,并根据需要进行实际的文件读取.据我了解,键值存储的主要优点(与使用文件系统为一体)是读取较小的值,因为整个页面可以缓存,而不是只有一个值.所有访问当前来自与数据在同一服务器上的Web服务器(在Intranet上),但我们可能会检查是否存在来自远程计算机的密钥(主要通过10GbE连接).

没有任何特别的理由来改变它,尽管随着系统的其他主要部分的改变,重新考虑当前的方法似乎是值得的.

给定一个工作负载,其读取主要是(单个)读取插入顺序和随机(但很可能重复)访问任意键,除了频繁写入(大小为1:10写入:读取),是否有可能从文件系统转移到键值存储是非常有利的吗？

简介:根据 您对数据完整性,持久性,大小和速度的要求,我推荐Redis.

这里有一个很好的介绍演示文稿:https:
//simonwillison.net/static/2010/redis-tutorial/

nb更多信息会有所帮助,但根据你给出的内容+我所知道的,这里有一些主要的参与者:

Memcached:
https ://memcached.org/
一个免费的,开源的,高性能的分布式内存对象缓存系统,适用于加速动态Web应用程序.
+适用于Web应用程序,免费,开源.
-如果服务器出现故障(memcached进程失败或系统重启),则所有会话都将丢失.较高(商业用途)级别的性能限制.

Redis:
https ://redis.io/
类似于memcached但具有数据持久性,支持多种值类型,具有原子递增/递减的计数器和内置密钥到期.
+将数据保存到磁盘,因此永远不会丢失,非常简单,速度,灵活性(键可以包含字符串,散列,列表,集和排序集),分片,由vmware而不是个人维护.
-有限的聚类.

LevelDB:
https ://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html
Google编写的快速键值存储引擎,它将字符串键映射到字符串值.
+谷歌.
-？可以使用Google +;)

TokoyoCabinet:
https ://fallabs.com/tokyocabinet/
包括对锁定,ACID事务,二进制数组数据类型的支持.
+速度和效率.
- 在某些领域鲜为人知,例如美国

Project Voldemort:
https ://project-voldemort.com/
一个用Java编写的高级键值存储.为更新提供多版本并发控制(MVCC).副本的更新是异步完成的,因此不保证数据的一致性.
+功能
-一致性

MongoDB:
https ://www.mongodb.org/
一个可扩展,高性能,开源,面向文档的数据库.用C++编写功能复制和高可用性,具有跨LAN和WAN的镜像以及自动分片功能.在Ruby on Rails社区中很受欢迎.
+易于安装,良好的文档,支持.
-相对较新.

Couch:
http ://www.couchdb.org/
类似于Mongo,针对文档数据库.
+复制,高级查询.
-群集,磁盘空间管理.

Cassandra:
https ://cassandra.apache.org/
Apache Cassandra具有容错性和分散性,可用于Netflix,Twitter和Reddit等.
+集群和复制.
-需要更多的设置知识.

由于时间不够,我无法提供所有参考资料,但希望这至少有帮助.

取决于

文件数量

你如何在FS上构建它们

你正在使用哪个FS

你正在使用什么样的存储空间

您可能最终耗尽inode,或者可能再次访问文件的速度很慢(例如,如果您在一个目录中放入太多条目).

您还必须小心谨慎地访问文件(和/或创建目录),而KV商店通常会为您处理.

过去我用fs-as-key-value-store方法遇到了所有这些问题:).

但是可以这样做,比如Bigis,这是redis KV协议的一个实现,就像redis作者本人一样,但是你必须对你的操作有点小心.

根据您的问题,您可能会发现MogileFS或直接混浊的S3是更好的解决方案.