Введение

Синхронный WAL очень частое явление в базах данных, делая их durability максимальной. При таком исходе каждый батч записи это вызов fsync, и это дало мне 956k opr/s на 16кб значениях, звучит хорошо, но на самом деле: скорость записи упала в 5 раз.

В этой статье я расскажу:

• Что такое групповой коммит на пальцах

• Почему групповой коммит не для финтеха

• Как это реализовано у меня

• Как изменились цифры до и после внедрения

• Во сколько раз ScoriaDB с group commit быстрее BadgerDB и Pebble.

Если вы пишете хранилище, логгер, кэш или просто любите копаться в LSM‑движках — добро пожаловать на борт, нас ждет короткое путешествие.

Что такое групповой коммит

Представьте, если бы в вашем мессенджере нельзя было отправить кучу фоток выделяя галочками.

Вам нужно скинуть другу их 10 штук, приходится отправлять поштучно, а каждая фотография это отдельное сообщение и уведомление, что весьма неудобно и времязатратно.

Но, как и в математике, где что‑то общее выносят за скобку, для группы фоток можно вынести их отправку.

Групповой коммит это почти тоже самое, что отправка фоток одной пачкой. Вместо того, чтобы писать все записи по отдельности и после каждой делать запрос на диск, fsync делается только на пачку.

Почему почти?

Групповой коммит работает по таймеру, в течение которого накапливаются данные. Не по количеству, как с фотками ( напомню, что чаще всего одним сообщением 10 фоток) потому что идея считать сколько записей не очень производительна.

И этот интервал времени, по мере которого данные будут принадлежать одной пачке, необходимо задать — в ScoriaDB это 10 мс.

В ScoriaDB этот режим включён по умолчанию. Для финансовых задач не рекомендуется групповой коммит.

2. Почему групповой коммит не для финтеха

Потому что там недопустима потеря записи.

Если питание отключится за эти 10 мс — пачка транзакций исчезнет безвозвратно.

Чтобы не произошло катастрофы там используют синхронный режим: fsync после каждой записи.

От группового коммита стоит отказаться в любом сценарии, где потеря одной записи влечет репутационный или денежный ущерб.

Как отключить?

При открытии базы передайте параметр GroupCommitEnabled: false через внутренний API. (В след релизе появится простой флаг в публичном конструкторе)

Когда точно можно:

• Логи, метрики, трейсы. Если при краше вы потеряете последние 10 мс логов — мир навряд ли рухнет.

• Разработка и тестирование. Когда база гоняется локально и накапливает тонны данных — скорость важнее, чем мифический краш посередине теста.

• Любая аналитика, где важна пропускная способность, а не каждая запись. Например, видеонаблюдение.

• Кэш, сессии, временные данные. Они и так живут в памяти, а на диске, как подстраховка от перезапуска.

• Большие пакетные вставки данных (ETL, миграции, бэкапы). Там важна итоговая сумма, а не каждая промежуточная запись.

Когда можно, но с оговорками:

• IoT‑сенсоры, показания счётчиков. Если потеряется — ничего страшного, следующий цикл перезапишет. Но строго нет, если это датчик критичный или повлечет денежные убытки, даже за 10мс.

• Игровая аналитика (действия игроков). Потеря нескольких кликов за 10 мс незаметна на фоне общего трафика. Но покупки внутри игры — уже финансы, там отдельно.

3. Как это реализовано у меня

У него есть три простых вещи:

1. Буфер — обычная переменная в памяти. Вы кидаете туда свои записи, они лежат и ждут своей очереди.

2. Интервал — 10 мс.

3. Канал для сигнала «Сбросить на диск сейчас» — при закрытии базы можно сбросить все, даже если таймер еще не прошел.

Как работает этот цикл:

• По истечению таймера, или сигналу из канала, он вызывается.

• Смотрит буфер: если там ничего нет, спим дальше.

• Что‑то пришло? — тогда:

  1. Берёт всё из буфера

  2. Записывает в файл WAL

  3. Просит диск это зафиксировать через fsync

  4. Очищает буфер

А как же Deadlock?

Для этого продуман мьютекс. Один заходит — закрывает, кладёт запись, выходит — открывает. Остальные ждут своей очереди.

Где лежит код?
Вот ссылка на тот файл в репозитории:

4. Как изменились цифры до и после внедрения

Железо: Intel Core i3-1215U (8 потоков), NVMe SSD

Среда: Linux, Btrfs (тоже имеет значение)

Синхронный режим

Групповой коммит

Для маленьких значений прирост значительный — в 1,62 раза. Для 4 КБ разница скромнее, ведь узкое место уже не WAL, а копирование данных в Value Log и работа с диском (проблема, которую я решу в след. релизе).

И, короночка, как изменилась производительность WAL

Групповой коммит сильнее всего ускорил сам журнал предзаписи

Конкурентная запись (8 потоков)

Масштабируемость на 8 потоках улучшилась в 4,1 раза — групповой коммит снимает конкуренцию за мьютекс WAL.

Также он никак не влияет на чтение — MVCC гарантирует, что читатели не блокируются писателями.

P. S. Как повторить мои бенчмарки

git clone https://github.com/f4ga/ScoriaDB.git
cd ScoriaDB
go test -bench='BenchmarkPut' -benchtime=5s -count=5 -benchmem ./pkg/scoria/

Цифры будут зависеть от вашего железа. У меня проц слабоват и, кажется, эти бенчи кратно сократили жизнь ноуту... С современным диском и >8 ядер, может быть ещё быстрее. Будет интересно, что выйдет на HDD.

5. Во сколько раз ScoriaDB с group commit быстрее BadgerDB и Pebble

Все бенчмарки запущены на одном железе

Для справки: ScoriaDB в режиме batch sync (fsync на каждый батч, без группового коммита) даёт 956 000 ops/s — это тоже выше, чем у конкурентов

ScoriaDB с групповым коммитом даёт в 3 раза больше операций в секунду, чем Pebble, и в 8,4 раза больше, чем BadgerDB.

Таблица иллюстрирует, какой выигрыш даёт переход к групповому коммиту. Но открою секрет, она и без него была в пару раз быстрее.

Контракты надежности принципиально разные, но Групповой коммит в ScoriaDB можно отключить.

7. Итог

Групповой коммит — это честный инженерный компромисс.

• Плюс: 1,44 млн операций в секунду (прирост в 1,6×).

• Минус: задержка до 10 мс и потеря последней группы при краше.

ScoriaDB все же отличается своей сборкой решений. Здесь есть MVCC (многоверсионность), Column Families (отдельные LSM‑деревья), встроенный gRPC/REST‑сервер, и все не на плюсах, а на гошке.

Заходите, смотрите, критикуйте и предлагайте, не забудьте поддержать проект звездочкой, автору будет приятно.

Исходный код

README на двух языках, дока только на английском.

Если вы знаете хранилища на Go, где есть групповой коммит, то поделитесь пожалуйста, потому что я не смогла найти такого.

Спасибо, что дочитали до конца. Буду рада поддержать обсуждение и ответить на вопросы, надеюсь удастся прочитать ваши issues или PR.