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

SL>по сути по количество вызовов flush одинаково во всех режимах, и выигрыш возможен только при наличии достаточных интервалов между транзакциями, если же система по нагрузкой с длинными и короткими транзакциями вперемешку постоянно, то особого выигрыша не будет.

Как-то сумбурно ты описал оба варианта. "Классический" я в таком виде не встречал, это в какой базе так, например?

При WAL нам не нужно делать flush для страниц из файла данных. В принципе, они могут записываться в файл только при вытеснении. Если произойдет крах, состояние файла данных можно полностью восстановить по журналу. Специально мы записываем измененные страницы данных для того, чтобы этот процесс не занимал слишком много времени. Поэтому записывающий процесс/поток ставит контрольные точки. Номер контрольной точки записывается и в файл журнала, и в файл данных. Процесс, выполняющий восстановление после краха, читает номер контрольной точки из файла данных и понимает, что на этот момент все изменения в журнале отражены в файле данных. Дальше он находит эту точку в файле журнала и применяет к файлу данных только изменения, записанные после нее.

Теперь о том, откуда выигрыш. Запись в файл журнала последовательная (всегда в конец), а в файл данных случайная. Последовательная запись намного быстрее на существующих технологиях внешней памяти (HDD и SSD). При коммите транзакции мы пишем только в журнал, а запись в файл данных откладывается или размазывается во времени. Таким образом, уменьшается и время отклика для конкретной транзакции, и общая пропускная способность, так как другие транзакции меньше ждут на блокировках.

Но с появлением NVM положение дел можнт измениться: http://paulcavallaro.com/blog/write-behind-logging/