БД через расшаренную память

[Губанов Сергей Юрьевич]

Мучает меня дурацкая идея...

Есть данные. В основном данные нужны в режиме только для чтения. Изменяются они редко. Данных может быть много - гигабайты.

Есть программа. Программа стартует, медленно всасывает в себя все данные, а потом очень быстро работает.

Программ может быть несколько (у меня их уже две). Запускаются они на одном большом сервере.

Вроде всё нормально, однако:
1) Жалко память (копий данных столько сколько программ).
2) Жалко при старте тратить время на всасывание данных (хочется иметь возможность очень быстрого рестарта).

Дурацкая идея:
Сделать "сервер" данных, который будет шарить свою память. Он (ре)стартует медленно.
Остальные программы при старте будут всего лишь маппить память. Выгоды: мгновенный рестарт, данные не копируются.

Сколько же тут подводных камней...

[valexey_u]

Сколько же тут подводных камней...

Ну, на первый взгляд я тут камней не вижу, если сделать модификацию (которая, судя по описанию задачи, крайне редка) через через запрос на этот сервер. То есть мапим данные в режиме RO, в случае модификации просим сервак что-то там модифицировать. Если модификация не разрушает структуру уже готовых данных, то все ок. Если разрушает, то в момент изменения данных сервер должен послать сигнал обоим базам что он блокирует вот эту область БД для модификации, дождаться ответа от обоих программ что они поняли, и уже потом модифицировать. После окончания модификации он оповещает что все, можно дальше работать.

[Губанов Сергей Юрьевич]

Если разрушает, то в момент изменения данных сервер должен послать сигнал обоим базам что он блокирует вот эту область БД для модификации, дождаться ответа от обоих программ что они поняли, и уже потом модифицировать. После окончания модификации он оповещает что все, можно дальше работать.

Что-то ты больно сложно. Я думаю тут можно использовать interlocked increment/decrement для рукопашной реализации критических секций, а так же для счётчиков ссылок.

[valexey_u]

Что-то ты больно сложно. Я думаю тут можно использовать interlocked increment/decrement для рукопашной реализации критических секций, а так же для счётчиков ссылок.

Это уже детали реализации :-) По факту критические секции, это и есть, в некотором роде, обмен сигналами (занят/свободен ресурс).

Если запись случается действительно редко, я бы наверно сделал бы вообще обмен блокирующими сообщениями через какой-нибудь голимый tcp и не парился бы. Если же запись не редко, а просто не часто, тогда можно и критические секции прикрутить или еще как-то оптимизировать синхронизацию работы.