在MongoDB中存储非常大的文档
简而言之：如果您有大量不同大小的文档，其中相对较少的文档达到最大对象大小，那么在MongoDB中存储这些文档的最佳实践是什么？
我有一套文件，比如：
{_id: ...,
values: [12, 13, 434, 5555 ...]
}
值列表的长度因文档而异。对于大多数文档，它将有几个元素，对于少数文档，它将有数千万个元素，我将达到MongoDB中的最大对象大小限制。问题是，我为那些非常大（而且相对较少）的文档提出的任何特殊解决方案都可能会对我存储小文档的方式产生影响，否则，这些小文档将在MongoDB集合中愉快地生活。
在我看来，我有以下几种选择。如果您能提供这些建议的利弊，以及我错过的任何其他选择，我将不胜感激。
1）使用另一个数据存储：这似乎太激烈了。我喜欢MongoDB，这并不像我达到了许多对象的大小限制。在案例中，我的应用程序可以对非常大的对象和其他对象进行不同的处理。它看起来并不优雅。
2）使用GridFS存储值：就像传统数据库中的Blob一样，我可以将前几千个元素的值保存在文档中，如果列表中有更多的元素，我可以将其余的元素作为二进制文件保存在GridFS对象中。我不能在这个部分搜索，但我可以忍受。
3） 滥用GridFS：我可以将所有文档保存在GridFS中。对于大多数（小）文档，二进制块将是空的，因为files集合将能够保存所有内容。剩下的我可以将多余的元素保留在chunks集合中。与选项2相比，这会带来开销吗？
4） 真正滥用GridFS：我可以使用GridFS的files集合中的可选字段来存储值中的所有元素。GridFS是否也为文件集合执行智能分块？
5）使用一个额外的关系集合来存储一对多关系，但是这个集合中的文档数量很容易超过1000亿行。
共有1个答案
如果您有大型文档，请尝试在MongoDB中存储一些关于它们的元数据，并将其余数据（您将不会查询的部分）放在外部。
-
问题内容： 我需要在MySQL表中存储大量（数千万）的512位SHA-2哈希。为了节省空间，我想以二进制形式存储它们，而不是以十六进制数字的字符串存储。我使用的是ORM（DBix :: Class ），因此将从代码中抽象出存储的特定详细信息，从而可以将它们扩充到我选择的任何对象或结构中。 MySQL的类型是64位。因此，我可以从理论上将散列划分为八列。不过，这似乎很荒谬。我的其他想法只是使用单个列
-
我正在使用Java开发一个web应用程序，在这里我有一个方法可以读取。使用apache poi的xlsx文件： 该方法工作正常，但是该方法处理具有数千行记录的文件的可能性有多大，例如，大约2530万行。当处理一个大文件时，我采取以下异常： 我需要知道如何避免这种错误。例如，如果有，请读取并处理该文件。xlsx 1000至1000线，或其他解决方案。
-
问题内容： 我将MongoDB与本机节点驱动程序一起使用，需要准确存储可能大于int最大值2147483647的数字。在跟踪使用情况时，我将需要能够增加数字。我有什么选择？ 我正在用猫鼬。我遇到的问题是，当我过去2147483647时，它会将数字转换为双精度。如何强制Mongoose使用64位long int ？ 我的架构如下所示 我的样子是这样 问题答案： 您现在可以使用该插件在Mongoose
-
问题内容： 我有一个非常大的文本文件（45GB）。文本文件的每一行包含两个空格分隔的64位无符号整数，如下所示。 4624996948753406865 10214715013130414417 4305027007407867230 4569406367070518418 10817905656952544704 3697712211731468838 … … 我想读取文件并对数字进行一些操作。
-
我刚刚注意到，我的应用程序的存储在过去的几周内几乎达到了5GB的免费使用限制。经过更多细节的检查，似乎这是“神器”桶造成的。 我看到了这个SO问题，它说“工件”桶与节点10环境相关。 我确实在一个月前移动到了节点10，但在发现日志不再在firestore functions console中进行结构化之后，几天后我又回到了节点8，并且从那以后只使用节点8。 我还使用了函数，以备此处所需。 我还注意
-
我搜索了数据库和食谱，但似乎找不到正确的答案。我有一个非常简单的python代码，它总结了一个范围内的自我权力。我需要这个非常非常大的数字的最后十位，我已经尝试了get上下文（）. prec，但是我仍然达到了极限。 代码如下： 我怎么能看到这些美丽的数字？它在我的四核上打印速度相对较快。这只是为了给ProjectEuler带来乐趣，问题#48，请不要破坏者。我不想要解决方案，也不想让工作为我完成，