DBT - это отличный инструмент, который решает определенные задачи. Но все же функционал DBT не дает нам разработки кода и документации в одном месте. Мы не повторили чужой функционал, из-за оценочного суждения, а разработали свой подход, который закрыл нам наши проблемы с документацией и удобством разработки витрин. Инструмент активно и успешно используется несколькими большими командами продуктовой аналитики
1) Парсер разработала команда DE, и поддерживает его. Стоимость поддержки после реализации стремится к нулю.
2) Существующие инструменты не дали Нам сократить Time To Market, а скорее наоборот увеличили его. А также, вырастили кол-во плохо документируемых витрин. Поддержка этих витрин и есть техдолг, который решился сам после внедрения нашего подхода
Копайлот-помощник для аннотаций - это означает, что сначала делаем витрину, а описание "делаем потом". Каким бы не был хорошим копайлот - документация будет терять свою актуальность по мере активных доработок витрины. Мы пришли к своему решению именно после такой модели, в которой есть этот недостаток.
Если начинаешь разбираться со сложной витриной в DBT, то ищешь в yaml нужные колонки и читаешь описания, а затем - ищешь место в SQL где эти колонки собираются. Это не так удобно, как аннотации в коде. Нашел, то что нужно, и рядом есть контекст с описанием. Нужно что-то исправить? Сразу в одном месте исправляем код и документацию, это дает нашему инструменту преимущество перед другими подходами
Если написать SQL-код на 10К строк для итоговой таблицы с 400 колонками (это реальные цифры наших крупных таблиц), то заполнить yaml с описанием будет не так легко. Написать аннотации в процессе разработки SQL гораздо проще и удобнее. Это принципиальное отличие в подходах, решение ранее не существовало
Фреймфорк использует аннотации в sql, это ключевое отличие от dbt. Именно это делает разработку витрин и документации неразрывным и единым процессом.
Тесты запускаются через gitlab/ci перед влитием.
Для бизнеса - это заметное влияние на Time To Market. В актуальных витринах легко и удобно искать то, что нужно для большинства задач по отчетности. Большинство витрин разрабатываются и дополняются продуктовыми аналитиками без команды DE, никто никого не ждет.
Качественная документация - это мощный материал для LLM моделей и ai-ассистентов, которые уже неплохо умеют text-to-sql. Это дает еще больше возможностей для продуктовых исследований
nekufa 10 тыс. пуш-уведомлений в секунду — это нагрузка с нашего продакшен на момент написания статьи.
Это вовсе не означает, что в нет запаса на рост нагрузки.
А еще не могли бы тогда уточнить как вы измеряли? Сообщения какого размера использовали?
Время ожидания feedback'а сюда не входит.
На графике показано суммарное время на обработку сообщения, т.е. не только отправка в сокет.
Для отправки сообщения нужно сходить в тарантул, сделать проверки, сформировать json, упаковать и отправить бинарные данные в ios.
Время обработки ухудшилось из-за проблем с proxy, желтый график без прокси — на нем время хорошее.
Сейчас суммарное время составляет 3-4мс.
Рестарт tarantool длился «минуты», 10-15 минут, не больше, предварительно нужно было сделать снапшот, это еще 10-15 минут, точнее время не назову. Во время снапшота — мастер работает и доступен на запись.
На сервере с tarantool память вся отдана ему. Других процессов нет.
Да ~12k — 15k уведомлений в секунду рассылают 8 серверов:
Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
24 ядра
памяти — 32Гб
жесткие диски — обычные sata
Про лимитирующий фактор не совсем понял, поясните чуть подробнее что имелось ввиду?
В основном у нас кейсы не сортировкой, а с поиском по разным полям.
Там где нужен быстрый поиск — создаем индекс. Если операция редкая — используем full scan по primary key.
Если результирующая выборка небольшая, то сортировать можно в «питоне».
У tarantool 1.6, 1.7, 1.8 — одинаковый протокол с msgpack внутри.
Думаю сложностей быть не должно.
Кроме sql еще много всего интересного, например движок винил.
Было бы интересно попробовать его для хранения данных.
А как вы собираетесь весь процесор на python занять без fork?
redis вас тут тоже не спасет.
> Нет, проблема явно не в этом: отключите запись на диск в tarantool, и запустите свой бенчмарк для сравнения.
Внутри gtarantool запросы группируются в пачки, несколько запросов в отдельном гринлете отправляются через один вызов soket.send. В отдельном гринлете из сокета вычитываются несколько ответов за один soket.recv.
Ну уже видно, что gtarantool в 10 гринлетов быстрее чем обычный синхронный коннектор!
Подберите оптимальное кол-во гринлетов, а если питон утилизировал 1 ядро cpu на 100%, то делайте fork и грузите тарантул больше.
Еще вы сравниваете insert в tarantool и insert в redis, под капотом это немного различные вещи.
Запись на диск или в память. Ваш тест не ждет когда redis синканет все данные на диск.
Сравните разницу на select-ах в gtarantool и redis.
Сделайте несколько гринлетов, и выполняйте insert через общий tarantool-connection.
Можно посмотреть кейсы для gevent: https://habrahabr.ru/company/mailru/blog/254727/
Рассылку новости инициирует редактор через админку, от админки сайта приходит http-запрос, и если HTTP 200 ОК, то начинается рассылка пуш-уведомлений. Также http-запрос может быть автоматически отправлен на другой доступный сервер.
Что если сообщение было успешно отправлено на следующий сервер, но не было там обработано из-за того, что сервер упал?
Да, будет нужно ждать пока сервер поднимут.
Тогда можно сделать отдельную очередь для таких «эстафетных» сообщений, и в случае падения сервера с такой очередью активировать ее где-то автоматически. Подумаю о такой фиче.
DBT - это отличный инструмент, который решает определенные задачи. Но все же функционал DBT не дает нам разработки кода и документации в одном месте. Мы не повторили чужой функционал, из-за оценочного суждения, а разработали свой подход, который закрыл нам наши проблемы с документацией и удобством разработки витрин. Инструмент активно и успешно используется несколькими большими командами продуктовой аналитики
1) Парсер разработала команда DE, и поддерживает его. Стоимость поддержки после реализации стремится к нулю.
2) Существующие инструменты не дали Нам сократить Time To Market, а скорее наоборот увеличили его. А также, вырастили кол-во плохо документируемых витрин.
Поддержка этих витрин и есть техдолг, который решился сам после внедрения нашего подхода
Копайлот-помощник для аннотаций - это означает, что сначала делаем витрину, а описание "делаем потом". Каким бы не был хорошим копайлот - документация будет терять свою актуальность по мере активных доработок витрины. Мы пришли к своему решению именно после такой модели, в которой есть этот недостаток.
Если начинаешь разбираться со сложной витриной в DBT, то ищешь в yaml нужные колонки и читаешь описания, а затем - ищешь место в SQL где эти колонки собираются. Это не так удобно, как аннотации в коде.
Нашел, то что нужно, и рядом есть контекст с описанием. Нужно что-то исправить? Сразу в одном месте исправляем код и документацию, это дает нашему инструменту преимущество перед другими подходами
Если написать SQL-код на 10К строк для итоговой таблицы с 400 колонками (это реальные цифры наших крупных таблиц), то заполнить yaml с описанием будет не так легко. Написать аннотации в процессе разработки SQL гораздо проще и удобнее. Это принципиальное отличие в подходах, решение ранее не существовало
Фреймфорк использует аннотации в sql, это ключевое отличие от dbt. Именно это делает разработку витрин и документации неразрывным и единым процессом.
Тесты запускаются через gitlab/ci перед влитием.
Для бизнеса - это заметное влияние на Time To Market. В актуальных витринах легко и удобно искать то, что нужно для большинства задач по отчетности. Большинство витрин разрабатываются и дополняются продуктовыми аналитиками без команды DE, никто никого не ждет.
Качественная документация - это мощный материал для LLM моделей и ai-ассистентов, которые уже неплохо умеют text-to-sql. Это дает еще больше возможностей для продуктовых исследований
Про потыкать - есть планы, надеюсь мы расскажем про них отдельно немного позже
Спасибо!
Да, как то не получилось коротко) тема объемная.
Надеюсь новичок утонет до статьи, и будет выплывать по тихоньку, куда деваться)
Это вовсе не означает, что в нет запаса на рост нагрузки.
А еще не могли бы тогда уточнить как вы измеряли? Сообщения какого размера использовали?
На графике показано суммарное время на обработку сообщения, т.е. не только отправка в сокет.
Для отправки сообщения нужно сходить в тарантул, сделать проверки, сформировать json, упаковать и отправить бинарные данные в ios.
Время обработки ухудшилось из-за проблем с proxy, желтый график без прокси — на нем время хорошее.
Сейчас суммарное время составляет 3-4мс.
На сервере с tarantool память вся отдана ему. Других процессов нет.
Да ~12k — 15k уведомлений в секунду рассылают 8 серверов:
Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
24 ядра
памяти — 32Гб
жесткие диски — обычные sata
Про лимитирующий фактор не совсем понял, поясните чуть подробнее что имелось ввиду?
Там где нужен быстрый поиск — создаем индекс. Если операция редкая — используем full scan по primary key.
Если результирующая выборка небольшая, то сортировать можно в «питоне».
Думаю сложностей быть не должно.
Кроме sql еще много всего интересного, например движок винил.
Было бы интересно попробовать его для хранения данных.
А как вы собираетесь весь процесор на python занять без fork?
redis вас тут тоже не спасет.
> Нет, проблема явно не в этом:
отключите запись на диск в tarantool, и запустите свой бенчмарк для сравнения.
Внутри gtarantool запросы группируются в пачки, несколько запросов в отдельном гринлете отправляются через один вызов soket.send. В отдельном гринлете из сокета вычитываются несколько ответов за один soket.recv.
Подберите оптимальное кол-во гринлетов, а если питон утилизировал 1 ядро cpu на 100%, то делайте fork и грузите тарантул больше.
Еще вы сравниваете insert в tarantool и insert в redis, под капотом это немного различные вещи.
Запись на диск или в память. Ваш тест не ждет когда redis синканет все данные на диск.
Сравните разницу на select-ах в gtarantool и redis.
Можно посмотреть кейсы для gevent: https://habrahabr.ru/company/mailru/blog/254727/
Да, будет нужно ждать пока сервер поднимут.
Тогда можно сделать отдельную очередь для таких «эстафетных» сообщений, и в случае падения сервера с такой очередью активировать ее где-то автоматически. Подумаю о такой фиче.