загрузка огромной базы данных в память Visual C

Question

У нас есть несколько необычное приложение c, так как оно представляет собой базу данных объемом около 120 гигабайт, которая загружается в память для максимальной производительности. Машина, на которой она работает, имеет около четверти терабайта памяти, поэтому нет проблем с доступностью памяти. База данных доступна только для чтения.

В настоящее время мы динамически распределяем всю память, что довольно медленно, но выполняется только один раз, поэтому с точки зрения времени это не проблема.

Мы думали о том, будет ли быстрее, при запуске или во время выполнения, если бы мы использовали глобальные структуры данных вместо динамического выделения. Но похоже, что Visual Studio ограничивает глобальные структуры данных до скудных 4 ГБ, даже если вы установите коммит кучи компоновщика и зарезервированный размер намного больше.

Кто-нибудь знает способ обойти это?

Answer 1

Один из способов сделать это - создать базу данных в виде файла отображения постоянной памяти , а затем использовать часть запроса базы данных для доступа к ней вместо динамически размещаемых структур.Возможно, стоит попробовать, я не думаю, что производительность сильно пострадает (но, конечно, будет медленнее).

Answer 2

Сколько областей памяти вы выделяете? (1 x 120 ГБ) или (120 миллиардов x 1 байт) и т. Д.

Я считаю, что работа, выполняемая при динамическом выделении памяти, пропорциональна количеству выделенных областейа не их размер.

В зависимости от ваших данных и использования (уточните, и мы можем быть более конкретными), вы можете выделить большой блок памяти кучи (например, 120 ГБ), а затем управлять этим самостоятельно.

Answer 3

Проводили ли вы реальный тест своего решения «в памяти» по сравнению с хорошо индексированной таблицей, доступной только для чтения, установленной на твердотельных накопителях? В зависимости от общего решения вполне возможно, что ваши дополнительные усилия принесут только небольшие улучшения для конечного пользователя. Мне известно о том, что по крайней мере одно решение, занимающее половину петабайта памяти, где шаблон доступа является абсолютно случайным с временем отклика конечного пользователя менее 10 секунд со всеми данными на диске.

Answer 4

Производительность при запуске : Если вы думаете о переходе от динамического к статическому глобальному распределению, то я предполагаю, что вы знаете, сколько вы выделяете во время компиляции, и существует фиксированное число распределения выполняются во время выполнения. Я бы подумал о сокращении количества выполненных распределений, фактический вызов new - это реальное узкое место, а не само фактическое распределение.

Производительность во время выполнения : Нет, это не улучшит производительность во время выполнения. Структуры данных такого размера окажутся в куче, а затем в кеше по мере их чтения. Чтобы повысить производительность во время выполнения, вы должны стремиться улучшить локальность данных, чтобы данные, необходимые после некоторых из них, которые вы только что использовали, оказались в той же строке кэша и располагались в кэше с данными, которые вы только что использовали.

Обе эти техники, которые я использовал для достижения максимального эффекта, эффективно упорядочивают данные вокселей в «пакетах», уменьшают локальность данных в древовидной структуре и сокращают количество обращений к новым, значительно повышают производительность рендерера в реальном времени. Я работал в предыдущей должности. Мы говорим о ~ 40 ГБ воксельных структурах, возможно, потоковом диске. Работал у нас:).