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

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

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

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

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

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

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

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

Я пыталась сделать простое KV-хранилище. Ну судя по названию, начну с того, что это был пет-проект. И вот первый вариант, пара тысяч записей и тесты приходилось ждать минуту. Проблема была в неорганизованных данных, ну и в небольшой безответственности перед тем как что-то делать.

Через пару дней я взяла LSM-дерево, мемтейбл на B-дереве(что временно) и компакшн. Дальше были и атомарные батчи, fsync, все хотелось оптимизировать, добавить отказоустойчивости, сделать все более быстро, серьёзно и чтоб хоть где-то полезно.

Я расскажу из каких частей состоит мой движок, почему принимала те или иные решения, где у меня все было не так гладко, компромиссы, что до сих пор не работает и отложено в долгий ящик. Если вы когда-нибудь писали свой storage — очередь, кэш, или свое NoSQL хранилище — мой опыт поможет вам в принятии некоторых решений.