增量附加文档的大规模存储？

Question

我需要存储数十万（现在，可能是数百万）文档，这些文档一开始是空的，并且经常被附加，但从未以其他方式更新或删除。这些文档没有任何关联，只需要通过某个唯一 ID 访问即可。

读取访问是文档的某个子集，它几乎总是从某个索引位置的中途开始（例如“文档 #4324319，将 #53 保存到末尾”）。

这些文档开始时非常小，只有几 KB。它们通常达到大约 500KB 的最终大小，但许多达到 10MB 或更多。

我目前正在使用 MySQL (InnoDB) 来存储这些文档。每个增量保存都只是转储到一个带有其所属文档 ID 的大表中，因此读取文档的一部分看起来像“select * from saves where document_id=14 and save_id > 53 order by save_id”，然后手动连接它全部在代码中。

理想情况下，我希望存储解决方案易于水平扩展，具有跨服务器的冗余（例如，每个文档存储在至少 3 个节点上），并且可以轻松恢复崩溃的服务器。

我已经将 CouchDB 和 MongoDB 视为 MySQL 的可能替代品，但我不确定它们中的任何一个对于这个特定的应用程序是否有很大的意义，尽管我愿意被说服。

关于一个好的存储解决方案有什么意见吗？

Answer 1

检查我们的SolFS 虚拟文件系统。它会在您的条件下运作良好。

Answer 2

好的，首先需要注意的是，MongoDB 确实对文档大小有限制。但是，最新版本将覆盖您的 10MB 大小。

MongoDB 的一些有用点。

理想情况下，我希望存储解决方案易于水平扩展，具有跨服务器的冗余（例如，每个文档存储在至少 3 个节点上），并且可以轻松恢复崩溃的服务器。

对于复制，MongoDB 支持replica sets。副本集是单主副本。如果主服务器宕机，系统会自动选择一个新的主服务器（容易恢复）。添加新节点就像启动新服务器并指向现有集合一样简单。

对于水平可扩展性，MongoDB 支持sharding。分片稍微复杂一些，但工作方式与您期望的一样，将写入拆分到多台机器（或多个副本集）。

我需要存储数十万（现在，可能是数百万）文档，这些文档一开始是空的，并且经常被附加到

几家公司让 Mongo 在生产中运行数十亿个文档。

Mongo 提供了一系列update modifiers，在“附加到”的情况下非常有用。特别是查看添加到数组末尾的 $push 运算符。应该正是您所需要的。

读取访问是文档的某个子集，它几乎总是从某个索引位置的中途开始（例如“文档 #4324319，将 #53 保存到末尾”）。

MongoDB 允许您仅返回选择字段（如预期的那样）。根据您的布局，您可以使用dot notation 仅检索某些子文档。如果您的更新是作为数组实现的，您还可以使用非常适合您上面列出的查询的$slice command。

所以我认为 MongoDB 可以满足您的所有基本需求。易于追加，易于查询这些追加，并且复制是内置的。您可以通过分片获得水平扩展（尝试首先从副本开始）

Answer 3

我的直接想法是为什么将这些存储在数据库中？在处理这么多文件时，将它们存储在数据库中会比文件系统带来更好的搜索性能吗？

我认为将这些存储在散列目录结构中的文件系统上会更好。您可以使用数据库仅存储元数据（根目录、文档 ID、保存 ID、相对于根的位置）。

根目录（节点）将是一个单独的表，可以在写入（枚举并写入所有位置）时使用，然后循环（或其他负载平衡算法）用于读取。

如果一个节点不可访问或文件不存在，负载平衡可以“故障转移”到下一个。如果读/写代码尊重这一点，也可以将根目录标记为离线以计划中断。同样也可以用于分区，其中 x 个根目录服务奇数 id，x 个服务偶数 id 作为一个简单的例子。

确保节点同步也可以使用元数据进行编码。

只需我的 2 美分，因为我以前从未处理过这么多文件。

Answer 4

你有什么理由需要数据库吗？

您描述了“存储具有唯一名称的文档的系统”，所以我开始考虑“文件系统”。也许像企业级文件服务器/s（我估计最多大约 200 TiB 的数据），其中唯一 ID 是网络上的目录和文件名。

Answer 5

听起来像是HBase（通过 HDFS）解决的理想问题。

缺点是学习曲线有些陡峭。