将大型数据库加载到visualc内存中

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

目前，我们正在动态地进行所有内存分配，这相当慢，但只执行一次，因此在时间方面不成问题

我们在考虑，如果我们使用全局数据结构而不是动态分配，在启动或运行时性能方面是否会更快。但VisualStudio似乎将全局数据结构限制在了微薄的4gb，即使您将链接器堆提交和保留大小设置得更大

---

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

您正在分配多少内存区域（1 x 120GB）或（1200亿x 1字节）等

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

---

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

实现这一点的一种方法是将数据库作为一个数据库，然后使用数据库的查询部分来访问它，而不是动态分配的结构。这可能值得一试，我认为性能不会受到太大影响（但当然会更慢）。

启动性能：如果您正在考虑从动态全局分配切换到静态全局分配，然后我假设您知道在编译时分配了多少，并且在运行时执行了固定数量的分配。我会考虑减少分配的数量，对新的实际调用是真正的瓶颈，而不是实际的分配本身。 运行时性能：不，它不会提高运行时性能。这种大小的数据结构将在堆上结束，然后在读取时在缓存中结束。为了提高运行时的性能，您应该致力于改进数据的局部性，以便在刚刚使用的某些数据之后所需的数据最终位于同一缓存线上，并在缓存中与刚刚使用的数据同步

---

我使用的这两种技术都非常有效，有效地“批量”排列体素数据，减少了树结构中数据的局部性，减少了对新数据的调用次数，极大地提高了我以前工作过的实时渲染器的性能。我们讨论的是大约40GB的体素结构，可能是磁盘流。为我们工作：）。

您是否对“内存中”解决方案与在固态驱动器上设置索引良好的只读表进行了实际的基准测试？根据整体解决方案的不同，您的额外努力很可能只对最终用户产生很小的改进。我碰巧知道，至少有一种解决方案接近半PB的存储空间，其中访问模式完全随机，最终用户对磁盘上所有数据的响应时间不到10秒。

我会在Linux系统上编写这样一个beast，它可以处理这样的负载（在64位x86-64=AMD64系统上）。填充100GB需要时间。由于每个项目的开销，还不能确定120Gb的数据库是否能填满256GB的RAM。我很想把它转移到Linux上，但这场斗争已经结束。我们有非常快速的固态驱动器设置，因此，一旦分配了内存，在不到10秒内加载120 GB。是的，120GB确实合适；事实上，我们已尝试加载2个副本（每个100GB），可用内存没有问题。为了确保这一点，这意味着您运行的是2008或2003服务器R2，具有64位进程，对吗？该平台是一个四E7主板、256GB内存和多个Revo SSD。我从来不需要打开办公室的暖气：）我们自己做内存管理。我们正在分配10个12 GB的块，然后使用指针来分割数据。是的，有很多基准测试，内存中的数据差异很大。随机访问速度不是问题。通过构造良好的索引，无论是否将其存储在ssd上，您都可以在几分之一秒内访问1000 PB。这里的问题是需要尽快处理千兆字节的数据。