Кода самой платформы за два года у нас накопилось достаточно много, для удобства разработки он побит на сабмодули и лежит в нескольких гит-репозиториях. В одном репозитории все сабмодули сводится воедино, оттуда запускается сборка.
Доставка у нас совсем простая. На всех нодах тарантула лежит одинаковый код, несмотря на это каждая нода реализует отдельную роль в кластере. Поэтому для обновления кода платформы мы подкладываем каждой ноде свежую версию кода на диск, далее поочередно их перезапускаем, делая своего рода rolling upgrade. Обновление мы делаем, как правило, в моменты наименьшей нагрузки, поэтому оно проходит незаметно для внешних потребителей. Бывают совсем большие релизы, не позволяющие делать rolling upgrade, для них мы согласовываем интервал сервисного времени с недоступностью.
У нас была попытка использовать редактор для работы с Apache Avro, мы некоторое время использовали ArchiMate. Из коробки он Apache Avro не поддерживал, но файлы, в которые сохраняются проекты ArchiMate — довольно простой структуры XML, мы сделали для себя конвертер из ArchiMate в Apache Avro. Но как-то не прижилось, редактировать и сопровождать plain-text Apache Avro оказалось не сильно сложнее (текущие ~3 тысячи строк с моделью), пока так и живем. Из нашего опыта на отдельную статью пока материала не набрать, единственное что могу посоветовать — структурировать модель, снабжать комментариями и описаниями. Но если вдруг до чего-то большего дорастем — обязательно напишу и поделюсь :)
Не хотелось постулировать (и тем более рекламировать) отсутствие SQL как какое-либо преимущество, скорее хотелось сказать, что в системах определенного класса без него можно вполне себе нормально жить, просто большинство людей из моей практики считает, что без SQL жизни нет.
Вы правы про язык Lua, его простота накладывает определенный налог при построении больших систем. Те 30 тысяч строк, о которых шла речь в статье, они как раз состоят из большого числа отдельных небольших компонентов, и большая часть этих компонентов, как раз, относится к коду приведения объектов в единую модель. Соответственно отдельные части этого кода почти никак не связаны между собой, так как относятся к обработке не связанных между собой объектов. Небольшие общие части, как правило, какие-то служебные и вспомогательные функции, вынесены в отдельные общие разделяемые библиотеки, за счет этого удается поддерживать более-менее чистую и масштабируемую кодовую базу.
Тот факт, что для работы с данными, особенно для произвольных запросов и для исследования имеющихся данных, SQL нет равных — это неоспоримо. Но пока, к сожалению, тарантул поддерживает SQL только в рамках однонодовой конфигурации, то есть если у вас шардированный кластер из тарантулов, SQL использовать пока не получится. И в целом задача построения распределенного планировщика запросов — довольно нетривиальная задача. Понятнее и быстрее в разработке на Lua, конечно, не получается (в сравнении со скоростью написания выборки на SQL), зато удается получить полностью предсказуемое время работы запроса, и это время работы запроса не будет зависеть от того, какой метаинформацией о табличках обладает на текущий момент планировщик SQL, благодаря этому мы получаем полностью предсказуемое время отклика на разных нагрузках и объемах данных.
Как таковой OLAP нагрузки в прямом смысле у нас нет, то есть те отчеты, которые я упоминал в статье, это довольно простые отчеты, которые не связаны с аналитикой данных, например, позиционный отчет для трейдера, который который отражает балансы бумаг и денег в заранее определенных разрезах. Произвольных запросов за аналитикой по данным у нас тоже нет, то есть наша система почти полностью OLTP, для OLAP нагрузки у нас в банке, разумеется, есть отдельные хранилища, куда сгружается вся необходимая информация. Делать в одном месте OLAP и OLTP, безусловно, не самая лучшая идея.
Модель у нас меняется достаточно часто, добавляются новые сущности, которые мы начинаем к себе загружать и у себя хранить, расширяются имеющиеся. Применение модели у нас происходит одномоментно и сразу на весь кластер, тарантул позволяет в разумных пределах применять DDL неблокирующим образом, то есть мы применяем модель прямо под нагрузкой, во время работы. Отвечая на ваши вопросы, перезагрузка ноды тарантула для применения DDL не требуется, применяется быстро, недоступности не вызывает, может вызывать разве что краткосрочный рост времени отклика на один из запросов, попавших на ноду, которая в этот момент применяет DDL.
Apache Avro показался нам более удобным для описания модели с точки зрения человека, который эти модели строит, нежели чем моделировать предметную область сразу на схемах GraphQL. Мы также сделали для себя небольшие, обратно совместимые с базовым стандартом расширения Apache Avro, которые позволяют нам добавить немного концепций domain driven design в Apache Avro, а также описать связи между сущностями. В итоге на основании модели, описанной на Apache Avro, мы генерируем DDL для спейсов тарантула, а также генерируем GraphQL схему, на деле все получилось довольно просто.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам, также транзакционные данные (каждый их понимает по-своему, не судите строго) — например, сделки с внутренних и внешних площадок, котировки. Потом на основании этих данных строим интерфейсы пользователя и отчеты для внутренних и внешних клиентов. 14.5 тысяч в секунду в тесте было как раз транзакционных данных, довольно разнородных по своему размеру, справочные данные меняются не так часто, их в тесте не было, да и в целом их объем на несколько порядков меньше.
Кода самой платформы за два года у нас накопилось достаточно много, для удобства разработки он побит на сабмодули и лежит в нескольких гит-репозиториях. В одном репозитории все сабмодули сводится воедино, оттуда запускается сборка.
Доставка у нас совсем простая. На всех нодах тарантула лежит одинаковый код, несмотря на это каждая нода реализует отдельную роль в кластере. Поэтому для обновления кода платформы мы подкладываем каждой ноде свежую версию кода на диск, далее поочередно их перезапускаем, делая своего рода rolling upgrade. Обновление мы делаем, как правило, в моменты наименьшей нагрузки, поэтому оно проходит незаметно для внешних потребителей. Бывают совсем большие релизы, не позволяющие делать rolling upgrade, для них мы согласовываем интервал сервисного времени с недоступностью.
Вы правы про язык Lua, его простота накладывает определенный налог при построении больших систем. Те 30 тысяч строк, о которых шла речь в статье, они как раз состоят из большого числа отдельных небольших компонентов, и большая часть этих компонентов, как раз, относится к коду приведения объектов в единую модель. Соответственно отдельные части этого кода почти никак не связаны между собой, так как относятся к обработке не связанных между собой объектов. Небольшие общие части, как правило, какие-то служебные и вспомогательные функции, вынесены в отдельные общие разделяемые библиотеки, за счет этого удается поддерживать более-менее чистую и масштабируемую кодовую базу.
Тот факт, что для работы с данными, особенно для произвольных запросов и для исследования имеющихся данных, SQL нет равных — это неоспоримо. Но пока, к сожалению, тарантул поддерживает SQL только в рамках однонодовой конфигурации, то есть если у вас шардированный кластер из тарантулов, SQL использовать пока не получится. И в целом задача построения распределенного планировщика запросов — довольно нетривиальная задача. Понятнее и быстрее в разработке на Lua, конечно, не получается (в сравнении со скоростью написания выборки на SQL), зато удается получить полностью предсказуемое время работы запроса, и это время работы запроса не будет зависеть от того, какой метаинформацией о табличках обладает на текущий момент планировщик SQL, благодаря этому мы получаем полностью предсказуемое время отклика на разных нагрузках и объемах данных.
Модель у нас меняется достаточно часто, добавляются новые сущности, которые мы начинаем к себе загружать и у себя хранить, расширяются имеющиеся. Применение модели у нас происходит одномоментно и сразу на весь кластер, тарантул позволяет в разумных пределах применять DDL неблокирующим образом, то есть мы применяем модель прямо под нагрузкой, во время работы. Отвечая на ваши вопросы, перезагрузка ноды тарантула для применения DDL не требуется, применяется быстро, недоступности не вызывает, может вызывать разве что краткосрочный рост времени отклика на один из запросов, попавших на ноду, которая в этот момент применяет DDL.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам, также транзакционные данные (каждый их понимает по-своему, не судите строго) — например, сделки с внутренних и внешних площадок, котировки. Потом на основании этих данных строим интерфейсы пользователя и отчеты для внутренних и внешних клиентов. 14.5 тысяч в секунду в тесте было как раз транзакционных данных, довольно разнородных по своему размеру, справочные данные меняются не так часто, их в тесте не было, да и в целом их объем на несколько порядков меньше.