Thank you so much for detailed description of handling the data processing pipeline!
There are a couple of questions that I would like to clarify:
What is the strategy for the error handling? Error handling for data processing is one of the complex topic that requires special attention. What are the primitives the framework provides?
What are the scalability property of the framework? Can we control the number of workers/threads for each stage? Is it possible to control the memory footprint? And finally, is it possible to distribute the data processing across the nodes?
Видимо, не всем знакомы термины "основания" и "полагать". Основания — это то, что используется в качестве основы, т.е. некий источник. В качестве такого источника я взял pdf документ, который легко найти в открытом доступе, который разбирает, например, автор "технической статьи". "полагать" — это синоним слов "думать", "считать", "предполагать". Если для вас "основания полагать" является эквивалентом слова "факт" — то у меня для вас плохие новости.
Нормальная техническая статья никогда не будет опускаться до уровня гопоты. Автор будет делать такое в одном единственном случае: если она предназначается для гопоты. По ссылке vas3k.com можно найти добротные статьи для широкой аудитории. Опять, же, это не технические, а технически-популярные (по аналогии с термином "научно-популярный") статьи, написанные гораздо более качественно.
Мой основной посыл был не в том, что манера не та, а в том, что:
Статья не техническая.
Налицо передергивание фактов, т.к. в оригинальной статье тезис был менее строг.
Тут было пропущено "скорее всего". Заголовок очень желтый, явно, чтобы привлечь внимание.
Выводов никаких не будет. Я тут корчу из себя журналиста, а настоящая журналистика — это беспристрастная констатация фактов.
Констатация фактов — заголовок не соответствует статье. В выводах ничего конкретного нет, домыслы и факты о том, чего якобы не было. Я не говорю о том, что это правда или не правда, я говорю о том, что "Я тут корчу из себя журналиста" — правильное описание контента.
Например, техническая статья от Никиты Колмогорова, автора вышеупомянутого канала «Золото Бородача». Он изучил все документы и в свойственной для матёрого гика манере сделал подробный обзор тестового блокчейна TON. Кратко — это «просто накиданая на коленке по бырому обертка вокруг ноды».
Давайте пойдем по ссылки и почитаем, что там на самом деле написано:
Код ну очень сыровато выглядит — до релиза там явно далеко, но, может быть, это просто накиданая на коленке по бырому обертка вокруг ноды шоб показать можно было инвесторам, что не исключено
"Может быть… просто накиданая". Мда, факты говорите? Орфография "пацанского разбора" заставляет плакать кровавыми слезами. Никакая это не "техническая статья".
Возвращаясь к оригинальной статье. Передергивание фактов, "технический анализ" — вот все то, что вы должны знать про современную "журналистику".
Тут я не очень понял. Можно сказать, что то, что Kafka сохраняет порядок — приятный бонус. Можно им не пользоваться, и тогда задачи становятся одинаковыми. А значит можно снова сравнивать, верно?
Получается, что у Kafka производительность выше во всех сценариях работы. Более того, Kafka предоставляет больше гарантий и возможностей. Думаю, вот в таком аспекте и можно сравнить.
Сравнивать FIFO-очередь и Kafka бессмысленно, FIFO-очереди YMQ не ставят себе задачу заменить Kafka
Сравнивать имеет смысл, т.к. решается одна и та же задача. А то, что у команды не было задачи конкурировать с Kafka — это вопросы, относящиеся к политической области, а не технической.
На мой взгляд, сравнение более, чем уместное: при одинаковых гарантиях Kafka выдает на многие порядки большую производительность. Тут возникает масса вопросов про эффективность.
Даже стандартные очереди YMQ (которые уже сейчас при необходимости поддерживают те же десятки тысяч RPS в одну очередь, и это не предел оптимизаций) не стоит сравнивать с Kafka — функции и задачи у этих систем немного разные.
Можно тут прояснить, в чем разница задач для очередей? Какие задачи выполняют распределенные очереди кроме той, чтобы хранить последовательность сообщений, добавлять и извлекать?
Сегодня проблема высокой доступности упирается не в резервирование (это само собой), а в консенсус — алгоритм по выбору лидера (Leader election). Чаще всего крупные аварии происходят не из-за нехватки серверов, а из-за проблем с консенсусом: не выбрался новый лидер, появились два лидера в разных датацентрах и т.п. Пример — авария на MySQL-кластере Github — они написали подробный постмортем.
Консенсус — это не алгоритм выбора лидера, а алгоритм прихода участников к соглашению. На основе консенсуса можно построить алгоритм выбора лидера. Более того, алгоритм консенсуса может включать в себя выбор лидера, но далеко не все алгоритмы это делают.
Чаще всего аварии бывают не из-за проблем с консенсусом, а из-за отсутствия консенсуса. Пример с Github — это типичный случай отсутствия консенсуса.
Объясняю на пальцах, почему такие рассуждения ничего не доказывают. Допустим, у вас есть бревно.
Если у вас есть топор, то у вас есть просто одно движение, типа:
«хрясь»
Если же вы решили воспользоваться ножом, то вы можете, например:
«пилить»
И при этом будете делать все 200 перепиливаний ножом.
Как вы будете пилить 200 бревен? Группировать кучками? Или раскидаете?
Нож годится для определенных действий, например, резка картофеля. В других сценариях он приводит к тому, что люди занимаются не полезной работой, а перепиливанием бревен, из-за чего получаются медленные результаты.
Disclaimer: я использую нож и топор с 1993 года, и пришел к выводу о необходимости использовать нож сдержанно после года через три после начала его использования. Желание наплодить картофелин — это желание либо новичка, либо человека, который любит жареную картошку или то, что похоже на жареную картошку. Все, кто имеет дело с бревнами — скажи нет ножу, даже если это ювелирная резьба по дереву.
Добавил секцию со ссылками и комментариями в свой пост. [2] — это моя статья про микс парадигм с точки зрения решения проблем, связанных с многопоточным программированием.
Главные ошибки автора:
1. Он не дает четкого определения ООП.
2. Приводит примеры плохого ООП.
3. Не приводит ничего взамен, чтобы подход был равносилен ООП. То, что приведено в конце — это слишком специфично, чтобы можно было использовать во всех местах, где используется ООП.
Можно делать разбор каждого утверждения. Но автор неправ фундаментальным образом: он боролся не с ООП, а с неправильным использованием ООП. На основе этого сделал вывод про ООП.
Как правило, выбирается инструмент, а затем уже нужно смотреть, какие парадигмы инструмент позволяет использовать наиболее просто и быстро. Если это Java, то тут обычно без вариантов.
Парадигма ООП — важная веха в истории программирования. Она давала и будет давать плоды. Однако, как и любой инструмент, его можно использовать неправильно, а также и понимать неправильно, что будет приводить к еще более худшему программному коду.
Ценность статьи — не в количестве букв, а в информации, которая в ней содержится. Можно было бы налить больше воды, как это было сделано в указанной ссылке на статью, но я в этом смысла никакого не вижу.
coroutine_handle является управляющим обработчиком для текущей сопрограммы, и не описывает пользовательский callback. Так что вряд ли тут мы дождемся ответа. Тут налицо непонимание базовых вещей.
Внезапно окажется, что await_suspend и coroutine_handle — это вовсе не клиентская часть для создания продолжений, я часть, связанная с жизненным циклом сопрограммы.
Thank you so much for detailed description of handling the data processing pipeline!
There are a couple of questions that I would like to clarify:
Very detailed introduction to the library with useful examples, thank you for sharing this!
Видимо, не всем знакомы термины "основания" и "полагать". Основания — это то, что используется в качестве основы, т.е. некий источник. В качестве такого источника я взял pdf документ, который легко найти в открытом доступе, который разбирает, например, автор "технической статьи". "полагать" — это синоним слов "думать", "считать", "предполагать". Если для вас "основания полагать" является эквивалентом слова "факт" — то у меня для вас плохие новости.
Давайте посмотрим на документ TON, pdf, 132 страницы.
В самом начале мы видим:
Telegram Open Network
Dr. Nikolai Durov
Никаких официальных опровержений не было. Как и официальных подтверждений. Так что основания полагать связь есть.
Нормальная техническая статья никогда не будет опускаться до уровня гопоты. Автор будет делать такое в одном единственном случае: если она предназначается для гопоты. По ссылке vas3k.com можно найти добротные статьи для широкой аудитории. Опять, же, это не технические, а технически-популярные (по аналогии с термином "научно-популярный") статьи, написанные гораздо более качественно.
Мой основной посыл был не в том, что манера не та, а в том, что:
Тут было пропущено "скорее всего". Заголовок очень желтый, явно, чтобы привлечь внимание.
Констатация фактов — заголовок не соответствует статье. В выводах ничего конкретного нет, домыслы и факты о том, чего якобы не было. Я не говорю о том, что это правда или не правда, я говорю о том, что "Я тут корчу из себя журналиста" — правильное описание контента.
Давайте пойдем по ссылки и почитаем, что там на самом деле написано:
https://medium.com/golden-borodutch/пацанский-разбор-кода-блокчейна-тон-d8e1096b4fb0
"Может быть… просто накиданая". Мда, факты говорите? Орфография "пацанского разбора" заставляет плакать кровавыми слезами. Никакая это не "техническая статья".
Возвращаясь к оригинальной статье. Передергивание фактов, "технический анализ" — вот все то, что вы должны знать про современную "журналистику".
Тут я не очень понял. Можно сказать, что то, что Kafka сохраняет порядок — приятный бонус. Можно им не пользоваться, и тогда задачи становятся одинаковыми. А значит можно снова сравнивать, верно?
Получается, что у Kafka производительность выше во всех сценариях работы. Более того, Kafka предоставляет больше гарантий и возможностей. Думаю, вот в таком аспекте и можно сравнить.
Сравнивать имеет смысл, т.к. решается одна и та же задача. А то, что у команды не было задачи конкурировать с Kafka — это вопросы, относящиеся к политической области, а не технической.
На мой взгляд, сравнение более, чем уместное: при одинаковых гарантиях Kafka выдает на многие порядки большую производительность. Тут возникает масса вопросов про эффективность.
Можно тут прояснить, в чем разница задач для очередей? Какие задачи выполняют распределенные очереди кроме той, чтобы хранить последовательность сообщений, добавлять и извлекать?
Консенсус — это не алгоритм выбора лидера, а алгоритм прихода участников к соглашению. На основе консенсуса можно построить алгоритм выбора лидера. Более того, алгоритм консенсуса может включать в себя выбор лидера, но далеко не все алгоритмы это делают.
Чаще всего аварии бывают не из-за проблем с консенсусом, а из-за отсутствия консенсуса. Пример с Github — это типичный случай отсутствия консенсуса.
Всегда пожалуйста:
Если у вас есть топор, то у вас есть просто одно движение, типа:
«хрясь»
Если же вы решили воспользоваться ножом, то вы можете, например:
«пилить»
И при этом будете делать все 200 перепиливаний ножом.
Как вы будете пилить 200 бревен? Группировать кучками? Или раскидаете?
Нож годится для определенных действий, например, резка картофеля. В других сценариях он приводит к тому, что люди занимаются не полезной работой, а перепиливанием бревен, из-за чего получаются медленные результаты.
Disclaimer: я использую нож и топор с 1993 года, и пришел к выводу о необходимости использовать нож сдержанно после года через три после начала его использования. Желание наплодить картофелин — это желание либо новичка, либо человека, который любит жареную картошку или то, что похоже на жареную картошку. Все, кто имеет дело с бревнами — скажи нет ножу, даже если это ювелирная резьба по дереву.
1. Он не дает четкого определения ООП.
2. Приводит примеры плохого ООП.
3. Не приводит ничего взамен, чтобы подход был равносилен ООП. То, что приведено в конце — это слишком специфично, чтобы можно было использовать во всех местах, где используется ООП.
Можно делать разбор каждого утверждения. Но автор неправ фундаментальным образом: он боролся не с ООП, а с неправильным использованием ООП. На основе этого сделал вывод про ООП.
coroutine_handleявляется управляющим обработчиком для текущей сопрограммы, и не описывает пользовательский callback. Так что вряд ли тут мы дождемся ответа. Тут налицо непонимание базовых вещей.Ок, тогда просто прошу реализовать это:
Внезапно окажется, что
await_suspendиcoroutine_handle— это вовсе не клиентская часть для создания продолжений, я часть, связанная с жизненным циклом сопрограммы.