将巨大的数据库加载到内存visual c中

Question

我们有一个不寻常的c应用程序，因为它是一个大约120千兆字节的数据库，所有这些都加载到内存中以获得最佳性能。它运行的机器有大约四分之一TB的内存，因此内存可用性没有问题。数据库是只读的。

目前我们正在动态地进行所有内存分配，这很慢，但它只进行一次因此在时间上不是问题。

如果我们要使用全局数据结构而不是动态分配，我们在考虑在启动时还是在运行时性能上是否会更快。但是，即使您将链接器堆提交和保留大小设置得更大，Visual Studio也会将全局数据结构限制为仅4gb。

有人知道解决这个问题吗？

Answer 1

执行此操作的一种方法是将数据库作为persistent memory mapped file，然后使用数据库的查询部分来访问它而不是动态分配的结构。值得一试，我认为性能不会受到太大影响（但当然会慢一些）。

Answer 2

您分配了多少个内存区域？ （1 x 120GB）或（120亿x 1字节）等。

我认为动态分配内存时所做的工作与分配区域的数量成比例，而不是它们的大小。

根据您的数据和用法（详细说明，我们可以更具体），您可以分配一大堆堆内存（例如120 GB），然后自行管理。

Answer 3

启动性能：如果您正在考虑从动态切换到静态全局分配，那么我假设您知道在编译时分配了多少并且有一个固定的数字在运行时执行的分配。我考虑减少执行的分配数量，实际调用new是真正的瓶颈，而不是实际的分配本身。

运行时性能：不，它不会提高运行时性能。该大小的数据结构将最终在堆上，随后在读取时在缓存中。要在运行时提高性能，您应该致力于改善数据的局部性，以便在您刚刚使用的某些数据之后所需的数据将最终存储在同一缓存行中，并在缓存中使用您刚刚使用的数据进行调整。

这两种技术我已经习惯了很好的效果，有效地在'批次'中排序体素数据，减少树结构中数据的位置并减少对new的调用次数，大大提高了实时渲染器的性能我曾在以前的职位上工作过。我们正在谈论~40GB的体素结构，可能是磁盘流。为我们工作：）。

Answer 4

您是否已经对“内存”解决方案进行了实际基准测试，而在固态硬盘上设置了一个良好索引的只读表？根据整体解决方案，您的额外工作完全有可能仅对最终用户产生微小的改进。我碰巧知道至少有一个解决方案接近半PB存储，其中访问模式是完全随机的，最终用户响应时间少于10秒，所有数据都在磁盘上。