在 MongoDB 或其他 DB 中存储 100Mb 文件和高效的交叉连接操作
Posted
技术标签:
【中文标题】在 MongoDB 或其他 DB 中存储 100Mb 文件和高效的交叉连接操作【英文标题】:Storing 100Mb files and efficient cross-join operation in MongoDB or other DB 【发布时间】:2016-06-24 11:57:15 【问题描述】:我参与的项目的一部分包括开发一个供内部使用的科学应用程序,处理大量文件(大约 20000 个),每个文件大小约为 100Mb。文件伴随着元信息,用于选择整个集合的子集。
更新 之后 阅读 回复 是的,处理位于单个服务器机房中。
应用程序选择这些文件的两个子集。在第一阶段,它单独处理每个文件,并独立地从一个文件中产生多达 30 个项目,用于第二阶段。每个生成的项目也存储在一个文件中,文件大小从 5 到 60Kb 不等。
在第二阶段,应用程序处理在第一阶段产生的所有可能的结果对,其中一对的第一个元素来自第一个子集,第二个 - 来自第二个 - 交叉连接或笛卡尔积两套。
第一个子集中的项目数量通常为数千,而第二个子集中的项目数量为数万。因此,第二阶段中所有可能的配对数量为数亿。
处理单个源 100Mb 文件的典型时间约为 1 秒,一对第一阶段结果 - 微秒。该应用程序不是用于实时处理的,它的一般用例是提交一个工作进行夜间计算并在早上获得结果。
我们已经有了一个应用程序的版本,该版本是较早开发的,当时我们的数据要少得多。它是用 Python 开发的,并使用 Python 库中的文件系统和数据结构。计算在 10 台 PC 上执行,连接自开发的软件,用 Twisted 编写。文件存储在 NAS 和 PC 的本地驱动器上。现在,应用程序的性能很差,尤其是在第二阶段和之后的结果聚合期间。
目前我正在寻找 MongoDB 来完成这项任务。不过,我对此类工具没有太多经验,欢迎提出建议。
我用 MongoDB 和 PyMongo 进行了一些实验,发现从数据库加载整个文件在千兆以太网上大约需要 10 秒。处理的最小块大小约为 3Mb,检索时间为 320 毫秒。从本地驱动器加载文件更快。
MongoDB 配置包含一个带路径的单行。
然而,数据库非常吸引人的特点是它能够存储元信息并支持对其进行搜索,以及自动复制。 这也是一个持久化的数据存储,因此意外停止后可以继续计算(目前我们必须重新开始)。
所以,我的问题是。
MongoDB 是一个正确的选择吗? 如果是,那么数据模型的指导方针是什么?
是否可以缩短文件的检索时间?
或者,像以前一样将文件存储在文件系统中,并将它们的路径存储在数据库中是否合理?
已在客户端 python 代码中创建了第二阶段所有可能对的列表,并且花费了相当长的时间(我没有测量它)。
MongoDB 服务器会做得更好吗?
【问题讨论】:
【参考方案1】:在这种情况下,您可以选择 sharded gridfs
作为 mongo 的一部分 more here
这将允许更快的文件检索过程,并且仍然具有元数据和文件记录。
仅使用副本集时加快速度的另一种方法是拥有一种逻辑平衡器,并一次从主服务器获取文件,另一时间从从服务器(或轮询之王方式中的其他从服务器)获取文件。
在文件系统中存储文件总是会更快一点,只要这是一个服务器机房(-> 在本地处理)- 我可能会坚持下去,但非常担心备份。
【讨论】:
感谢您的回复。我添加了有关交叉连接的详细信息。您能否也对它们发表评论。以上是关于在 MongoDB 或其他 DB 中存储 100Mb 文件和高效的交叉连接操作的主要内容,如果未能解决你的问题,请参考以下文章
Java Berkeley DB 读取性能与 100M 文档
如何从 mongo db 获取详细信息并在 nodejs Fork 方法中发送或存储在对象中
如何从 mongo db 获取详细信息并在 nodejs Fork 方法中发送或存储在对象中