Здравствуйте, GlebZ, Вы писали:

Мы используем Prevayler в реальном проекте для хранения кэша на клиенской стороне. Вещь действительно изящная. Но...
Prevayler фактически это не более чем навороченная сериализация (через "транзакции") сложной структуры данных. Следствие — если начали использовать одну структуру — ее уже нельзя менять. А бывает нужно. Из-за этого приходится извращаться, придумывать спец. форматы объектов, промежуточно сначала сериализовать во что-то простое и т.д.

В общем хотим отказаться.

GZ>Здравствуйте, Poudy, Вы писали:

P>>Здравствуйте, GlebZ, Вы писали:
P>>>>Эффективный — это быстрый или мощный?
GZ>>>Да.
P>>Что да Оба что ли?
GZ>Почему бы и нет.

P>>>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД.
GZ>>>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.

P>>Не верю, что известно. Мне непонятно, откуда может взяться разница.
GZ>Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д.
GZ>Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.

GZ>>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
P>>Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле?
GZ>Используется оно в том то и дело, очень эффективно. И занимает место для этой цели, действительно больше.

GZ>>>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде.
P>>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях.
GZ>Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?

GZ>С уважением, Gleb.