Это егэшная задачка по информатике, btw. Сдавал недавно (так вышло) - мне вот ровно она попалась, за 15 минут не уложился решить, сейчас интереса ради попробовал на leetcode - полчаса ушло с учётом вспоминания синтаксиса С++.
Хз насколько это вообще показательно, очень уж сильно зависит успешность решения таких задачек от набитости руки и состояния в моменте - в итоге алгоритмические секции просто проверяют насколько у человека натренирован конкретно этот навык, и корелляция с успешностью выполнения рабочих задач тут отнюдь не полная.
UPD: почитал решения, можно за линию сделать оказывается, у меня было решение за O(nlogk) - забавная задачка :)
К сожалению это потребность платформы, практика показывает, что с настройкой умных библиотек для работы с кафкой (даже при разумных дефолтах), люди справляются очень плохо — слишком много денег теряется на факапах, связанных с этим.
Систему делали для того, чтобы поставить её перед текущим боевым кластером, соответственно нагрузка на него определяла требования к прослойке.
Те самые миллионы rps - это нагрузка от тысяч различных потребителей по методам кафки produce и fetch (не единичные сообщения!). Мы постоянно работаем над оптимизацией потребителей через убеждение и тюнинг платформенных библиотек, но текущая ситуация именно такая.
Консьюмеров мы конечно уже реализовали, в статье об этом написано.
Как и задумывалось, api предоставляет сильно упрощённый функционал, его для большинства сценариев хватает.
Абстракция, разумеется, не идеальная — если сделать клиентов-консьюмеров больше чем партиций, то лишние будут простаивать. Это сделано намеренно, чтобы не усложнять реализацию.
NATS к сожалению обеспечивает лишь гарантии at most once в безброкерном режиме, а с брокером смысл его использования теряется. Кроме того задача переезда на него гораздо тяжелее чем задача переезда на grpc-прокси перед kafka без переезда данных.
Ну и проблемы с библиотеками от этого никуда не деваются :)
Я в процессе отладки не раз подозревал GC, но ни разу он не был виновен - трейсинг хорошо позволяет отслеживать такое. На горячем пути в grpc и franz-go действительно в основном пулы объектов под капотом.
Идея про С++/Rust расcматривалась скорее в полушуточном режиме, поскольку мы не упирались в язык, а в команде экспертизы по Go заметно больше :)
Для подобных систем в целом валидно отправлять каждое событие в кафку, другое дело, что эти отправки стоит батчить, чтобы не создавать чрезмерную нагрузку на брокеры.
Потребность управлять поведением клиентов - как раз одна из основных причин создания data-bus, там зачастую что-то нездоровое происходит.
Тогда возможно вам будет интересно ознакомиться с проектом https://github.com/mailgun/kafka-pixy, хоть он и не имеет полноценной поддержки (последний релиз был в 2019), но как минимум из него можно черпать вдохновение :)
Всё же Faiss — это не БД, это библиотека для построения ANN индексов.
Я тоже тестировал питон, потом плюнул и переписал на гошке, производительность резко скакнула с 20к до 400к rps, питончик в десериализацию упирался.
Недурно! А скорость поиска? И какого размера кластер это добро обслуживает, если не секрет?
А какое у вас примерно количество записей в базе и рейт запросов по ним?
Это вот любопытно на самом деле - а зачем ставить себе цель отсекать кандидатов?
Они могут решать задачи бизнеса? Могут.
Делают это не хуже литкодовцев? Не хуже.
Так зачем тогда мучать и их и интервьюеров?
Это егэшная задачка по информатике, btw. Сдавал недавно (так вышло) - мне вот ровно она попалась, за 15 минут не уложился решить, сейчас интереса ради попробовал на leetcode - полчаса ушло с учётом вспоминания синтаксиса С++.
Хз насколько это вообще показательно, очень уж сильно зависит успешность решения таких задачек от набитости руки и состояния в моменте - в итоге алгоритмические секции просто проверяют насколько у человека натренирован конкретно этот навык, и корелляция с успешностью выполнения рабочих задач тут отнюдь не полная.
UPD: почитал решения, можно за линию сделать оказывается, у меня было решение за O(nlogk) - забавная задачка :)
Это текущая нагрузка на кластер, прокси просто должна с ней справиться, иначе она станет блокером роста бизнеса.
К сожалению это потребность платформы, практика показывает, что с настройкой умных библиотек для работы с кафкой (даже при разумных дефолтах), люди справляются очень плохо — слишком много денег теряется на факапах, связанных с этим.
Прекрасный вопрос!
Главный ответ такой: в большой компании людям не очень интересно разбираться с тонкостями настройки kafka. Это хорошо , согласуется с опытом Avito.
В итоге мы реализовали упрощающий pub-sub интерфейс, позволяющий не думать об этом.
Систему делали для того, чтобы поставить её перед текущим боевым кластером, соответственно нагрузка на него определяла требования к прослойке.
Те самые миллионы rps - это нагрузка от тысяч различных потребителей по методам кафки produce и fetch (не единичные сообщения!). Мы постоянно работаем над оптимизацией потребителей через убеждение и тюнинг платформенных библиотек, но текущая ситуация именно такая.
Консьюмеров мы конечно уже реализовали, в статье об этом написано.
Как и задумывалось, api предоставляет сильно упрощённый функционал, его для большинства сценариев хватает.
Абстракция, разумеется, не идеальная — если сделать клиентов-консьюмеров больше чем партиций, то лишние будут простаивать. Это сделано намеренно, чтобы не усложнять реализацию.
Безусловно вы правы.
Выбор оптимизируемой метрики определяется целью — в нашем случае нужно было держать нагрузку на продовый кластер без чрезмерного оверхеда.
Поскольку кафка занимается в основном перекладыванием байтиков, то и оптимизировали мы именно его :)
Хорошее замечание, спасибо.
NATS к сожалению обеспечивает лишь гарантии at most once в безброкерном режиме, а с брокером смысл его использования теряется. Кроме того задача переезда на него гораздо тяжелее чем задача переезда на grpc-прокси перед kafka без переезда данных.
Ну и проблемы с библиотеками от этого никуда не деваются :)
Я в процессе отладки не раз подозревал GC, но ни разу он не был виновен - трейсинг хорошо позволяет отслеживать такое. На горячем пути в grpc и franz-go действительно в основном пулы объектов под капотом.
Идея про С++/Rust расcматривалась скорее в полушуточном режиме, поскольку мы не упирались в язык, а в команде экспертизы по Go заметно больше :)
Для подобных систем в целом валидно отправлять каждое событие в кафку, другое дело, что эти отправки стоит батчить, чтобы не создавать чрезмерную нагрузку на брокеры.
Потребность управлять поведением клиентов - как раз одна из основных причин создания data-bus, там зачастую что-то нездоровое происходит.
Посмотрел крупнейших потребителей - в топе рекламная сеть, аналитика и система защиты от ботов.
Тогда возможно вам будет интересно ознакомиться с проектом https://github.com/mailgun/kafka-pixy, хоть он и не имеет полноценной поддержки (последний релиз был в 2019), но как минимум из него можно черпать вдохновение :)
Вы оперируете интересными числами неизвестного происхождения в своих предположениях :)
Не думаю, что я смогу комплексно ответить на ваш вопрос за пределами уже сказанного.
Нагрузка на гейтвее скорее ближе к сотне тысяч rps, а дальше микросервисная архитектура делает своё дело — у нас сейчас около 4 тысяч сервисов.