DIY для банка: выбираем базу данных, когда стартап нас отшил

В предыдущей серии я рассказывал, как TigerBeetle — стартап нашей мечты — отправил нас во френдзону. Пришлось засучить рукава и делать «сердце» банка самим.

Но на чем писать? Чтобы не было мучительно больно за бесцельно прожитые спринты, мы сформулировали требования.

Задача:

- 1000 TPS (транзакций в секунду) на рандомных аккаунтах.
- 100 TPS на одного «жирного» клиента.

С первым пунктом всё понятно: если руки растут из плеч, любая современная БД это вывезет. А вот второй пункт — это боль. Нужно заблокировать аккаунт, посчитать баланс, записать проводку и разблокировать. Арифметика беспощадна: 1 секунда / 100 транзакций = 10 мс на всё про всё. Тут уже на Python не попишешь, тут думать надо.

В кастинг на роль «сердца» попали четыре кандидата:

1. Postgres (Классика)
Старый добрый слон. Чтобы уложиться в 10 мс, всю логику придется зашивать в хранимки (Stored Procedures). Гонять данные туда-сюда между приложением и БД — непозволительная роскошь. Сомнения: Наша текущая система на MySQL выдает жалкие 7 TPS. Вендор клянется мамой, что это предел физики. Мы, конечно, умнее, но сможем ли мы быть умнее на порядок? Вопрос открытый.

2. Redis + Postgres (Безумный Макс)
Идея для смелых: ставим Redis перед Постгресом. — «Но это же просто кэш!» — кричат пуристы. — «Подержите мое пиво», — отвечаем мы.

Почему это круто:

- Single-threaded: Редис однопоточный. Никаких гонок (race conditions). Атомарность из коробки.

- Lua scripts: Логику можно исполнять прямо внутри памяти. Быстро, дерзко.

- Надежность: У Редиса есть стримы. Можно реализовать Transaction Outbox паттерн без танцев с бубном, Kafka и Debezium. Данные льются в Postgres в фоне.

- Персистенс: Да, вся база должна лезть в RAM. Но Редис умеет сбрасывать данные на диск и реплицировать на слейвы. Если настроить прямыми руками — надежно, как швейцарские часы.

3. TigerBeetle (Бывшая)
Те самые ребята, которые нас отшили. Заявляют 1 000 000 TPS. Даже на один аккаунт. Звучит как сказка, но проверить надо. Вдруг врут? А если не врут — будем кусать локти (или снова проситься к ним).

4. Google Spanner (Швейцарский нож)
Самый загадочный зверь. Спрашиваешь у Гугла, что такое Spanner, и тебе отвечают: «ЭТО ВСЁ».
Хочешь SQL? Spanner.

Хочешь Key-Value? Spanner.

Графы? Spanner.

AI? Разумеется, Spanner! Там скоро можно будет писать запросы в духе: «AI, проверь, хватит ли у юзера 123 денег на пиво, и если да — переведи».
На презентации меня сдержало только хорошее воспитание, чтобы не спросить: «А блокчейн вы туда еще не впихнули?». Похоже, это единственное, чего там нет.

Проблема: Это распределенная БД. Она сама решает, где хранить данные. Скорее всего, она раскидает счета по разным нодам, и каждый перевод превратится в multi-node transaction. А это медленно. Но Гугл так настойчиво поил нас кофе и водил по виски-барам, что мы решили дать Спаннеру шанс. Из вежливости.

------

Результаты эпичной битвы и реальные цифры нагрузочного тестирования — в следующем посте.

А пока вангуем в комментариях. В каком порядке тулзы пришли к финишу (от лучшей производительности к худшей). И какую технологию выбрали бы лично вы?

Кто будет ближе всех — тот настоящий HighLoad архитектор.