В конце сентября Филипп Дельгядо, один из архитекторов карточного процессинга Lekton Sigma, выступил на Yandex Neuro Scale. На конференции он рассказал, как они с командой добавляли поддержку YDB к своему решению.

Под катом — интервью с Филиппом, где он поделился с нами ключевыми техническими моментами, которые видит интересными для широкой аудитории Хабра: зачем в принципе добавлять поддержку ещё одной базы данных, сколько разработчиков нужно, чтобы вкрутить лампочку всё запилить, и с какими сложностями они столкнутся при переходе от централизованной PostgreSQL к распределённой YDB.

Зачем может понадобиться больше одной СУБД

Q: Филипп, прежде чем перейти к базам данных, расскажи немного о Lekton Sigma. Что это такое, для чего используется и какие требования выдвигает к СУБД?

Lekton Sigma — коробочное решение для реализации процессинга платежей: от эмиссии карт до приёма эквайринговых платежей. Обычно оно разворачивается на железе клиента.

Архитектурно Lekton Sigma состоит из нескольких десятков довольно крупных сервисов, которые написаны на Kotlin, используют Kafka и HTTP в качестве транспорта, ClickHouse для аналитики и собственный отдельный слой Agnostic для работы с данными. Вся система горизонтально масштабируется.

Agnostic позволяет нам абстрагироваться от конкретной используемой СУБД. Каждый сервис работает с «документоориентированной СУБД» Agnostic, которая обеспечивает эффективный доступ и гарантии ACID. Agnostic также реализует всю необходимую нашим разработчикам функциональность, используя возможности конкретной СУБД.

Agnostic не только предоставляет интерфейс для работы со сложными объектами, но и берёт на себя инфраструктурные задачи, включая сложное индексирование данных, шифрование и контроль доступа там, где это необходимо.

Поскольку транзакционные данные накапливаются очень быстро, Agnostic реализует функции housekeeping, аккуратно удаляя из оперативной базы старые данные. Кроме того, Agnostic обеспечивает гарантии при работе с Kafka и поддержку обновлений данных (при изменении схемы) без останова.

Q: Какие СУБД вы уже поддерживали и почему решили добавить ещё одну?

Разумеется, Agnostic поддерживает PostgreSQL. Это простая, понятная СУБД, для которой легко найти поддержку как в платном, так и в бесплатном варианте использования. Но PostgreSQL не очень удобна для работы с крупными базами данных (больше 1–2 терабайт), а некоторым нашим клиентам нужно работать с десятками терабайт.

Для таких случаев мы поддерживаем вторую СУБД — FoundationDB. Очень надёжное key-value опенсорс-решение с горизонтальным масштабированием и ACID-транзакциями. Когда Кайла Кингсбери, автора известного теста Jepsen, спросили, почему он не проводит тестирования FoundationDB, то он ответил, что просто не сможет найти ничего нового.

Совершенно неубиваемая СУБД, у которой всего два минуса. Во-первых, это очень низкоуровневое key-value-решение, где администратор не может даже посмотреть на таблицы. А во-вторых, она не очень известна в России, хотя наша компания и предоставляет полноценную поддержку этой СУБД, а коммиты наших сотрудников принимаются в основной код FoundationDB.

Поэтому мы решили добавить ещё одну СУБД, которая бы стала промежуточным решением. Важно, чтобы она была простой в использовании и достаточно популярной, но при этом хорошо горизонтально масштабировалась на десятки терабайт данных.

Мы выбрали YDB, потому что, на первый взгляд, это было идеальное решение: реляционная база данных, привычный SQL. Мы думали, что можно будет взять код для PostgreSQL и за неделю добавить поддержку YDB.

Увы, реальность оказалась не такой прекрасной, и нам потребовалось целых три недели на эту задачу.

YDB — это не PostgreSQL

Q: Расскажи, как проходила интеграция. Какие интересные возможности YDB вы использовали?

В YDB есть прекрасная возможность массовых операций (BatchAPI). Мы очень любим батчинг: это часто позволяет увеличить эффективность системы в несколько раз — и мы не могли пройти мимо.

На тот момент для применения батчинга было необходимо использовать нативный SDK для работы с YDB, поэтому все наши наработки для PostgreSQL пришлось сразу отбросить. Выяснилось, что YDB очень любит строгую типизацию данных в запросах, и при реализации батчинга это приводило к большому количеству лишнего кода. Да и сообщения об ошибках типизации были непонятными и неочевидными.

Большая часть кода Sigma написана на Kotlin, и мы очень любим корутины и асинхронное выполнение. К счастью, драйвер YDB поддерживает асинхронное выполнение запросов, хотя и адаптированное для Java. Мы устали описывать весьма сложные политики повтора запросов для разных возможных отказов на CompletableFuture — и написали собственную реализацию RetryContext.

Администрирование YDB

Q: Как распределённая природа YDB отразилась на администрировании?

Когда мы тестировали YBD в облаке, то удивились большому разбросу времени выполнения запроса. Выяснили, что в распределённой на несколько разных дата-центров базе клиент подключался к произвольному доступному шарду, который мог находиться на весьма далёком сервере. Это и приводило к большим задержкам. Чтобы частично исправить ситуацию, можно аккуратно настроить клиентское приложение и конфигурацию СУБД, но некоторые проблемы всё равно останутся. Для большинства приложений подобные задержки не очень важны, но на результатах наших нагрузочных тестов они сказывались достаточно заметно.

Наша команда нагрузочного тестирования много работает с PostgreSQL и Oracle и привыкла к централизованным отчётам о производительности. Увы, в YDB пока нет подобного инструмента, а он очень удобен для общения с командой поддержки YDB и для оценки результатов изменения каких-либо конфигурационных параметров. И хотя все нужные нам данные можно собрать из внутренних вьюшек и процедур, пришлось научиться самим собирать общий отчёт.

Q: Как вы тестировали нагрузку?

Для полноценного тестирования мы собрали собственный небольшой кластер, размещённый в трёх дата-центрах с низким временем отклика между ними. В результате мы получили более 1500 бизнес-транзакций в секунду. Каждая транзакция — это авторизация платежа (от запроса с POS до ответа) с проверкой данных карты, тарификацией, изменениями счётчиков и т. п. Могли бы получить больше, но начали упираться уже не в базу данных, а в ресурсы, выделенные на наши собственные продуктовые сервисы:

Общие впечатления

Q: Если резюмировать опыт твоей команды для читателей Хабра, что бы ты хотел отметить в использовании YDB?

Очень порадовала команда поддержки Яндекса. Без них мы точно не успели бы так быстро добавить поддержку YDB и не получили бы такие результаты на тестовом стенде.

Разработчиков очень порадовала простота работы с СУБД. Можно быстро запустить Docker-образ на своём ноутбуке, есть удобный веб-интерфейс со всем необходимым.

Разумеется, были трудности и неудобства, большинство из которых я упомянул. Но все эти проблемы не вызвали существенных сложностей. Да, разработка под YDB требует аккуратности, внимания и понимания того, что вы делаете. Это не привычная PostgreSQL или Oracle, а немного другая система, и знакомые подходы могут не сработать.

Не все интересные нам фишки YDB мы успели попробовать. Сейчас мы активно экспериментируем с YDB Topics. Topics являются частью YDB и поддерживают транзакционную целостность, поэтому, используя их вместо Kafka, можно будет выкинуть кучу нашего кода, обеспечивающего гарантии. А ещё мы планируем попробовать колоночное хранилище. Это позволит значительно уменьшить объём хранимых данных, а может быть, отказаться от ClickHouse и использовать в нашем продукте одну СУБД для всех задач.

В комментариях я готов обсудить YDB, а также другие вопросы архитектуры финтеха и платёжных систем.