Comments 18
Apache Zookeeper как необходимая часть деплоя – 21 век на дворе, свою реализацию рафта вшивают уже в каждый утюг :)
Есть же KRaft?
Давно интересует Debezium, какие с ним были проблемы или нюансы? Надежная вещь?
Очень много зависит от зрелости адаптера к бд для него, причем это касается как стабильности, так и набора фич. Например, адаптер для vitess год назад был очень сырой - например, не умел снимать initial snapshot.
Адаптер mysql, который мы используем уже достаточно долго, достаточно хорош. Набор фич, как то снятие первоначального снепшота, промежуточные, поддержка операций - нас устраивает полностью. Иногда проскакивают досадные вещи - по бинлогу прилетает неподдерживаемая ddl операция и на этом репликация заканчивается :) Необходимо почистить историю изменений и снять заново состояние ddl с источника. В остальном надежно.
Ну и стоит смериться, что сообщения идут в json (возможна сериализация в avro), и если у вас большой поток, то места будет уходить много. Плюс к этому своя собственная сериализация типов из бд заставляет потанцевать. Мы используем спарк для восстановления состояния таблиц и там это решается достаточно просто - вывод схемы по последнему сообщению + сравнение с схемой источника. А вот для потокового проигрывания, мне кажется, все становится сложнее, особенно если у вас шардированная база данных.
если я верно понял, вся причина в том, чот вы поселили вместе разную нагрузку. То есть, ровно то, что не советуют делать при эксплуатации таких штук ) и удивляетесь, что плохо работает )
Точная причина произошедшего мне неизвестна, но кажется, что именно в этом )
С одной стороны да, проблема шумных соседей присутствует и это антипаттерн. С другой стороны кафка в таких условиях работает как часы, причем сама как сервис, так и ее клиенты.
Самое неприятное в поведении даже не то, что при средней нагрузке (у нас не было 100% забитого цпу, или проблем с памятью, или слишком уж сильной нагрузки на диски) кластер панды уходил в перевыборы, а то что клиенты от него отваливались навсегда.
Ну и хотелось бы от инструмента возможности тюнинга настроек и более адекватного поведения при нагрузке. Потому что шумные соседи могут быть и на нодах виртуализации, и в кубике, и на шаренной схд. Но судя по рекомендациям панды - ее не стоит использовать ни в одном из этих случаев - только железо, только хардкор :)
Уж виртуалки то вполне можно, раз сцилла позволяет. Самое главное это стабильный паттерн производительности. Если четко соблюдаются шары на проц и диски, то все должно быть ок.
Это не тот инструмент, где можно ждать гибкости. Архитектура seastar заточено под конкретные условия и не терпит отхождения. От того оно такое и быстрое.
От того оно такое и быстрое.
Ниже есть независимые бенчи. Ах если бы все было так однозначно :)
Если подвести итог, мы получаем сервис в некоторых случаях с меньшей лейтенси, но при этом куда более нестабильный (как в метриках, так и в работе).
Кстати прошло почти 2 месяца, кафка ни разу за это время не привлекла к себе внимание алертами или метриками - все просто работает в тех же условиях.
Тут я конечно больше ориентируюсь на сциллу. Там разница с касандрой реально огромная в перформансе и в том, как железка вообще утилизируется. Про редпанду тоже слышал противоречивые отзывы и, честно говоря, не совсем понимаю, зачем ее переписывать. По опыту с кафкой, она кушает мизерно число ресурсов и переваривает огромное количество трафика при этом.
В апстрим зарепортили проблему? Если да, то можете дать ссылку на репорт, пожалуйста?
Нет, репорта не было, когда есть альтернативы - проще уйти :(
Да и кажется, что у ребят там проблем хватает )
Очень прошу зарепортить в апстрим данный баг, так как он звучит достаточно важным. Потому что если не зарепортите, то шанс на его починку намного меньше, чем с репортом :) Возможно, что дело не в баге, а в какой-то "скрытой" настройке или чём-то странном ещё.
На количество issue можете не ориентироваться особо - они могут быть разной приоритетности и тому прочее.
Очень сомневаюсь, что это кто-то всерьез воспримет.
по опыту сциллы, они не предназначены для соседства с чем-то. Вокруг этого построена вся их архитектура, в этом смысл фреймворка seastar. Потоки прибиваются к ядрам, на потоки мапятся жестко шарды. IO системы настраивается соотвествующий образом. Внутренний шедулер адаптируется под замеренные реальные показатели IO, и он ожидает, что они не будут хаотично меняться из-за шумного соседа. Это плата за скорость.
Их бенчмарки вызывают вопросики, очень рекомендую почитать https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up
Отличная статья, спасибо большое. Жаль, что она не попалась на глаза. Стал жертвой типичной когнитивной ошибки - искал везде информацию по преимуществам внедряемой системы, а не по недостаткам.
Согласен про то, что при одинаковой архитектуре и достаточно долгой жизни проекта, переписывание на какой-то другой язык (как один из наиболее привычных приемов) не даст никакого ускорения. Все что может помочь в выжимании скорости уже сделано.
Немного другой подход или иной выбор компромиссов может давать разницу, как видно в этом случае. Но, как всегда, даёт свои плюсы и минусы. Эта серия статей (ссылки там в конце) показывает разные аспекты сравнения, и итоговое решение надо принимать на основе тестирования под свою нагрузку, но кто ж так в реальности делает xD
Там ключевой косяк теста: "Issue #1 is that in Kafka’s server.properties file has the line log.flush.interval.messages=1 which forces Kafka to fsync on each message batch... So I removed that from the server.properties file...", автор убрал этот параметр, и весь его тест превратился в фуфло. Т.к. по default log.flush.interval.messages=10000 (было раньше, а сейчас вообще лимита нет по сути), т.е. kafka сбрасывает на накопитель каждые 10000 msg (в старых версиях, в новых версиях применяются default'ы checkpoint интервалов - 1 минута), если так подходить, то логично было-бы для redpanda выставить --unsafe-bypass-fsync и тогда сравнивать. А в своих тестах команда redpanda делает акцент на надёжности - демонстрируя потерю данных в kafka: https://github.com/redpanda-data/kafka-fsync.
Ага, совсем не ангажированный пост от чувака из Confluent.
Реквием по красной панде