PD
Ну, это проблема проектирования. Документы надо чанками хранить. А осмысленных сущностей в 300mb - не бывает (
Size: a a a
2019 August 20
LV
Бывает.
PD
Эээ? Пример?
LV
Описания объекта с координатами.
LV
В жизни много чего бывает. Две посылки с одним трекинг намбером - легко. Два объект недвижимости с одним кадастровым номером - тоже не проблем. Два человека с одним снилс - да о чем речь.
PD
В жизни много чего бывает. Две посылки с одним трекинг намбером - легко. Два объект недвижимости с одним кадастровым номером - тоже не проблем. Два человека с одним снилс - да о чем речь.
Ну, про несуществованиее естественных уникальных ключей давно переговорено.
LV
Ну, теперь можно проговорить про неограниченный размер документов. описывающий реальные сущности ))
PD
Описания объекта с координатами.
Десять миллионов точек? Ойй...
PD
Ну, теперь можно проговорить про неограниченный размер документов. описывающий реальные сущности ))
Ну тогда надо сразу резать по чанкам. Но вообще Kafka - про события, а не данные, это тоже антипаттерн. Хотя некоторые умудрялись картинки на обработку через нее гонять и даже быстро.
LV
Событие может внести в себе данные ))
EI
Так такие проблемы будут у любого брокера. В доке по Кафке хотя бы написано, что так делать можно только в тестовом окружении.
Я выше писал про проблемы - а давайте семь self-education статей скину, которые можно разработчикам и архитекторам показывать:
: https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/ + шесть статей по ссылкам в конце.
: https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/ + шесть статей по ссылкам в конце.
PD
Я выше писал про проблемы - а давайте семь self-education статей скину, которые можно разработчикам и архитекторам показывать:
: https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/ + шесть статей по ссылкам в конце.
: https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/ + шесть статей по ссылкам в конце.
Это все немножко про другое. Не про kafka as a transport или kafka as a queue, а про Streams и прочее.
EI
Это все немножко про другое. Не про kafka as a transport или kafka as a queue, а про Streams и прочее.
Понял, что не написал "чем мне понравились статьи и рисунки Ben Stopford"
Ответ короткий: статья Мартина "Event Sourcing" (https://martinfowler.com/eaaDev/EventSourcing.html) - пример сухой и мало понятной.
Ben Stopford показывает понятнее, и в графике - а это облегчает понимание команде.
Ответ короткий: статья Мартина "Event Sourcing" (https://martinfowler.com/eaaDev/EventSourcing.html) - пример сухой и мало понятной.
Ben Stopford показывает понятнее, и в графике - а это облегчает понимание команде.
EI
Это все немножко про другое. Не про kafka as a transport или kafka as a queue, а про Streams и прочее.
Да, это про streams
SV
Я хочу прочитать вот эту книжку:
Пока только прогледел по диагонали – очень понравились метод подачи и объем информации по требованиям.
Mastering the Requirements Process Second Edition
By Suzanne Robertson, James Robertson
...............................................
Publisher: Addison Wesley Professional
Pub Date: March 17, 2006
Print ISBN-10: 0-321-41949-9
Print ISBN-13: 978-0-321-41949-1
Pages: 592
Пока только прогледел по диагонали – очень понравились метод подачи и объем информации по требованиям.
есть более свежая редакция Mastering the Requirements Process: Getting Requirements Right (3rd Edition)
2019 August 21
AT
есть более свежая редакция Mastering the Requirements Process: Getting Requirements Right (3rd Edition)
Спасибо!
SB
Ну взяли вы пачку в 10 сообщений. На обработку одного уходит 5мс. Закомитили офсет через 1мс. Через 3 упали. Сообщения потеряли. Дальше я любой ваш кейс сведу к этому сценарию до тех пор, пока вы не начнете читать сообщения строго последовательно из партиции и делать коммит офсета по одному сообщению.
Значит, вы коммитите оффсет не так, как надо в данном сценарии.
Есть в общем два сценария:
- нужен большой throughput, потеря какого-то числа сообщений - некритична. Тогда имеет смысл коммитить оффсет асинхронно и "иногда".
- нужны гарантии обработки, тогда как правило одновременно нужна и последовательность. Коммитить оффсет синхронно после успешной обработки сообщения.
Что делать во втором случае, если какое-то сообщение невозможно обработать по какой-то причине? Зависит от юз-кейса. Иногда - фиксить консюмер, чтобы он смог его обработать. Иногда - складывать в DLQ. Иногда - игнорировать и идти дальше.
Есть в общем два сценария:
- нужен большой throughput, потеря какого-то числа сообщений - некритична. Тогда имеет смысл коммитить оффсет асинхронно и "иногда".
- нужны гарантии обработки, тогда как правило одновременно нужна и последовательность. Коммитить оффсет синхронно после успешной обработки сообщения.
Что делать во втором случае, если какое-то сообщение невозможно обработать по какой-то причине? Зависит от юз-кейса. Иногда - фиксить консюмер, чтобы он смог его обработать. Иногда - складывать в DLQ. Иногда - игнорировать и идти дальше.
LV
Ну там 100500 сообщение перед этим и после этого о том, что вы написали в своем.
A
Необходимо решение, чтобы документировать изменения структуры (модели) базы данных. Обычно от аналитика приходит огромный документ Word с таблицей внутри, когда его спрашиваешь что изменилось в документе, описывающем БД - он говорит не знаю, вот моя постановка читай ищи. Расскажите свой опыт.