Как быть, если компания не OpenAI и бурно растет и нарезать производительные нод проще, чем купить выделенный мощный сервер? И в случае необходимости добавить к ним еще одну или две ноды? А как обеспечить отказоустойчивость с околонулевыми RPO\RTO с одним писателем? А как быть если все-таки уперлись на доступной физике в потолок производительности? Всё по-быстрому переписать с нуля, главное чтобы бизнес не заметил? Парадигма взаимодействия с бд и с p2p или pub\sub системами различна. Возомжно, универсальные комбайны хороши. Вот только бы кто-то обозначил границы их применимости в зависимости от нагрузки и требований по надежности.
Подскажите пожалуйста, какие есть планы на шардирование этих очередей? Будет ли этот функционал только в PostgresPro или появится и в shardman тоже? Какой выбран протокол взаимодействия с очередями?
P.S.: ваш пример в ачале статьи с транзакионным разрывом между брокером и бд некорректен: все зависит от последовательности "коммитов", при правильной последовательности мы таску\сообщение не теряем, но должны быть готовы к обработке дубля. Что может быть дешевле 2pc или просто остается единственным вариантом, когда 2pc не возможен (kafka+db).
Да, нашел важные ответы во второй статье. Вашу идею я понял. Shardman - это всё тоже самое, только на стороне БД. Т.е. для прикладной разработки - это практически всё тот же постгри: многие проблемы (шардирование, коллокация, отказоустойчивость и пр.) перенесены в коробку и решаются на стороне сервиса БД, а не из прикладного кода.
Спасибо за статью! Если не секрет, поделитесь пожалуйста информацией: 1) какова была трудоемкость вашего решения в человеко-годах (от проектирования до развертывания) 2) почему не ydb\shardman? У них точно есть поддержка прямо сейчас, ПГсовместимы, хотя CocroaсhDb выглядит интереснее
Спасибо за статью! Если не секрет, поделитесь пожалуйста информацией: 1) какова была трудоемкость вашего решения в человеко-годах (от проектирования до развертывания) 2) почему не ydb?
Вся прелесть в plantuml как раз в том и состоит, что нет необходимости попадать стрелочками в квадратики. И тратиь время на фантазии "как же всё это лучше расположить". Да, итоговая картинка, возможно, будет далека от дизайнерского идеала. Но отразить суть, передать мысль читателю, позволяет достаточно быстро. Если на картинке получается паутинка, то это скорее не проблема plantuml, а рисующего, который пытается показать слишком много объектов\контекста с помощью одной картинки. Вернее даже так: если картинка превращается в паутинку, то ее нужно упрощать, разбивать на серию диаграмм, и т.д.Killer feature - это текстовый формат описания, который легко встроить, например, в asciidoc и получить все плюшки от documentation as code. К сожалению, visio\drawio\xmind вести полноценну документацию по проекту не позволят. Вишенка на торте: элементы, отображаемые в plantuml, можно сделать интерактивными, т.е. можно реализовать переход от квадратика к полноценному описанию этого кважратика в тексте и т.д.
Видимо вы застали роение пчел. Во время роения нужно очень постараться, чтобы они начали атаковать. Им просто не до того: пузо набито мёдом, что его не согнуть для ужаления - они ведь летят на новое место со своими продуктами и стройматериалами, да и защищать нечего - дома еще\уже нет. Но вот запах может сильно спровоцировать: спирт, бензин, духи, косметика даже в следовых количествах заставляют агриться. Плюс они четко чувствуют страх и неуверенность.
База данных не стала бутылочным горлышком после реализации Inbox? Если не стала, то может и NATS\Kafka не нужнs для вашей задачи и всю обработку можно организовать на уровне бд?
То есть вы предлагаете все это перенести на клиента? А если клиентских сервисов несколько? А при динамическом маштабировании? А когда количество данных в каждом топике по несколько гигабайт? А когда часть данных уже ушла из кафки?
Таких проблем нет. Клиент - метка условная, "клиентский сервис" - такой же участник обработки, как и другие компоненты. И перенести в него данные можно и отмасштабироваться и отшардировать потоки. И как показала практика это сделать можно сильно проще, чем при использовании Тарантула. Самое важное - можно сделать так, чтобы клиент обрабатывал только свою часть данных, не обращаясь ко всему спейсу тарантула через балансировщики, роутеры, вычисляя нужные шарды и т.д.. И еще важнее - надежнее.
По-моему кейс чересчур надуманный: при выполнении потоковой обработки сообщений нужно "оставаться в потоке" и все необходимые данные хранить под ногами у сервиса-обработчика ровно столько времени, сколько это ему необходимо. Кафка, в частности ее клиент, позволяет решить эти задачи из коробки, причем позволяет хранить только данные необходимые конкретному обработчику в данный момент времени для обработки конкретных партиций топика, а не все подряд, масштабироваться примерно по щелчку пальцев по сравнению с тарантулом. В случае включения в эту историю Тарантула появляются проблемы и накладные расходы, которые перевешивают весь профит от подключения: дополнительные инфраструктурные компоненты тарантула, которые требуют большее количества железа и отдельной команды сопровождения, проблемы синхронизации топиков кафки и структур тарантула, сложность или невозможность обеспечения транзакционности обработки сообщений, обеспечение fault tolerance и т.д.. А плюсы от включения далеко не очевидны. Тарантул был бы интересен как конкурент Redis/Ignite, в том числе при взаимодействии с БД. Но, например, реализации JSR 107 в нем нет, и только его подключение в проект будет нести дополнительные сложности.
DLQ предназначен только для ошибочных сообщений, которые никак не могут быть обработаны бизнес процессом (a-la байты перепутались и сообщение не парсится) и их нужно отложить, чтобы они не стопорили обработку остальных. Завязываться на dlq и прокачивать через него поток неконсистентных сообщений - ошибка. Inbox\outbox хороши, но медленные. Как и рабочий вариант с загрузкой в предварительные структуры без FK. Посмотрите на вариант решения достижения консистентности перед складыванием в БД спомощью kafka streams. Сложнее, но вариант быстрый, масштабируемый и надежный.
Cогласно реализованному в кафке паттерну producer-consumer участники информаионного обмена ничего и не должны знать друг о друге. Недописал важный аспект в предыдущем комментарии.
Нормально работает, неузко. В рамках, например spring kafka прозрачно и незаметно для разработчика. Ничего другого (синхронного rpc в асинхронной обработке) делать не нужно.
Всё несколько хитрее. Для обеспечения семантики exactly once необходимо коммитить чтение консюмером, только вместе с коммитом записи продюсером. У клиента для этого есть специальный метод. А если используете какую-то оболочку (spring kafka например), то всё доступно из коробки.
Redis все-таки скорее про распределенный кэш. Для публикаций и подписок больше подходят брокеры сообщений (Kafka\Artemis\Rabit\etc). Тем более, что для pub/sub Redis дает только at most once семантику (слабейшую), т.е. не может гарантировать примерно ничего и нужно быть готовым как к дублям так и потерям сообщений.
Обеспечение отказоустойчивости (resiliense and fault tolerance) идет от самой кафки. Т.е. самостоятельно организовывать в коде ничего не надо - только настраивать. А вот с обработкой ошибок не так всё не то, чтобы хорошо - скорее неудобно: необходимо либо их полностью обрабатывать в пределах отдельного этапа обработки, либо обрабатывать и разделять (split) дальнейший поток обработки. Это является одной из особенностей стримовой обработки сообщений в целом.
Information
Rating
Does not participate
Registered
Activity
Specialization
Технический директор, Архитектор программного обеспечения
Как быть, если компания не OpenAI и бурно растет и нарезать производительные нод проще, чем купить выделенный мощный сервер? И в случае необходимости добавить к ним еще одну или две ноды? А как обеспечить отказоустойчивость с околонулевыми RPO\RTO с одним писателем? А как быть если все-таки уперлись на доступной физике в потолок производительности? Всё по-быстрому переписать с нуля, главное чтобы бизнес не заметил? Парадигма взаимодействия с бд и с p2p или pub\sub системами различна. Возомжно, универсальные комбайны хороши. Вот только бы кто-то обозначил границы их применимости в зависимости от нагрузки и требований по надежности.
Подскажите пожалуйста, какие есть планы на шардирование этих очередей? Будет ли этот функционал только в PostgresPro или появится и в shardman тоже? Какой выбран протокол взаимодействия с очередями?
P.S.: ваш пример в ачале статьи с транзакионным разрывом между брокером и бд некорректен: все зависит от последовательности "коммитов", при правильной последовательности мы таску\сообщение не теряем, но должны быть готовы к обработке дубля. Что может быть дешевле 2pc или просто остается единственным вариантом, когда 2pc не возможен (kafka+db).
Да, нашел важные ответы во второй статье. Вашу идею я понял. Shardman - это всё тоже самое, только на стороне БД. Т.е. для прикладной разработки - это практически всё тот же постгри: многие проблемы (шардирование, коллокация, отказоустойчивость и пр.) перенесены в коробку и решаются на стороне сервиса БД, а не из прикладного кода.
Спасибо за статью! Если не секрет, поделитесь пожалуйста информацией:
1) какова была трудоемкость вашего решения в человеко-годах (от проектирования до развертывания)
2) почему не ydb\shardman? У них точно есть поддержка прямо сейчас, ПГсовместимы, хотя CocroaсhDb выглядит интереснее
Спасибо за статью! Если не секрет, поделитесь пожалуйста информацией:
1) какова была трудоемкость вашего решения в человеко-годах (от проектирования до развертывания)
2) почему не ydb?
Вся прелесть в plantuml как раз в том и состоит, что нет необходимости попадать стрелочками в квадратики. И тратиь время на фантазии "как же всё это лучше расположить". Да, итоговая картинка, возможно, будет далека от дизайнерского идеала. Но отразить суть, передать мысль читателю, позволяет достаточно быстро. Если на картинке получается паутинка, то это скорее не проблема plantuml, а рисующего, который пытается показать слишком много объектов\контекста с помощью одной картинки. Вернее даже так: если картинка превращается в паутинку, то ее нужно упрощать, разбивать на серию диаграмм, и т.д.Killer feature - это текстовый формат описания, который легко встроить, например, в asciidoc и получить все плюшки от documentation as code. К сожалению, visio\drawio\xmind вести полноценну документацию по проекту не позволят. Вишенка на торте: элементы, отображаемые в plantuml, можно сделать интерактивными, т.е. можно реализовать переход от квадратика к полноценному описанию этого кважратика в тексте и т.д.
Видимо вы застали роение пчел. Во время роения нужно очень постараться, чтобы они начали атаковать. Им просто не до того: пузо набито мёдом, что его не согнуть для ужаления - они ведь летят на новое место со своими продуктами и стройматериалами, да и защищать нечего - дома еще\уже нет. Но вот запах может сильно спровоцировать: спирт, бензин, духи, косметика даже в следовых количествах заставляют агриться. Плюс они четко чувствуют страх и неуверенность.
База данных не стала бутылочным горлышком после реализации Inbox? Если не стала, то может и NATS\Kafka не нужнs для вашей задачи и всю обработку можно организовать на уровне бд?
Таких проблем нет. Клиент - метка условная, "клиентский сервис" - такой же участник обработки, как и другие компоненты. И перенести в него данные можно и отмасштабироваться и отшардировать потоки. И как показала практика это сделать можно сильно проще, чем при использовании Тарантула. Самое важное - можно сделать так, чтобы клиент обрабатывал только свою часть данных, не обращаясь ко всему спейсу тарантула через балансировщики, роутеры, вычисляя нужные шарды и т.д.. И еще важнее - надежнее.
По-моему кейс чересчур надуманный: при выполнении потоковой обработки сообщений нужно "оставаться в потоке" и все необходимые данные хранить под ногами у сервиса-обработчика ровно столько времени, сколько это ему необходимо. Кафка, в частности ее клиент, позволяет решить эти задачи из коробки, причем позволяет хранить только данные необходимые конкретному обработчику в данный момент времени для обработки конкретных партиций топика, а не все подряд, масштабироваться примерно по щелчку пальцев по сравнению с тарантулом. В случае включения в эту историю Тарантула появляются проблемы и накладные расходы, которые перевешивают весь профит от подключения: дополнительные инфраструктурные компоненты тарантула, которые требуют большее количества железа и отдельной команды сопровождения, проблемы синхронизации топиков кафки и структур тарантула, сложность или невозможность обеспечения транзакционности обработки сообщений, обеспечение fault tolerance и т.д.. А плюсы от включения далеко не очевидны. Тарантул был бы интересен как конкурент Redis/Ignite, в том числе при взаимодействии с БД. Но, например, реализации JSR 107 в нем нет, и только его подключение в проект будет нести дополнительные сложности.
DLQ предназначен только для ошибочных сообщений, которые никак не могут быть обработаны бизнес процессом (a-la байты перепутались и сообщение не парсится) и их нужно отложить, чтобы они не стопорили обработку остальных. Завязываться на dlq и прокачивать через него поток неконсистентных сообщений - ошибка. Inbox\outbox хороши, но медленные. Как и рабочий вариант с загрузкой в предварительные структуры без FK. Посмотрите на вариант решения достижения консистентности перед складыванием в БД спомощью kafka streams. Сложнее, но вариант быстрый, масштабируемый и надежный.
Cогласно реализованному в кафке паттерну producer-consumer участники информаионного обмена ничего и не должны знать друг о друге. Недописал важный аспект в предыдущем комментарии.
Нормально работает, неузко. В рамках, например spring kafka прозрачно и незаметно для разработчика. Ничего другого (синхронного rpc в асинхронной обработке) делать не нужно.
Через метод Producer.sendOffsetsToTransaction. Вот здесь почедовечески написано как делать через родной клиент https://www.baeldung.com/kafka-exactly-once.
Всё несколько хитрее. Для обеспечения семантики exactly once необходимо коммитить чтение консюмером, только вместе с коммитом записи продюсером. У клиента для этого есть специальный метод. А если используете какую-то оболочку (spring kafka например), то всё доступно из коробки.
Redis все-таки скорее про распределенный кэш. Для публикаций и подписок больше подходят брокеры сообщений (Kafka\Artemis\Rabit\etc). Тем более, что для pub/sub Redis дает только at most once семантику (слабейшую), т.е. не может гарантировать примерно ничего и нужно быть готовым как к дублям так и потерям сообщений.
Обеспечение отказоустойчивости (resiliense and fault tolerance) идет от самой кафки. Т.е. самостоятельно организовывать в коде ничего не надо - только настраивать. А вот с обработкой ошибок не так всё не то, чтобы хорошо - скорее неудобно: необходимо либо их полностью обрабатывать в пределах отдельного этапа обработки, либо обрабатывать и разделять (split) дальнейший поток обработки. Это является одной из особенностей стримовой обработки сообщений в целом.