SQLite 3.7.0

Узким местом SQLite является медлительность при insert/update из-за необходимости выполнения fsync/flush (медлительного во всех ОС) по завершении транзакции — без fsync нельзя гарантировать целостность базы или возможность отката последней незавершенной транзакции при сбое питания. Можно "пакетировать" изменения в "длинные транзакции", чтобы удельная задержка от fsync на каждую операцию была ниже. Но это не всегда возможно, особенно в многопоточной среде. Приходится либо менять режим commit'ов на более скоростной, но менее надежный (например, без rollback-журнала), либо городить сверху самодельный "пакетировщик" длинных транзакций — сохраняя надежность, но получая потенциальную возможность потери всего пакета изменений.

DRH придумал, как убить двух зайцев. Заводится отдельный журнальный файл, в котором последовательно накапливаются последние изменения, которые периодически (намного реже, чем на каждый insert/update, как в штатном autocommit-режиме 3.6.x) "сбрасываются" в основной файл одной длинной операцией. Это радикально (на порядки!) сокращает число необходимых fsync'ов, а заодно и уменьшает число блокировок. Правда ценой некоторого замедления select'ов. Но поскольку этот режим лога (он называется WAL — Write-Ahead Logging) опциональный, то можно его включать только там, где важна именно скорость вставки, а выборка редка, например для БД со статистическими журналами.

Ждать этого счастья еще два месяца. Если всё действительно будет работать так, как обещано (здесь: http://www.sqlite.org/draft/wal.html ), то этим планом DRH дарит (сберегает) мне несколько рабочих дней. А то я уже начал было подумывать заменить sqlite в сессионной БД в E4 на что-нибудь самодельное (на текущий момент самодельная БД используется только для сводной статистической информации — DATA\log\stat\2010stat.e4r — т.к. у sqlite не хватает сил работать с такими данными в реальном времени).