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

Question

我需要存储数十万（现在，可能有数百万）文档，这些文档从空开始并经常附加，但从不更新或删除。这些文档不以任何方式相互关联，只需要通过一些唯一的ID进行访问。

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

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

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

理想情况下，我希望存储解决方案能够轻松实现横向扩展，并在服务器之间实现冗余（例如，每个文档至少存储在3个节点上），并且可以轻松恢复崩溃的服务器。

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

良好存储解决方案的任何输入？

Answer 1

听起来像HBase（Over HDFS）要解决的理想问题。

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

Answer 2

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

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

Answer 3

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

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

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

如果节点无法访问或文件不存在，则负载平衡可能会“故障转移”到下一行。如果读/写代码遵循该目录，则根目录也可以脱机标记为计划中断。同样也可以用于分区，其中x个根目录服务于奇数id，而x号服务甚至id作为一个简单的例子。

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

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

Answer 4

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

MongoDB 的一些有用点。

  

理想情况下，我希望存储解决方案能够轻松实现横向扩展，并在服务器之间实现冗余（例如，每个文档至少存储在3个节点上），并且可以轻松恢复崩溃的服务器。

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

对于水平可伸缩性，MongoDB支持sharding。分片有点复杂，但是可以像你期望的那样工作，在多台机器（或多个副本集）之间分割写入。

  

我需要存储数十万（现在，可能有数百万）文件，这些文件从空开始并经常附加

有几家公司让Mongo在生产中运行了数十亿份文件。

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

  

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

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

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

Answer 5

检查我们的SolFS虚拟文件系统。它适用于您的条件。