Oberon space
General Category => Общий раздел => Тема начата: Губанов Сергей Юрьевич от Октябрь 10, 2012, 04:37:54 am
-
Мучает меня дурацкая идея...
Есть данные. В основном данные нужны в режиме только для чтения. Изменяются они редко. Данных может быть много - гигабайты.
Есть программа. Программа стартует, медленно всасывает в себя все данные, а потом очень быстро работает.
Программ может быть несколько (у меня их уже две). Запускаются они на одном большом сервере.
Вроде всё нормально, однако:
1) Жалко память (копий данных столько сколько программ).
2) Жалко при старте тратить время на всасывание данных (хочется иметь возможность очень быстрого рестарта).
Дурацкая идея:
Сделать "сервер" данных, который будет шарить свою память. Он (ре)стартует медленно.
Остальные программы при старте будут всего лишь маппить память. Выгоды: мгновенный рестарт, данные не копируются.
Сколько же тут подводных камней...
-
Сколько же тут подводных камней...
Ну, на первый взгляд я тут камней не вижу, если сделать модификацию (которая, судя по описанию задачи, крайне редка) через через запрос на этот сервер. То есть мапим данные в режиме RO, в случае модификации просим сервак что-то там модифицировать. Если модификация не разрушает структуру уже готовых данных, то все ок. Если разрушает, то в момент изменения данных сервер должен послать сигнал обоим базам что он блокирует вот эту область БД для модификации, дождаться ответа от обоих программ что они поняли, и уже потом модифицировать. После окончания модификации он оповещает что все, можно дальше работать.
-
Если разрушает, то в момент изменения данных сервер должен послать сигнал обоим базам что он блокирует вот эту область БД для модификации, дождаться ответа от обоих программ что они поняли, и уже потом модифицировать. После окончания модификации он оповещает что все, можно дальше работать.
Что-то ты больно сложно. Я думаю тут можно использовать interlocked increment/decrement для рукопашной реализации критических секций, а так же для счётчиков ссылок.
-
Что-то ты больно сложно. Я думаю тут можно использовать interlocked increment/decrement для рукопашной реализации критических секций, а так же для счётчиков ссылок.
Это уже детали реализации :-) По факту критические секции, это и есть, в некотором роде, обмен сигналами (занят/свободен ресурс).
Если запись случается действительно редко, я бы наверно сделал бы вообще обмен блокирующими сообщениями через какой-нибудь голимый tcp и не парился бы. Если же запись не редко, а просто не часто, тогда можно и критические секции прикрутить или еще как-то оптимизировать синхронизацию работы.