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

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

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

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

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

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

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

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