Комментарии 13
включили нагрузку и получили уже 14,5 тыс. транзакций в секунду.
Что там, внутри транзакций? Без этого трудно оценить, 14.5 в секунду- это много или мало.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам, также транзакционные данные (каждый их понимает по-своему, не судите строго) — например, сделки с внутренних и внешних площадок, котировки. Потом на основании этих данных строим интерфейсы пользователя и отчеты для внутренних и внешних клиентов. 14.5 тысяч в секунду в тесте было как раз транзакционных данных, довольно разнородных по своему размеру, справочные данные меняются не так часто, их в тесте не было, да и в целом их объем на несколько порядков меньше.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам
Это все в Тарантуле????
А какой движок?
быстрый memtx, который всё хранит в оперативке, или тот второй, где размер не ограничен, но он медленный.
не лучше ли было разнести их о разным платформам?
и можете рассказать про блок валидации по модели — а что если модель меняется? вы перегружаете весь кластер или только обновляется какая-то малая часть системы без прерывания работы?
Модель у нас меняется достаточно часто, добавляются новые сущности, которые мы начинаем к себе загружать и у себя хранить, расширяются имеющиеся. Применение модели у нас происходит одномоментно и сразу на весь кластер, тарантул позволяет в разумных пределах применять DDL неблокирующим образом, то есть мы применяем модель прямо под нагрузкой, во время работы. Отвечая на ваши вопросы, перезагрузка ноды тарантула для применения DDL не требуется, применяется быстро, недоступности не вызывает, может вызывать разве что краткосрочный рост времени отклика на один из запросов, попавших на ноду, которая в этот момент применяет DDL.
Тот же tarantool с каждой версией все лучше и лучше поддерживает SQL. И это ведь не зря, SQL отличный инструмент для работы с данными в базе данных, он ведь неспроста популярен. Да его можно заменить на Lua, но не факт что получится даже эффективнее, не говоря уже про понятнее и быстрее в разработке.
Вы правы про язык Lua, его простота накладывает определенный налог при построении больших систем. Те 30 тысяч строк, о которых шла речь в статье, они как раз состоят из большого числа отдельных небольших компонентов, и большая часть этих компонентов, как раз, относится к коду приведения объектов в единую модель. Соответственно отдельные части этого кода почти никак не связаны между собой, так как относятся к обработке не связанных между собой объектов. Небольшие общие части, как правило, какие-то служебные и вспомогательные функции, вынесены в отдельные общие разделяемые библиотеки, за счет этого удается поддерживать более-менее чистую и масштабируемую кодовую базу.
Тот факт, что для работы с данными, особенно для произвольных запросов и для исследования имеющихся данных, SQL нет равных — это неоспоримо. Но пока, к сожалению, тарантул поддерживает SQL только в рамках однонодовой конфигурации, то есть если у вас шардированный кластер из тарантулов, SQL использовать пока не получится. И в целом задача построения распределенного планировщика запросов — довольно нетривиальная задача. Понятнее и быстрее в разработке на Lua, конечно, не получается (в сравнении со скоростью написания выборки на SQL), зато удается получить полностью предсказуемое время работы запроса, и это время работы запроса не будет зависеть от того, какой метаинформацией о табличках обладает на текущий момент планировщик SQL, благодаря этому мы получаем полностью предсказуемое время отклика на разных нагрузках и объемах данных.
1) Этот код лежит в «монорепозитории» или таки разбит на части?
2) Какова процедура, схематично, «доставки» обновления исходников до production
Кода самой платформы за два года у нас накопилось достаточно много, для удобства разработки он побит на сабмодули и лежит в нескольких гит-репозиториях. В одном репозитории все сабмодули сводится воедино, оттуда запускается сборка.
Доставка у нас совсем простая. На всех нодах тарантула лежит одинаковый код, несмотря на это каждая нода реализует отдельную роль в кластере. Поэтому для обновления кода платформы мы подкладываем каждой ноде свежую версию кода на диск, далее поочередно их перезапускаем, делая своего рода rolling upgrade. Обновление мы делаем, как правило, в моменты наименьшей нагрузки, поэтому оно проходит незаметно для внешних потребителей. Бывают совсем большие релизы, не позволяющие делать rolling upgrade, для них мы согласовываем интервал сервисного времени с недоступностью.
Как мы делали ядро инвестиционного бизнеса «Альфа-Банка» на базе Tarantool