Файлы с отображенной памятью плохо для постоянно меняющихся данных?

Question

У меня есть служба, которая отвечает за сбор постоянно обновляемого потока данных из сети. Предполагается, что весь набор данных должен быть доступен для использования (только для чтения) в любое время. Это означает, что самое новое сообщение с данными, которое приходит к самому старому, должно быть доступно клиентскому коду.

В настоящее время планируется использовать отображенный в памяти файл в Windows. Прежде всего потому, что набор данных огромен, охватывая десятки ГиБ. Нет никакого способа узнать, какая часть данных будет необходима, но когда это необходимо, клиенту, возможно, придется прыгать по желанию.

Файлы с отображенной памятью отвечают всем требованиям. Однако я видел, как сказано (написано), что они лучше всего подходят для наборов данных, которые уже определены и не постоянно меняются. Это правда? Может ли сценарий, который я описал выше, достаточно хорошо работать с файлами отображения памяти?

Или лучше оставить файл отображения памяти для всех данных до некоторого количества МБ последних данных, чтобы файл отображения памяти содержал почти 99% истории входящих данных, но я храню больше всего последние, скажем, 100 МБ в отдельном буфере памяти. Каждый раз, когда этот буфер заполняется, я перемещаю его в файл отображения памяти и затем очищаю его.

Answer 1

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

Answer 2

Из вашей постановки задачи я вижу следующие требования:

1. данные должны быть всегда доступны
2. данные записываются один раз, я предполагаю, что они только добавляются, никогда не перезаписываются.
3. шаблон доступа для чтения данных является случайным, т. Е. Прыгает вокруг
4. там также, кажется, есть неявное требование задержки

Мне кажется, файл с отображенной памятью выбран по адресу 3) + 4). Если ваш размер данных может поместиться в памяти, это вполне может быть разумным решением. Однако, если размер ваших данных слишком велик для размещения в памяти, файл с отображением в памяти может привести к снижению производительности из-за частой ошибки страницы.

Вы не описали, как делается "прыжок вокруг". Если возможно построить индекс, вы сможете сохранить данные в несколько файлов, сохранить индекс в памяти, использовать индекс для загрузки и обслуживания данных, а также кэшировать наиболее часто используемые данные. Основная идея похожа на хэш на основе диска. Вероятно, это более масштабируемое решение.

Answer 3

Любой набор данных, который определен и не изменяется, является лучшим!
Файлы, отображаемые в память, обычно побеждают другие возможности - большинство ОС все равно кэширует доступы в ОЗУ. И производительность будет предсказуемой, вы не упадете с обрыва, когда начнете менять местами.

Answer 4

Файл может быть отображен как доступный только для чтения в одном потоке, который представляет данные и имеет фоновый рабочий поток, в котором файл отображается как readwrite для выполнения добавления.

Answer 5

Поскольку вы пометили этот Win32, я предполагаю, что вы работаете на 32-битной машине, и в этом случае вам просто не хватает адресного пространства для отображения в памяти всего вашего набора данных. Это означает, что вам придется создавать и уничтожать сопоставления в файле, когда вы «перепрыгиваете», что сделает это менее эффективным, чем вы ожидаете.

На практике, как правило, у вас есть чуть более 1 ГБ непрерывного адресного пространства, чтобы отобразить файл в 32-битном окне Windows, и вы можете получить меньше, если фрагментируете свое адресное пространство.

Как говорится, выполнение этого с картами памяти имеет преимущество, если вы ограничены в памяти (не в адресном пространстве), поскольку, когда вы отображаете в памяти файл только для чтения (в отличие от явного чтения его в память), ОС будет нет второй копии в кеше файловой системы.