Комментарии
23
Но ведь Ferrari в этом сезоне не быстры
Справедливости ради: на КДПВ — Ferrari SF70-H, на этой модели Себастьян Феттель (#5) стал вице-чемпионом F1 в 2017 году. Правда на КДПВ автомобиль его партнёра по команде Кими Райкконена (#7) он выступил менее удачно. Sorry за offtop.
Kafka = Franz Kafka (он)
Kafka = Брокер очереди сообщений (он)
Kafka = очередь сообщений (она)
Поскольку, вы пишете в тексте «брокер», то все же «он».
Kafka = Брокер очереди сообщений (он)
Kafka = очередь сообщений (она)
Поскольку, вы пишете в тексте «брокер», то все же «он».
Apache Kafka = технология (она)
Приведите цифры, а то непонятно о какой скорости речь.
Цифры относительные будут всегда, тк зависят от многих факторов (какое у вас железо, какой паттерн нагрузки, какого размера сообщения, на сколько хорошая сетка, как настроен кластер, клиенты и тд).
В наших инсталляциях на данный момент пиковые нагрузки в районе 25 гигабит в секунду или 600к событий в секунду на кластере из 9 машин с HDD дисками. Это точно далеко не предел, но пока нам больше и не нужно.
В наших инсталляциях на данный момент пиковые нагрузки в районе 25 гигабит в секунду или 600к событий в секунду на кластере из 9 машин с HDD дисками. Это точно далеко не предел, но пока нам больше и не нужно.
Все хорошо с производительностью у кафки, вот только с тулзами у нее большие проблемы. Нам даже пришлось самим тулзу на питоне писать, чтобы как-то управлять этим монстром
А какие у вас были проблемы, если не секрет (интересно)?
В целом, вы и правы и нет одновременно. Если сравнивать Kafka с другими подобными решениями, то у нее экосистема намного более развитая и богатая (коннекторы, репликаторы, прокси, schema registry и тд и тд). И часто компаниям достаточно того, что уже сделано другими и доступно в опенсорсе. Но бывают и случаи когда под именно вашу платформу/ваш кейс надо что-то дописывать самостоятельно.
В целом, вы и правы и нет одновременно. Если сравнивать Kafka с другими подобными решениями, то у нее экосистема намного более развитая и богатая (коннекторы, репликаторы, прокси, schema registry и тд и тд). И часто компаниям достаточно того, что уже сделано другими и доступно в опенсорсе. Но бывают и случаи когда под именно вашу платформу/ваш кейс надо что-то дописывать самостоятельно.
Я начал работать с кафка после rabbitMQ с встроенным веб интерфейсом и возможностью прочитать любое сообщение + просмотр метрик, редактирование очередей и тд. И тут чтобы посмотреть список топиков мне нужно шаманить с набором баш скриптов, прописывая кучу параметров, типа адреса zookeeper. Кстати наша тулза лежит на гитхабе и там можно все прописать в yaml конфиге и не парить мозг параметрами
Интересно, зачем Linkedin было необходимо ворачать несколько террабайт сообщений в час? Это ведь не видеохостинг, а текстовыми сообщениями добиться таких обьемов не реально.
722 000 000 профилей пользователей. Куча взаимодействий с сайтом.
Каждый клик — событие…
Даже если каждый зарегестрированный пользователь зайдет на сайт в одно и тоже время он должен делать приблизительно 1 клик в секунду. Есть большие сомнения, что online хотя 10% их пользователей.
1) не надо быть зарегистрированным что-бы пользоваться сайтом.
2) сколько по вашему занимает базовый эвент взаимодействия с сайтом? Опустим добавление медиа (картинок, видео и т.д.)
1) не надо быть зарегистрированным что-бы пользоваться сайтом.
readonly пользователи врядли создают нагрузку для которой нужна кафка. Если же создает, то интересно почему и архитектурные детали.
2) сколько по вашему занимает базовый эвент взаимодействия с сайтом?
Поскольку профили меняются редко, основное это отсылка сообщений размером 500-2000 байт.
Возмите в учет обычный клик. Любого пользователай вполне себе событие просмотра со множествоме метаданных. Кто, когда, и где и т.д.
И это миллионы этих 500-2000 байт.
К томуже их кафки могут быть использованны для чего угодно… Например стриминг логов с их серверов.
Самое удивительное, что LinkedIn всегда был невероятно тормознутым. Во времена, когда он еще не был заблокирован в РФ, я периодически заходил на него, т.к. иногда писали рекрутеры, а чаще просто потому что он забрасывал спамом несмотря на регулярные отписывания. Вроде отпишешься явно от всего, через месяц — снова спам, и приходится идти в настройки — вдруг что забыл. А там — будто и не отписывался никогда.
Так вот, каждый раз заходя на сайт удивлялся тому, насколько медленно он работает. Думал, что после покупки Microsoft станет лучше, но не стало. Хотя после блокировки почти не заходил на него. Спам перестал приходить — и ладно. Может быть сейчас они наконец решили проблемы с производительностью.
Так что LinkedIn — не лучшая реклама Kafka. Может и не Kafka причина тормознутости LinkedIn, но его медленность отмечали все, кого я спрашивал.
Пользовательской аналитикой очень просто таких объемов добиться (кликстрим, например).
Идея единственного монолитного приложения или даже нескольких крупных сервисов, разделяющих общий массив данных, практически стерта из умов и сердец инженеров-практиков во всем мире.Что за несусветная чушь? Каждой задаче своя архитектура.
И почему вы так уверенно заявляете от имени всех инженеров?
Автор не ответит — это перевод
Это перевод статьи, автор данного мнения – Emil Koutanov
В целом, многие с этим мнением не согласятся, конечнo.
Например, Kelsey Hightower считает, что монолиты скоро (или уже) опять будут в моде :)
Например, Kelsey Hightower считает, что монолиты скоро (или уже) опять будут в моде :)
2020 prediction: Monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications.
Спасибо за проделанную работу, но перевод хромает. Переводчку надо повышать свою тех.грамотность и избегать англицизмов (консюмер) и английских слов в переведенном тексте (fan-out, amplification и т.п) — для большинства слов уже давно есть устоявшиеся термины на русском языке.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Почему Kafka такая быстрая