降低写入大型二进制文件的性能

Question

在我们的一个软件中，我们创建记录并将它们存储在二进制文件中。写入操作完成后，我们回读这个二进制文件。问题是如果这个二进制文件小于100 MB，那么它的性能就足够了，但是一旦这个文件变大，它的性能就会受到影响。

所以，我想把这个大的二进制文件（> 100 MB）拆分成更小的文件（<100 MB）。但似乎这种解决方案并没有获得性能。所以，我只是在考虑处理这种情况的更好方法是什么？

你们真的很有帮助，对此发表评论。

由于

Answer 1

也许您可以尝试使用Sqlite数据库。

Answer 2

只用一瞥系统提供准确的答案总是很难，但你真的试过检查实际的吞吐量吗？

作为第一个解决方案，我只是建议使用专用磁盘（因此没有来自其他进程的并发读/写操作），并且速度很快。这样只需要硬件升级的一些成本，而且我们都知道硬件通常比软件便宜;）你甚至可以使用RAID控制器来最大化吞吐量。

如果您仍然受到磁盘吞吐量的限制，那么使用闪存技术的新技术：USB密钥（虽然看起来可能不太专业）或“新”固态硬盘可能提供比机械更多的吞吐量磁盘。

现在，如果磁盘接近速度不够快或者您无法掌握好的SSD，那么您还有其他解决方案，但它们涉及到软件更改，我建议将它们放在首位。

• 套接字方法：第二个实用程序正在侦听端口，并将数据发送到那里。在本地计算机上它相对较快，并且您也可以并行化工作，因此即使数据大小增加，您仍然可以很快地开始处理。
• 内存映射方法：写入实时内存中的专用区域并从该区域读取实用程序（Boost.Interprocess可能有帮助，还有其他解决方案）。

请注意，如果读取是顺序的，我发现尝试“管道”方法（ala Unix）更“自然”，以便两个进程同时执行。在传统的管道中，数据可能毕竟不会到达磁盘。

遗憾的是，在这个处于压倒性处理能力的时代，我们还在为我们的磁盘IO苦苦挣扎吗？

Answer 3

如果您的应用程序正在读取数据，则顺序迁移到数据库无助于提高性能。如果使用随机访问，则应考虑将数据移动到DB中，尤其是在使用不同索引的情况下。您应检查是否有足够的资源可用，如果完全加载到内存虚拟内存管理可能会对性能产生影响（交换，分页）。根据您的操作系统设置，可以达到文件io缓冲区的限制。文件系统本身可能是碎片化的。 要获得更高质量的答案，您应该提供有关硬件，操作系统，内存和文件系统的信息。以及您的数据文件的使用方式。你可以得到关于内核调整等的提示。

Answer 4

那么这里的检索机制是什么？您的应用程序如何知道要查找哪个较小的文件以查找记录？如果你拆分大文件而没有实现某种形式的键控查找 - 索引，分区 - 你没有解决问题，只是重新安排它。

当然，如果您已经实现了某种形式的索引，那么您已经开始构建自己的数据库了。

如果不了解您的申请，我们就会提出具体建议。也许解决方案是应用RDBMS解决方案。可能NoSQL方法会更好。也许你需要一个文本索引和检索引擎。

因此...

您的应用程序需要多久检索一次记录？它如何决定获得哪些记录？你对糟糕表现的定义是什么？为什么你（你的项目）决定首先使用平面文件而不是数据库？我们在谈论什么样的记录？