中到大值的键值存储答案

【问题标题】：Key-value stores for medium to large values中到大值的键值存储
【发布时间】：2011-11-18 13:50:20
【问题描述】：

我们有一个系统可以存储（个位数）数百万张图像，大小从 8KB 到 500KB 不等，中位数约为 15KB，平均为 30KB。总数据集目前约为 100GB。我们希望根据图像的哈希值访问图像（这个可以改变，但它需要可以从图像中计算出来，以便有效地检查图像是否已经在数据存储中— 图像被处理，使得两个图像是逐像素相同的，如果它们是逐字节相同的）。坚持（显然）很重要。

目前我们将它们全部存储为一个目录中的文件——目录列表被内核缓存，实际的文件读取是根据需要完成的。据我了解，键值存储（与使用文件系统相比）的主要优点是读取较小的值，因为可以缓存整个页面，而不仅仅是单个值。当前所有访问都来自与数据位于同一服务器上的 Web 服务器（在 Intranet 上），尽管我们可能会检查是否存在来自远程机器的密钥（主要通过 10GbE 连接）。

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

给定一个工作负载，其读取主要是（单次）按插入顺序读取和随机（尽管很可能重复）访问任意键，此外还有频繁的写入（大约 1:10 的写入：读取），从文件系统迁移到键值存储可能有很多优势吗？

【问题讨论】：

这取决于您当前的系统。如果它是单片的（单台机器服务来自单个存储位置的请求），您可能会看到通过添加多个节点并将数据副本存储在更靠近使用它的客户端的好处。要确定答案，您必须详细说明当前系统的组成以及需要补救的当前瓶颈。
2KB 文件与 10MB 文件完全不同。元数据开销/目录开销。从磁盘读取 2KB 文件更容易限制元数据和限制搜索，而 10 MB 文件主要时间是实际流式传输。你能多说一下文件大小分布吗？小文件是标准文件还是中文件？
查看 Microsoft Sharepoint 以了解此类工作，它可能会满足您的需求。在这种情况下，没有必要重新发明轮子

标签： image storage key-value key-value-store

【解决方案1】：

总结：为了满足您对数据完整性、持久性、大小和速度的要求，我推荐 Redis。

一个不错的介绍可以在这里看到：
https://simonwillison.net/static/2010/redis-tutorial/

n.b.更多信息会有所帮助，但根据您提供的信息以及我所知道的，以下是一些主要参与者：

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。
- ? 可以使用 Google + ;)

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

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

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

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

卡桑德拉：
https://cassandra.apache.org/
Apache Cassandra 具有容错性和分散性，并在 Netflix、Twitter 和 Reddit 等中使用。
+ 集群和复制。
- 更多设置知识需要。

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

【讨论】：

【解决方案2】：

视情况而定

文件数
如何在 FS 上构建它们
您使用的是哪个 FS
您使用的是哪种存储方式

您最终可能会用完 inode，或者再次访问文件的时间可能很慢（例如，如果您在单个目录中放置了太多条目）。

您还必须小心以原子方式访问文件（和/或创建目录），而 KV 存储通常会为您处理这些问题。

过去，我在使用 fs-as-key-value-store 方法时遇到了所有这些问题：)。

但可以做到，例如Bigdis，它是redis KV 协议的一个实现，来自redis 作者自己的files-on-disk，但是你必须小心你的操作。

根据您的问题，您可能会发现 MogileFS 或直云 S3 是更好的解决方案。

【讨论】：

【解决方案3】：

您提供的信息太少，无法给出具体答案 - 因此只是与您描述的内容相关的一些方面：

数据完整性
这可以是任何东西 - 即应禁止未经授权的数据更改和/或至少应检测到任何此类事件......或者它可以只是“RAID和/或备份......”领域中的东西。
“相同图像”
图像文件包含多个元数据字段/区域...如果一个具有元数据而另一个没有（或某些元数据字段不同），您的方法会导致看到两个逐像素相同的图像不同...这就是您想要的?
该领域的另一个方面是文件格式（PNG 与 BMP 与 JPEG 等）和压缩...相同的图像和不同的格式和/或压缩算法（甚至像 ZIP 与 LZW 之类的无损算法，JPEG 等更糟）可能导致将相同的图像归类为不同的图像 - 这是您想要的吗？
“数十万张图像”和“2 KB - 10 MB”
这并没有说太多......即中位数与平均图像/文件大小是多少？
访问
对这些文件/图像的访问是否已分发（如在 CDN 中）？还是基于局域网？

还有许多其他方面与您描述的内容相关......

如果没有任何进一步和真正具体的信息，我认为任何统计数据/基准/建议充其量都是幸运的。

可能的解决方案包括分布式系统（可以是基于文件系统/内存/DB）和/或基于 SSD 和/或 RAID 和/或 SAN 等的存储。

您感兴趣的“KeyValueStore”点可能是相关的，但在大多数情况下，处理我遇到的此类商店的大量图像不会添加任何独特功能（在某些情况下甚至会受到伤害）。

【讨论】：

数据完整性真的太模糊了，我必须同意：我唯一担心的是从键值存储中取出的数据与放入的数据相同问题中提到了相同的图像（它们经过处理，因此它们是逐像素相同的，它们是逐字节相同的）。否则，问题现在解决了剩下的问题。
@gsnedders 感谢您提供的附加信息...即使有数百万张图片，我也不知道 KeyValueStore 会带来什么好处...您对 KeyValueStore 的期望是什么？跨度>

【解决方案4】：

如果您的数据小于 1TB，则您可能不需要高可用性 NoSQL 数据库，并且大多数 NoSQL 数据库都要求将数据保存在 RAM 中。我是否可以建议使用沼泽标准关系数据库并使用哈希作为主键并使用您的数据创建一个 blob 表？您会惊讶于它的性能有多好，而且您不必担心 inode 会用完。

如果您的数据是文本/可压缩的，则关系数据库会更好。根据我的经验，很少有 NoSQL 数据库会为您压缩数据，您必须在客户端进行压缩。但 MySQL/MariaDB 提供透明压缩。

另一个选择是 RocksDB。对于某些用例，它非常适合磁盘空间，因为它支持使用自定义字典进行 zstd 压缩。

【讨论】：