好的。所以我有大量的二进制数据（比如 10GB）分布在一堆不同长度的文件（比如 5000 个）上。
我正在编写一个 Java 应用程序来处理这些数据，并且我希望为数据访问制定一个好的设计。通常会发生这样的事情：
目前我正在使用 RandomAccessFile 类来读取字节缓冲区（和 ByteBuffers）。我的最终目标是将数据访问封装到某个类中，这样它就很快了，我再也不用担心它了。基本功能是我将要求它从指定文件中读取数据帧，并且考虑到上述考虑，我希望最小化 I/O 操作。
典型访问示例：
有什么好的设计建议吗？
使用 Java NIO 和 MappedByteBuffers，并将您的文件视为字节数组列表。然后，让操作系统担心缓存、读取、刷新等细节。
@将要
相当不错的结果。读取大二进制文件快速比较：
测试 1 - 使用 RandomAccessFile 进行基本顺序读取。 2656 毫秒
测试 2 - 带缓冲的基本顺序读取。 47 毫秒
测试 3 - 使用 MappedByteBuffers 和进一步帧缓冲优化的基本顺序读取。 16 毫秒
哇。您基本上是从头开始实现数据库。是否有可能将数据导入实际的 RDBMS 并仅使用 SQL？
如果你自己做，你最终会想要实现某种缓存机制，所以你需要的数据来自 RAM，如果它在那里，你正在读取和写入较低层的文件。
当然，这也需要大量复杂的事务逻辑来确保您的数据保持一致。
我打算建议你跟进Eric 的数据库理念，学习数据库如何管理它们的缓冲区——有效地实现它们自己的虚拟内存管理。
但是当我想得更多时，我得出的结论是，大多数操作系统在实现文件系统缓存方面已经比在 Java 中没有低级访问可能做得更好。
不过，您可能会考虑从数据库缓冲区管理中吸取的一个教训。数据库使用对查询计划的理解来优化管理策略。
在关系数据库中，通常最好从缓存中逐出最近使用的块。例如，在连接中包含子记录的“年轻”块将不会被再次查看，而包含其父记录的块仍在使用中，即使它是“旧”的。
另一方面，操作系统文件缓存经过优化以重用最近使用的数据（并提前读取最近使用的数据）。如果您的应用程序不符合该模式，则可能值得自己管理缓存。
您可能想看看一个名为jdbm的开源简单对象数据库——它开发了很多此类东西，包括 ACID 功能。
我已经为该项目做出了许多贡献，如果没有别的，看看我们如何解决您可能正在处理的许多相同问题，这将是值得审查的源代码。
现在，如果您的数据文件不在您的控制之下（即您正在解析由其他人生成的文本文件等），那么 jdbm 使用的页面结构化存储类型可能不适合您 - 但如果所有这些文件是您正在创建和使用的文件，可能值得一看。
@埃里克
但是我的查询将比我用 SQL 做的任何事情都要简单得多。数据库访问不会比读取二进制数据更昂贵吗？
这是为了回答关于最小化 I/O 流量的部分。在 Java 方面，您真正能做的就是将您的阅读器包装在 BufferedReaders 中。除此之外，您的操作系统将处理其他优化，例如将最近读取的数据保存在页面缓存中，并对文件进行预读以加快顺序读取。在 Java 中进行额外的缓冲是没有意义的（尽管您仍然需要一个字节缓冲区来将数据返回给客户端）。
前几天我有人向我推荐了 hadoop ( http://hadoop.apache.org )。看起来它可能很不错，并且可能具有一定的市场吸引力。