Из чего состоит база данных, способная обрабатывать 7500 документов в секунду

Из чего состоит инфосистема

В системе «Честный знак» более 600 000 участников оборота: производители, импортеры, оптовики и розничные продавцы. Производитель заказывает уникальный код маркировки для каждой единицы выпускаемого товара, затем все участники оборота передают в систему информацию о движении этого товара. Конечная точка фиксации — выбытие товара из оборота. В 2022 году система обработала более 6,3 миллиарда электронных документов.

Есть мобильные приложения для покупателей, бизнеса и госорганов. Вся информация о товарах сводится в аналитический кластер, который создает срезы данных для участников оборота и контролирующих органов. Доступ к данным системы маркировки имеют более 5000 представителей 16 государственных органов.

Подобных масштабных систем в мире нет. В Испании и Франции пытались сделать маркировку экопродуктов, к нам приезжала делегация ЕАЭС в 2018 году для получения опыта. Они не верили, что мы запустимся, затем в 2019 году удивлялись работающей системе.

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

Технологические сложности системы

На текущий момент хранилища инфосистемы объединяют более 80 петабайт данных, ежегодный рост — 25%. Участники оборота ожидают скорость работы, близкую к реалтайм.

Какие сложности возникают при таких объемах:

• В рамках подсистемы выпуска кодов маркировки выполняется до 600 000 операций чтения-записи в секунду на одном кластере Cassandra. Это одно из самых высоко нагруженных мест системы.
• Участник оборота указывает в документе коды упаковки (например, коробов или палет), и первая сложность — это достроить дерево, получив весь набор уникальных кодов товара. Дерево может содержать до 22 млн кодов и иметь до 8 уровней вложенности. Далее нужно прочитать из хранилища историю движения каждого кода и провести необходимые проверки, после этого изменить состояние каждого из товаров и дополнить историю их движения.
• Одна из непростых задач — идемпотентность обработки документов. Мы должны получать одинаковый результат при повторной обработке документа, если условия обработки документа не изменились.

Архитектура хранилищ

Реляционные базы типа Postgres не подходят из-за сложностей масштабирования: на нашем количестве записей время на чтение и запись существенно возрастает. Поэтому мы сознательно строили систему на NoSQL-решениях.

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

При размере одной строки примерно в 1 Кб выигрыш при обновлении только пары полей в десятки байт будет очень существенным. Экономия на I/O начинается уже на этапе записи в write-ahead log, далее мы экономим за счет более рационального наполнения memstore и, соответственно, уменьшения количества сохранений на диск. А чем реже мы сохраняем на диск, тем реже запускается Compaction, и это еще больше экономит на I/O, потому что Compaction не только пишет, но и читает необходимые ему файлы. 

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

С учетом такого опыта дам рекомендации по хранению данных:

• Бороться за уменьшение объемов хранения на наших объемах данных — это важный шаг оптимизации затрат. Пустая запись в колонке занимает место в NoSQL, так как содержит название колонки. Когда записей в таблице сотни миллиардов, это существенно влияет на объем хранилища и стоимость хранения. Задача — правильно проектировать схему данных без излишеств, чтобы названия были короткими.
• Планировать, как размещать флаги и булевые значения. Мы храним их не как булевые, а как битовую маску. Все флаги, которые хочется сохранять на уровне одной записи, можно группировать в маски — тогда объемы и стоимость хранения сокращаются. 

• Не всегда нужно бороться за экономию места, особенно когда критичным параметром является скорость. Стандартный подход к хранению документов — S3 (Ceph, MiniO), однако при работе с большим количеством маленьких документов NoSQL выигрывает по скорости. На момент выбора хранилища (2020 год) Cassandra позволила нам сохранять до 5000 файлов размером до 16 Кб в секунду, когда MiniO — только 181 файл. Тесты проводились на одинаковом парке серверов. Мы используем Cassandra для хранения документов, так как нам необходима очень высокая скорость работы с документами. Однако мы понимаем, что это не совсем оптимально в точке репликации: S3-хранилища могут использовать алгоритм Erasure code и за счет этого экономить место.

Архитектура поиска

У нас был опыт использования индексов на HBase, но на больших скоростях записи индексы могут сломаться и оказаться неконсистентными. Перестройка индекса на наших объемах занимает дни, а иногда и недели — такие паузы мы не можем себе позволить. Поэтому в процессинге мы организовали работу с хранилищем только по сложносоставному ключу. Например, это может быть код маркировки, операция, уникальный номер документа, версия. Поиск по части ключа достаточно эффективен в большинстве NoSQL, однако в нашем опыте Cassandra опять же выигрывает.

Иногда сабсет данных нельзя найти по ключу — например, в рамках миграции. Тогда мы прибегаем к полному сканированию базы, но делаем это по ночам, когда база менее нагружена. Для аналитических исследований и подготовки более сложных миграций мы пользуемся отдельным хранилищем в аналитической платформе. Распределение нагрузки позволяет не конкурировать с процессингом за I/O и CPU.  

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

Преимущества открытого ПО

Мы сразу проектировали архитектуру инфосистемы на основе open source решений, чтобы убрать зависимость от западных вендоров. Какой стек технологий используем в качестве хранилищ:

• Cassandra;
• HBase;
• MongoDB;
• Postgres, Cockroach, CouchDB;
• Clickhouse;
• HDFS.

Чтобы строить архитектуру на open source, надо хорошо понимать используемый софт и уметь в нем разбираться самостоятельно, без поддержки крупного вендора. Информации в Сети достаточно много, но самый бесценный источник — это открытый код. Углубляясь в него и понимая архитектуру, мы можем находить уникальные решения и максимально эффективно работать с особенностями используемого хранилища. Как, например, в коде Cassandra мы нашли параметр, позволяющий увеличить таймаут Repair, так как на наших объемах он просто не успевал закончиться и сбрасывался. У нас есть эксперты, которые очень глубоко понимают используемые технологические решения. Мы вырастили сотрудников сами, под такие задачи на рынке специалистов не было.

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

Прогноз по открытому ПО

Систему начали строить в 2018 году, запустили в эксплуатацию в 2020 году, и с тех пор архитектура значительно поменялась: нагрузки выросли на два порядка. Мы нисколько не пожалели, что построили нашу систему на базе open source.

Он хорош тем, что с ним можно делать любые исследования, изучать и дорабатывать кодовую базу. Следующий этап нашего развития мы видим во внедрении машинного обучения. Его тоже строим на open source.

Если вы оказались в зависимости от западных вендоров, самое время искать альтернативы для перехода на открытые или российские решения. Текущий виток развития IT в РФ форсирует переход к построению процессов как на открытых международных, так и на открытых отечественных решениях. Здесь есть большой потенциал для развития и реализации серьезных проектов. Рынок ждет новых российских идей с открытым исходным кодом, и они точно будут появляться в ближайшие годы.