Ну, если бы в Go были строки, то можно было бы написать что-то похожее и на Go. Но увы, есть только байтовые массивы и чуть-чуть функций сверху, поэтому эффективнее будет сделать честную маршализацию.
Ну, на Go писать приличный код, пожалуй, еще сложнее и еще реже встречается, язык все-таки гораздо примитивнее, многих вещей нет или их не принято использовать.
При этом, конечно, хорошо, что в Yandex Cloud есть поддержка SQS. Это и упрощает миграцию с AWS и дает простой механизм для распределения задач по воркерам для не слишком нагруженных проектов. И для не очень опытных разработчиков (или вайбкодеров) шансов прострелить себе ногу на SQS/YMQ поменьше, чем на kafka или rmq. Особенно с YMQ trigger или при использовании стандартных рекомендаций на автоскейлинг. Для Kafka автоскейлинг прикрутить будет несколько сложнее и требует больше знаний.
Ну, почему SQS не популярен - понятно. 1. Очень много ограничений. Максимальный размер батча - 10 сообщений. FIFO очередь в AWS не может обработать больше 3000 сообщений в секунду (с максимальным батчингом), в Yandex Cloud не больше 300 сообщений в секунду. Для не FIFO очередей требования в AWS послабее, для YC - не больше 3000 сообщений в секунду. В AWS есть еще high-throughput FIFO, но и там все очень зависит от региона и до кафки совсем не дотягивает (и, по сути, это про дефолтовое число партиций...) 2. Нужно постоянно следить за visibility timeout, который сильно влияет на эластичность запросов и может приводить к нетривиальным проблемам. Особенно на пару с ограничением на In-flight messages
Т.е. единственное, для чего вообще можно применить SQS в реальных системах - это как раз не слишком нагруженная обработка относительно тяжелых и довольно одинаковых задач. Но и в этом случае придется подумать над разными обвязками. Для любых других задач SQS категорически неприменим. Но даже для очередей я бы взял kafka, так как проще, надежнее и популярнее и позволяет делать кучу прикольных оптимизаций.
Не совсем понятно, а с чего бы у Kafka проблема с равномерным распределением данных? Просто не надо создавать топики с одной партиции, а делать хотя бы небольшой запас по числу партиций (обычно стоит говорить о 60-120), для большей части применений это не стоит ничего. Потребность в масштабировании в 1000 раз достаточно маловероятна (и за это время можно и число партиций изменить).
А если требуется порядок обработки, то в SQS тоже нужно проектировать работу с MessageGroupId (и разбираться с особенностями DeleteMessage при групповой обработке).
Так у Kafka тоже очень простое API (отправить событие, получить событие), не сложнее SQS. У Kafka есть много разных особенностей настройки системы для получения нужных гарантий, ну так и в SQS тоже многое есть (выбор типа топиков, настройка топика и так далее). Ну и магии не бывает, миллион топиков и на SQS не сделать дешево (
Ну, вообще нормальные знания для senior-dev. Вернее, знание, что гарантий обработки в общем случае не бывает и если знать парочку вариантов для частных случаев.
В общем виде - решения нет. Например, если при обработке отправляется неидемпотентный внешний вызов, то ничего не придумать внутри обработки. В частных случаях - да, можно что-то придумать.
Как я понимаю, речь идет о городских сервисах Яндекса (Такси, Доставка, Еда и так далее)? Вроде бы общее число каких-то пользовательских операций (поездок, покупок) скорее около десятков в секунду, а признаки нужны при проведении каких-то пользовательских действий. Вот я и пытаюсь понять, как 5 поездок в секунду в Яндекс.Такси (примерно) превращаются в тысячи и десятки тысяч запросов на чтение признаков.
И на схеме есть PG и Redis, какие задачи они выполняют?
Хм, а в чем проблема со стандартизацией? Там же договорится о десятке основных полей (без которых централизованное логирование все равно смысла не имеет) - и все. А уж всякую специфику типа "идентификатор сущности, специфичный для логов конкретного сервиса" не вытаскивать в колонку на CH, а писать в мапу.
Т.е. не понятно, почему не справились со связкой vector+CH, она как раз нормально работает на подобных задачах.
(Хотя VictoriaLogs - хорошее решение, кто бы спорил).
А почему нельзя стандартизировать логи, даже на 2000 сервисах? Вроде бы это задача платформенной команды или, хотя бы, соглашения и без единого формата (наличия базовых общих полей) единое хранилище логов не имеет особого смысла - зачем логи, если нет даже correlationId? А в CH нет особых проблем только базовые (стандартные) поля писать в отдельные колонки, а всякую специфику - раскладывать в массив. Более того, подготовку для этого не сложно сделать прямо на vector.
Если в проекте длительное время погружения, то это проблемы организации проекта. Пользу от нового сотрудника на уровне миддл и выше можно начать получать практически сразу (неделя-две максимум). Ну и текущие методы проверки - все равно не дают какой-то вменяемой информации о кандидате, так что через месяц тоже легко выяснится, что кандидат не соответствует.
Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки? Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список. И что именно "все равно не выигрывает по скорости", можешь уточнить?
Во-первых, ты не привел ссылок (или каких-то уникальных параметров, по которым можно найти исследования). Во-вторых, те исследования, что удалось найти - не про "сравнение времени разработки", да и корректными их не назвать (
Хм, меньше всего строк получается на APL (впрочем, он действительно высокоуровневый). И вот на MUMPS гораздо компактнее выглядит код, нежели на SQL (но тут дело не в уровне).
Наверно и разрабатывать на этих языках быстрее (но нет...). Ну и когнитивная нагрузка от числа строк вообще не зависит, разумеется )
Исследование про оплату - никак не оценивает относительное качество кандидатов, так что его можно сразу выбросить, оно не дает никакой информации.
Все процитированные исследования про ЯП - не дают никакой информации про скорость разработки, у них просто дизайн такой, что к скорости разработки не имеет значения. А вот качество дефектов на функциональную точку у Питона выше (по той же статье Capers Jones, но это тоже не важно, так как это про абстрактный Питон, а не про реальную разработку.
Ты не привел никакой информации про сокращения из мира Java. В Сбере используется куча технологий, в PT вообще нет Java в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.
Интересно, откуда вообще появился миф, что Go - быстрый?
Ну, если бы в Go были строки, то можно было бы написать что-то похожее и на Go.
Но увы, есть только байтовые массивы и чуть-чуть функций сверху, поэтому эффективнее будет сделать честную маршализацию.
Ну, на Go писать приличный код, пожалуй, еще сложнее и еще реже встречается, язык все-таки гораздо примитивнее, многих вещей нет или их не принято использовать.
При этом, конечно, хорошо, что в Yandex Cloud есть поддержка SQS. Это и упрощает миграцию с AWS и дает простой механизм для распределения задач по воркерам для не слишком нагруженных проектов. И для не очень опытных разработчиков (или вайбкодеров) шансов прострелить себе ногу на SQS/YMQ поменьше, чем на kafka или rmq. Особенно с YMQ trigger или при использовании стандартных рекомендаций на автоскейлинг. Для Kafka автоскейлинг прикрутить будет несколько сложнее и требует больше знаний.
Ну, почему SQS не популярен - понятно.
1. Очень много ограничений. Максимальный размер батча - 10 сообщений. FIFO очередь в AWS не может обработать больше 3000 сообщений в секунду (с максимальным батчингом), в Yandex Cloud не больше 300 сообщений в секунду. Для не FIFO очередей требования в AWS послабее, для YC - не больше 3000 сообщений в секунду.
В AWS есть еще high-throughput FIFO, но и там все очень зависит от региона и до кафки совсем не дотягивает (и, по сути, это про дефолтовое число партиций...)
2. Нужно постоянно следить за visibility timeout, который сильно влияет на эластичность запросов и может приводить к нетривиальным проблемам. Особенно на пару с ограничением на In-flight messages
Т.е. единственное, для чего вообще можно применить SQS в реальных системах - это как раз не слишком нагруженная обработка относительно тяжелых и довольно одинаковых задач. Но и в этом случае придется подумать над разными обвязками. Для любых других задач SQS категорически неприменим.
Но даже для очередей я бы взял kafka, так как проще, надежнее и популярнее и позволяет делать кучу прикольных оптимизаций.
Не совсем понятно, а с чего бы у Kafka проблема с равномерным распределением данных?
Просто не надо создавать топики с одной партиции, а делать хотя бы небольшой запас по числу партиций (обычно стоит говорить о 60-120), для большей части применений это не стоит ничего. Потребность в масштабировании в 1000 раз достаточно маловероятна (и за это время можно и число партиций изменить).
А если требуется порядок обработки, то в SQS тоже нужно проектировать работу с MessageGroupId (и разбираться с особенностями DeleteMessage при групповой обработке).
Так у Kafka тоже очень простое API (отправить событие, получить событие), не сложнее SQS. У Kafka есть много разных особенностей настройки системы для получения нужных гарантий, ну так и в SQS тоже многое есть (выбор типа топиков, настройка топика и так далее). Ну и магии не бывает, миллион топиков и на SQS не сделать дешево (
Ну, вообще нормальные знания для senior-dev. Вернее, знание, что гарантий обработки в общем случае не бывает и если знать парочку вариантов для частных случаев.
В общем виде - решения нет. Например, если при обработке отправляется неидемпотентный внешний вызов, то ничего не придумать внутри обработки.
В частных случаях - да, можно что-то придумать.
Как я понимаю, речь идет о городских сервисах Яндекса (Такси, Доставка, Еда и так далее)? Вроде бы общее число каких-то пользовательских операций (поездок, покупок) скорее около десятков в секунду, а признаки нужны при проведении каких-то пользовательских действий.
Вот я и пытаюсь понять, как 5 поездок в секунду в Яндекс.Такси (примерно) превращаются в тысячи и десятки тысяч запросов на чтение признаков.
И на схеме есть PG и Redis, какие задачи они выполняют?
Спасибо за ответы!
А откуда берется 100k RPS на чтение и 30k RPS на запись?
Откуда так много?
И зачем хранить два варианта payload (String и json)?
Хм, а в чем проблема со стандартизацией? Там же договорится о десятке основных полей (без которых централизованное логирование все равно смысла не имеет) - и все.
А уж всякую специфику типа "идентификатор сущности, специфичный для логов конкретного сервиса" не вытаскивать в колонку на CH, а писать в мапу.
Т.е. не понятно, почему не справились со связкой vector+CH, она как раз нормально работает на подобных задачах.
(Хотя VictoriaLogs - хорошее решение, кто бы спорил).
А почему нельзя стандартизировать логи, даже на 2000 сервисах? Вроде бы это задача платформенной команды или, хотя бы, соглашения и без единого формата (наличия базовых общих полей) единое хранилище логов не имеет особого смысла - зачем логи, если нет даже correlationId?
А в CH нет особых проблем только базовые (стандартные) поля писать в отдельные колонки, а всякую специфику - раскладывать в массив. Более того, подготовку для этого не сложно сделать прямо на vector.
Если в проекте длительное время погружения, то это проблемы организации проекта.
Пользу от нового сотрудника на уровне миддл и выше можно начать получать практически сразу (неделя-две максимум).
Ну и текущие методы проверки - все равно не дают какой-то вменяемой информации о кандидате, так что через месяц тоже легко выяснится, что кандидат не соответствует.
Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки?
Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список.
И что именно "все равно не выигрывает по скорости", можешь уточнить?
Эээ, а как многопоточность связана с CPU bound? Как раз наоборот, для CPU bound многопоточность не очень важна, там и с воркерами не сложно разрулить.
Во-первых, ты не привел ссылок (или каких-то уникальных параметров, по которым можно найти исследования).
Во-вторых, те исследования, что удалось найти - не про "сравнение времени разработки", да и корректными их не назвать (
Хм, меньше всего строк получается на APL (впрочем, он действительно высокоуровневый).
И вот на MUMPS гораздо компактнее выглядит код, нежели на SQL (но тут дело не в уровне).
Наверно и разрабатывать на этих языках быстрее (но нет...).
Ну и когнитивная нагрузка от числа строк вообще не зависит, разумеется )
Исследование про оплату - никак не оценивает относительное качество кандидатов, так что его можно сразу выбросить, оно не дает никакой информации.
Все процитированные исследования про ЯП - не дают никакой информации про скорость разработки, у них просто дизайн такой, что к скорости разработки не имеет значения. А вот качество дефектов на функциональную точку у Питона выше (по той же статье Capers Jones, но это тоже не важно, так как это про абстрактный Питон, а не про реальную разработку.
Ты не привел никакой информации про сокращения из мира Java. В Сбере используется куча технологий, в PT вообще нет Java в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.