Comments 13
Очень интересно, но не совсем понятно, что делает эта система — какие конкретно данные на входе, какие на выходе. Ясно, что это все связанно с инвестиционным бизнесом, но этого мало.
Что там, внутри транзакций? Без этого трудно оценить, 14.5 в секунду- это много или мало.
включили нагрузку и получили уже 14,5 тыс. транзакций в секунду.
Что там, внутри транзакций? Без этого трудно оценить, 14.5 в секунду- это много или мало.
Спасибо за хороший отзыв.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам, также транзакционные данные (каждый их понимает по-своему, не судите строго) — например, сделки с внутренних и внешних площадок, котировки. Потом на основании этих данных строим интерфейсы пользователя и отчеты для внутренних и внешних клиентов. 14.5 тысяч в секунду в тесте было как раз транзакционных данных, довольно разнородных по своему размеру, справочные данные меняются не так часто, их в тесте не было, да и в целом их объем на несколько порядков меньше.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам, также транзакционные данные (каждый их понимает по-своему, не судите строго) — например, сделки с внутренних и внешних площадок, котировки. Потом на основании этих данных строим интерфейсы пользователя и отчеты для внутренних и внешних клиентов. 14.5 тысяч в секунду в тесте было как раз транзакционных данных, довольно разнородных по своему размеру, справочные данные меняются не так часто, их в тесте не было, да и в целом их объем на несколько порядков меньше.
Система создавалась для того, чтобы занять центральное место в инфраструктуре инвестиционного бизнеса банка в части хранения данных, поэтому мы загружаем в нее справочные данные, например, описание продуктов, данные по договорам с контрагентами, информацию по контрагентам, информацию по рыночным инструментам
Это все в Тарантуле????
А какой движок?
быстрый memtx, который всё хранит в оперативке, или тот второй, где размер не ограничен, но он медленный.
UFO just landed and posted this here
Apache Avro показался нам более удобным для описания модели с точки зрения человека, который эти модели строит, нежели чем моделировать предметную область сразу на схемах GraphQL. Мы также сделали для себя небольшие, обратно совместимые с базовым стандартом расширения Apache Avro, которые позволяют нам добавить немного концепций domain driven design в Apache Avro, а также описать связи между сущностями. В итоге на основании модели, описанной на Apache Avro, мы генерируем DDL для спейсов тарантула, а также генерируем GraphQL схему, на деле все получилось довольно просто.
UFO just landed and posted this here
У нас была попытка использовать редактор для работы с Apache Avro, мы некоторое время использовали ArchiMate. Из коробки он Apache Avro не поддерживал, но файлы, в которые сохраняются проекты ArchiMate — довольно простой структуры XML, мы сделали для себя конвертер из ArchiMate в Apache Avro. Но как-то не прижилось, редактировать и сопровождать plain-text Apache Avro оказалось не сильно сложнее (текущие ~3 тысячи строк с моделью), пока так и живем. Из нашего опыта на отдельную статью пока материала не набрать, единственное что могу посоветовать — структурировать модель, снабжать комментариями и описаниями. Но если вдруг до чего-то большего дорастем — обязательно напишу и поделюсь :)
насколько оправдано было решение строить все на одной платформе, где совмещаются как OLTP, так и OLAP нагрузки?
не лучше ли было разнести их о разным платформам?
и можете рассказать про блок валидации по модели — а что если модель меняется? вы перегружаете весь кластер или только обновляется какая-то малая часть системы без прерывания работы?
не лучше ли было разнести их о разным платформам?
и можете рассказать про блок валидации по модели — а что если модель меняется? вы перегружаете весь кластер или только обновляется какая-то малая часть системы без прерывания работы?
Как таковой OLAP нагрузки в прямом смысле у нас нет, то есть те отчеты, которые я упоминал в статье, это довольно простые отчеты, которые не связаны с аналитикой данных, например, позиционный отчет для трейдера, который который отражает балансы бумаг и денег в заранее определенных разрезах. Произвольных запросов за аналитикой по данным у нас тоже нет, то есть наша система почти полностью OLTP, для OLAP нагрузки у нас в банке, разумеется, есть отдельные хранилища, куда сгружается вся необходимая информация. Делать в одном месте OLAP и OLTP, безусловно, не самая лучшая идея.
Модель у нас меняется достаточно часто, добавляются новые сущности, которые мы начинаем к себе загружать и у себя хранить, расширяются имеющиеся. Применение модели у нас происходит одномоментно и сразу на весь кластер, тарантул позволяет в разумных пределах применять DDL неблокирующим образом, то есть мы применяем модель прямо под нагрузкой, во время работы. Отвечая на ваши вопросы, перезагрузка ноды тарантула для применения DDL не требуется, применяется быстро, недоступности не вызывает, может вызывать разве что краткосрочный рост времени отклика на один из запросов, попавших на ноду, которая в этот момент применяет DDL.
Модель у нас меняется достаточно часто, добавляются новые сущности, которые мы начинаем к себе загружать и у себя хранить, расширяются имеющиеся. Применение модели у нас происходит одномоментно и сразу на весь кластер, тарантул позволяет в разумных пределах применять DDL неблокирующим образом, то есть мы применяем модель прямо под нагрузкой, во время работы. Отвечая на ваши вопросы, перезагрузка ноды тарантула для применения DDL не требуется, применяется быстро, недоступности не вызывает, может вызывать разве что краткосрочный рост времени отклика на один из запросов, попавших на ноду, которая в этот момент применяет DDL.
Отсутствие SQL это конечно очень похоже на рекламное утверждение. Ну тоесть вот нет у вас SQL, зато есть 30 тыс. строк кода на Lua. Lua отличный, простой, понятный язык, не перегруженный лишним. Но делался он в первую очередь как встраиваемый, для того чтобы писать совсем небольшие скрипты. 30 тыс. строк это уже не небольшие скрипты. Врядли это хорошо, удобно, и эффективно поддерживается, такая большая кодовая база на таком неболшой скриптовом языке.
Тот же tarantool с каждой версией все лучше и лучше поддерживает SQL. И это ведь не зря, SQL отличный инструмент для работы с данными в базе данных, он ведь неспроста популярен. Да его можно заменить на Lua, но не факт что получится даже эффективнее, не говоря уже про понятнее и быстрее в разработке.
Тот же tarantool с каждой версией все лучше и лучше поддерживает SQL. И это ведь не зря, SQL отличный инструмент для работы с данными в базе данных, он ведь неспроста популярен. Да его можно заменить на Lua, но не факт что получится даже эффективнее, не говоря уже про понятнее и быстрее в разработке.
Не хотелось постулировать (и тем более рекламировать) отсутствие SQL как какое-либо преимущество, скорее хотелось сказать, что в системах определенного класса без него можно вполне себе нормально жить, просто большинство людей из моей практики считает, что без SQL жизни нет.
Вы правы про язык Lua, его простота накладывает определенный налог при построении больших систем. Те 30 тысяч строк, о которых шла речь в статье, они как раз состоят из большого числа отдельных небольших компонентов, и большая часть этих компонентов, как раз, относится к коду приведения объектов в единую модель. Соответственно отдельные части этого кода почти никак не связаны между собой, так как относятся к обработке не связанных между собой объектов. Небольшие общие части, как правило, какие-то служебные и вспомогательные функции, вынесены в отдельные общие разделяемые библиотеки, за счет этого удается поддерживать более-менее чистую и масштабируемую кодовую базу.
Тот факт, что для работы с данными, особенно для произвольных запросов и для исследования имеющихся данных, SQL нет равных — это неоспоримо. Но пока, к сожалению, тарантул поддерживает SQL только в рамках однонодовой конфигурации, то есть если у вас шардированный кластер из тарантулов, SQL использовать пока не получится. И в целом задача построения распределенного планировщика запросов — довольно нетривиальная задача. Понятнее и быстрее в разработке на Lua, конечно, не получается (в сравнении со скоростью написания выборки на SQL), зато удается получить полностью предсказуемое время работы запроса, и это время работы запроса не будет зависеть от того, какой метаинформацией о табличках обладает на текущий момент планировщик SQL, благодаря этому мы получаем полностью предсказуемое время отклика на разных нагрузках и объемах данных.
Вы правы про язык Lua, его простота накладывает определенный налог при построении больших систем. Те 30 тысяч строк, о которых шла речь в статье, они как раз состоят из большого числа отдельных небольших компонентов, и большая часть этих компонентов, как раз, относится к коду приведения объектов в единую модель. Соответственно отдельные части этого кода почти никак не связаны между собой, так как относятся к обработке не связанных между собой объектов. Небольшие общие части, как правило, какие-то служебные и вспомогательные функции, вынесены в отдельные общие разделяемые библиотеки, за счет этого удается поддерживать более-менее чистую и масштабируемую кодовую базу.
Тот факт, что для работы с данными, особенно для произвольных запросов и для исследования имеющихся данных, SQL нет равных — это неоспоримо. Но пока, к сожалению, тарантул поддерживает SQL только в рамках однонодовой конфигурации, то есть если у вас шардированный кластер из тарантулов, SQL использовать пока не получится. И в целом задача построения распределенного планировщика запросов — довольно нетривиальная задача. Понятнее и быстрее в разработке на Lua, конечно, не получается (в сравнении со скоростью написания выборки на SQL), зато удается получить полностью предсказуемое время работы запроса, и это время работы запроса не будет зависеть от того, какой метаинформацией о табличках обладает на текущий момент планировщик SQL, благодаря этому мы получаем полностью предсказуемое время отклика на разных нагрузках и объемах данных.
Интересно, а как осуществляется обновление IB-Core? Там же вроде прилично кода должно быть.
1) Этот код лежит в «монорепозитории» или таки разбит на части?
2) Какова процедура, схематично, «доставки» обновления исходников до production
1) Этот код лежит в «монорепозитории» или таки разбит на части?
2) Какова процедура, схематично, «доставки» обновления исходников до production
Кода самой платформы за два года у нас накопилось достаточно много, для удобства разработки он побит на сабмодули и лежит в нескольких гит-репозиториях. В одном репозитории все сабмодули сводится воедино, оттуда запускается сборка.
Доставка у нас совсем простая. На всех нодах тарантула лежит одинаковый код, несмотря на это каждая нода реализует отдельную роль в кластере. Поэтому для обновления кода платформы мы подкладываем каждой ноде свежую версию кода на диск, далее поочередно их перезапускаем, делая своего рода rolling upgrade. Обновление мы делаем, как правило, в моменты наименьшей нагрузки, поэтому оно проходит незаметно для внешних потребителей. Бывают совсем большие релизы, не позволяющие делать rolling upgrade, для них мы согласовываем интервал сервисного времени с недоступностью.
Sign up to leave a comment.
Как мы делали ядро инвестиционного бизнеса «Альфа-Банка» на базе Tarantool