从处理许多小数据文件迁移到 ruby​​ 中的几个大文件

Question

在 ruby​​ 中从处理许多小数据文件迁移到几个大数据文件时，我应该记住什么？

背景：我是一名生物信息学家，正在处理下一代测序数据，每次运行产生大约一百万个序列。我之前将一百万个序列中的每一个都保存到了自己的文件中，并对每个序列进行了一些处理步骤，为每个序列生成了几个文件。不幸的是，拥有数百万个文件使文件输入和输出成为主要瓶颈（并且也使备份变慢）。 （answers to this question 也不鼓励拥有数百万个文件）

我考虑使用 sqlite 来存储每个文件，但我想尽可能避免使用此选项，以避免添加依赖项。

我怀疑我应该只编写一个模块来处理大文件，并让所有处理脚本（作为独立进程运行）在想要进行输入或输出时使用这个模块。为处理类提供使用 StringIO 创建的文件流可能对此很有用，因为这样他们就不需要知道大文件是如何工作的。

为了避免在获取输入时必须读取整个大文件（我希望每个序列的处理都是一个独立的过程，以便对一个序列的分析不会破坏对另一个序列的分析），我'我必须跟踪我在大输入文件中的位置。尽管存在更复杂的进程间通信技术，但我可能只使用一个临时文件来存储 IO#seek 的字符位置。

我还必须记住，如果多个进程正在写入同一个文件，我将无法同时运行多个进程，并且大文件处理程序需要定期刷新其输出。

Answer 1

我不知道你的情况的细节，但你描述的应用程序——我想存储一百万个东西，我想快速灵活地访问它们——对我来说听起来像一个数据库。通过避免使用 sqlite 之类的工具，您不一定会避免依赖关系；你可能会用一种依赖换另一种。

如果您确实必须推出自己的基于文件的解决方案，则不必从一个极端转向另一个极端。分散在 10 个子目录中的 1000 个中型文件呢？这些中等大小的文件可能是.tar 档案或类似的东西（伪装的目录），从您的代码的角度来看，它们的行为可能很像您习惯处理的 100 万个小文件。此外，这些.tar 文件仍可直接从命令行访问，无需任何特殊软件。

也许这些想法很疯狂，但如果您要避免使用数据库，而是将一些快速实用的东西组合在一起，请考虑不需要您构建与自己的数据库系统等效的选项。

Answer 2

如果这只是存储“一堆文件”的情况，您可能只需要像 BDB 这样的简单键/值存储，它可以很容易地扩展到任何 RDBMS，包括 MySQL、SQLite，甚至键/值存储比如东京内阁。

SQLite 出现这样的问题有什么原因吗？强大的数据存储机制可能是处理“文件堆”系统的更好方法。