Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, avostrjakov, Вы писали:
G>>>Каковы типичные сценарии применения этой штуковины?
A>> В данной таблицы храняться сообщения от одного пользователя другому. Храняться пока не доставяться
A>>к конечному пользователю, что иногда может быть долгим процессом.
G>Я не до конца понимаю, что у вас за задача, но у меня есть стойкое ощущение, что вы делаете что-то не так. Очень уж странно как-то получается.
G>>>Сколько процессов пишут/читают?
A>> Пока это все прототип. Пишет и читает один процесс. В будущем будет много: сотни.
G>Сколько точно будет процессов? По одному на пользователя, нет? Короче говоря, пока вы задачу не опишете, вряд-ли кто-то сможет вам прокомментировать по сути.
Ок, Возьмем по максимуму. Считаем, что один процесс на пользователя. Одновременно передаваемых сообщений скажем 100 тысяч. Каждое сообщение размером примерно 100 Кб. В таблице может находиться примерно 4 миллиона записей. Одни процессы кладут туда записи, другие забирают данные (см. мой первоночальный пост).
G>>>Зачем нужно disk_copies?
A>> В память все это может не влезть, т.к. сообщения достаточно большие. Во-вторых, в случае падения легче восстановиться с диска.
G>Во-первых, вся таблица целиком хранится в памяти даже в случае disc_copies — на диск пишутся только изменения, и последовательно. disc_copies применяется только для восстановления таблицы при старте. "По настоящему" на диске это будет лежать только в случае disc_only. Насчет disc_only надо еще сказать, что одна таблица не может превышать 2GB в любом случае — придется fragmented tables использовать, чтобы это обойти.
2 GB — это ограничение мнезии? Подскажи пожайлуста, где про это написано.
G>Во-вторых, мнезия должна после падения прекрасно восстановится и с другой машины — не понятно, почему с диска восстановится "легче". Она же умеет и так и так, и она железная, ей все равно как восстанавливаться, нет? 
Про восстановление мнезии согласен. Когда я отвечал, то думал, что ты предлагаешь использовать некий кэш в памяти, а не мнезию.
