Comments 11
Перевожу.
Datomic это Postgres + Kafka в одном
Точнее:
Datomic = иммутабельный event store + queryable database в одном. Ты пишешь факты (datoms), они никогда не удаляются, и поверх них можно делать Datalog-запросы на любой момент времени.
Kafka отдельно не нужна потому что сам Datomic уже append-only лог. А отдельная read-проекция не нужна потому что Datomic сам умеет запросы по всей истории.
Postgres имел бы dual write problem. Записать событие в Kafka И обновить Postgres атомарно нельзя. Решения - transactional outbox. В классическом банке ACID обеспечивает дорогой мейнфрейм с Oracle - тяжелые блокировки, один источник правды.
То есть на datomic исчезает вся сантехника: outbox pattern, консьюмеры, синхронизация проекций, eventual consistency между write и read моделью. Одна система, сразу consistent. И дешёвые ноды в облаке.
Но Kafka у Nubank все равно есть - для межсервисного взаимодействия, не для замены Datomic.
Отличный комментарий, вы правы по сути. Особенно ценное уточнение про dual write problem и исчезновение outbox pattern. У меня в статье не раскрыто, а именно так и происходит. Datomic снимает целый класс инфраструктурных проблем, которые в классическом стеке решаются через слои абстракций поверх абстракций.
С другой стороны, если писать с нуля и правильно разделить на модули и микросервисы, то можно и на обычном стеке: модульный монолит с Postgres, ACID внутри, Kafka только наружу acid модуля.
Всё что ACID - в одной базе, одной транзакции. Сервис может быть легким:
Stateless приложение, горизонтально масштабируется
Postgres read replicas для чтения
Одна схема, один источник правды для финансов
Аудит - append-only таблица в той же транзакции
Это работает до определенного масштаба. Потолок - write throughput одного Postgres мастера, но datomic тоже под сценарий чтение много больше чем запись. Для большинства бизнесов этого хватает с запасом (десятки тысяч TPS).
Не знаю насчёт облака, но на обычных серверах 100+ ядер вполне можно и без мейнфреймов
В итоге, впечатление такое:
Почему Nubank выбрал это, а не Postgres Не потому что Postgres не тянет. А потому что:
Postgres + audit таблицы + CDC + event sourcing + temporal queries = то, что Datomic даёт из коробки Nubank не хотел строить всю эту инфраструктуру руками. Datomic — это event sourcing на уровне базы данных
Да, Nubank пошёл по описанному пути, чтобы достигнуть большего за счёт меньшего. Они эффективно решили бизнес задачу, используя в том числе принципы закона Конвея. Многие не задумываются, что технология и архитектура должна быть связана с бизнес доменом и структурой команд разработки. Люди, технологии и процессы -- это одно целое. Холистический подход.
Читать было интересно - материала много и лично для меня он в основном новый. Но этот LLM-ный слог... ну не говорят люди на русском так, что-то "чужое" чувствуется, портит впечатление.
Спасибо за обратную связь по стилю. Я постараюсь учесть.
Я проводил интересный эксперимент - давал коллегам свои статьи из разных временных периодов. И коллеги чувствуют llm-ный слог в статьях моих 2017 - 2018 года, написанных до эпохи llm. Тогда ещё никто не слышал ни о моделях трансформеров в нейросетях, ни о Сэме Альтмане.
Текущая статья основана на переводе десятка источников с других языков. Большую часть я взял и переписал своими словами, что то скопировал.
Я постарался донести смысл и идею, но не задумывался на формой. Интернет полон человеческих текстов, наполненных формой, но без какого-либо смысла.
Тем не менее учту обратную связь по стилю, это видимо мой недостаток :)
Блокчейн по сути. Только не децентрализованный, с чем обычно ассоциируется блокчейн, а в своем первозданном виде. И при этом вариация криптовалюты, если технически смотреть. А дальше грамотный инструментарий сверху.
Как с бумом доткомов - 99.9% мертвы, но среди выживших и переосмысленных Google и Amazon. Но банкинг консервативнее, долго туда технология будет заезжать. А в этой статье пример когда построили новый с нуля.
Совпадает идея с блокчейном в том, что нужно не перезаписывать прошлое, добавляем только факты событий. Правда у блокчейна основной смысл в консенсусе без доверия, когда доверяем математике и технологии, а не организации и людям. Но обратная сторона в его недостатках, включая скорость и производительность. У Nubank не было цели в децентрализации, там преимущество от использования Datomic в возможности получения темпоральных проекций БД в любой точке одним декларативным datalog запросом. Как то так...
Согласен, что проще красивые технологические решения строить с нуля, и работать в проектах в области greenfield.
После прочтения статьи не покидает впечатление, что все притянуто за уши. То есть, да, успех есть, и, да, какую-то роль тут сыграл стек. Но, непонятно, в этом ли суть. Условно, если ездить на такой же машине, как Альтман, использовать такой же телефон с такой же заставкой экрана, и носить одежду тех же брендов, то это не сильно приблизит к цели создания нового OpenAI.
Лично мне однажды довелось руководить построением антифрода потоке данных в 2 миллиарда событий в день. И, да, все эти вызовы, как, например, невозможность пошардировать все, ибо надо фичи на графах строить, или необходимость иметь историчность, ибо нужен контекст прошлых событий, мне ясен. И то, что self-joins требуют много памяти на таких объемах, понятно тоже (в моем случае, к примеру, выручал сервер с 1.5ТБ RAM). Но, сама идея HTAP хранилища под это дело кажется отвратительной. Ибо строгое разделение на оперативный и аналитический контуры (не запрещая себе при этом обогащать "оперативные" аггрегаты с аналитического контура) элиминирует массу проблем на корню, а отсутствие такового разделения насилует железо и создаёт боттлнеки в обе стороны. Впрочем, чат гпт тоже считает, что Nubank к этому в итоге пришёл
Но есть важная оговорка: в докладе Nubank на InfoQ в 2017 году они сами говорили, что использовать Datomic и их operational transactional infrastructure для агрегатов и аналитики “did not scale well”, и поэтому они сделали традиционный ETL в отдельную analytical environment / data lake. Там же они описывают, что в этой отдельной среде строят отчеты, комбинируют данные из ERP, запускают ML и регуляторную аналитику. Это уже не “чистый HTAP”, а более классическое разделение OLTP и OLAP.
Вообщем, чем-то напоминает восторженную легенду о Viaweb, когда, якобы, создатели стартапа в 95м надрали жопу всему рынку за счёт ставки на Lisp и использовании модификации кодовой базы в рантайме. Но, снова таки, 95й год был давно, а как-то повторить успех и нагнуть рынок за счёт Lisp как-то ни у кого больше и не вышло...
Ваш скепсис во многом оправдан. Просто повторять за лидерами, то так можно попасть в ловушку "Карго-культа". Стек сам по себе никогда не будет причиной успеха, а он в лучшем случае снимет часть налога на сложность в умелых руках. Но ни статья моя, ни сам Nubank не утверждает такого радикального тезиса, что есть одна панацея.
Универсального рецепта не бывает. Пример Nubank говорит, что удачное сочетание технологий, орг.дизайна, мотивированных профи в команде и бизнес-модели может превратиться в локальное экономическое чудо в банковской отрасли. То есть не магия и не серебряная пуля, а конкретный выбор под конкретную боль. При этом надо отметить факт, что их косты на клиента действительно кратно меньше, чем у конкурентов.
Разве в статье утверждалось, что Datomic у Nubank - это HTAP-хранилище? Datomic им нужен не ради HTAP, а ради темпоральности и иммутабельности в операционном контуре и скорее в первую очередь там. Меньше боли в аудите, плюс воспроизводимость состояний клиента при отладке инцидентов и т.д. Они пишут на сайте про возможность запускать тяжёлые аналитические запросы через datalog прямо по datomic без влияния на OLTP и про использование Spark‑кластера для тяжёлой аналитики (https://www.datomic.com/nubanks-story.html).
Ваш комментарий дополняет статью, но не противоречит её тезисам. Особенно, если учесть что почти 10 лет назад в 2017 году у Datomic было больше ограничений, чем сегодня.
По официальному описанию Nubank в 2024 году пропускал в среднем около 2,5 миллиардов Datomic-транзакций в сутки и держал много независимых Datomic-баз на каждый домен/сервис, а не одну гигантскую базу. (https://blog.datomic.com/2024/05/Jepsen-tests-Datomic.html)
p.s. Как я уже написал в итогах статьи, всё же - "Главный урок Nubank не в Clojure и не в Datomic"
Как построить банк на 130 миллионов клиентов с помощью Clojure, иммутабельного графа и закона Конвея