从ruby处理许多小数据文件迁移到几个大数据文件时，我应该记住什么？
背景：我是一名正在处理下一代测序数据的生物信息学家，每次测试产生大约一百万个序列。我之前将每百万个序列中的每一个保存到自己的文件中，并对每个序列执行了一些处理步骤，为每个序列生成几个文件。不幸的是，拥有数百万个文件正在使文件输入和输出成为主要瓶颈（并且还会使备份变慢）。 （在answers to this question）
中也不鼓励拥有数百万个文件我考虑使用sqlite来存储每个文件，但我想尽可能避免使用此选项，以避免添加依赖项。
我怀疑我应该只编写一个模块来处理大文件，并且让所有处理脚本（作为独立进程运行）在想要输入或输出时使用该模块。为处理类提供使用StringIO创建的文件流可能对此有用，因为他们不需要知道大文件的工作方式。
为了避免在获取输入时必须读取整个大文件（我希望将每个序列的处理作为一个独立的过程，以便分析一个序列不会破坏另一个序列的分析），我我必须跟踪我在大输入文件中的位置。虽然存在更复杂的进程间通信技术，但我可能只是使用临时文件来存储IO＃seek的字符位置。
我还必须记住，如果他们写入同一个文件，我将无法立即运行多个进程，并且大文件处理程序需要定期刷新其输出。
答案 0 :(得分：1)
我不知道你的情况的细节，但你所描述的应用程序 - 我想存储一百万件事情，我想快速灵活地访问它们 - 听起来像是一个DB给我。通过避免像sqlite这样的工具，你不一定能避免依赖;你可能正在为另一种交易一种依赖。
如果您必须推出自己的基于文件的解决方案，则不一定要从一个极端转到另一个极端。那1000个中等大小的文件分散在10个子目录中呢？那些中等大小的文件可能是.tar档案或类似的东西（伪装目录），从你的代码的角度来看，这些文件的行为可能与你习惯处理的100万个小文件非常相似。此外，这些.tar文件仍可直接从命令行访问，无需任何特殊软件。
也许这些都是疯狂的想法，但是如果你要避免使用数据库，而是将快速而实用的东西鞭在一起，那么考虑一些不需要你建立自己的数据库系统的道德等价物的选项。
答案 1 :(得分：0)
如果只是存储“一堆文件”的情况，你可能只需要一个像BDB这样的简单键/值存储，它可以很容易地扩展到任何RDBMS，包括MySQL，SQLite，甚至是键/值存储像东京内阁一样。
SQLite出现这种问题的原因是什么？强大的数据存储机制可能是更好的“文件堆”系统方法。