А как проверять качество звукоизоляции на каждом шаге? Там же дофига возможностей: не сделать мостик, не сделать звукоизоляцию подрозетников (если внутри квартиры), сделать стык полов между комнатами, пробить плавающий пол каким-нибудь крепежом - и так далее и так далее...
Потребление памяти вообще не существенно, в описанном примере просто можно через синглтон получать данные по объекту и не плодить кучу экземпляров одной сущности в одном сервисе (и в нормальной архитектуре клиента такая потребность даже не должна была возникнуть). При работе с кэшами (и не только, при распределенном взаимодействии вообще) много сил уходит на сам процесс сериализации/десериализации и часто хочется оптимзировать его, а не доступ к БД.
А есть пример продуктов, сделанных в аутсорсе такими командами? Ну и разница в разработке в "в пять раз" - это не очень много, это (на уровне всего продукта) где-то процентов 15 экономии. А с учетом "стало дешевле делать фичи - значит будем делать больше ненужных фич", реально для продуктов практически ничего не поменяется. Интересно будет, когда весь процесс разработки (от идеи и до продуктовой аналитики после выкатки) удастся упаковать в AI-цикл, там разница может быть существенной. Сейчас такие примеры есть, но крайне редкие и для микробизнесов. Тем более, что нормальных описаний предметных областей в моделях нет и научиться им пока неоткуда (
Хмм, 1. Вот тут хочется какое-то конкретное исследование увидеть, а не "слова". Ну хотя бы понять, на каком именно бенчмарке неточные формулировки улучшают результаты. 2. Нет, агенты категорически не понятливы. Они пытаются делать иллюзию понятливости (потому что так обучены), но понятливости им неоткуда взять. 3. Нет, здравого смысла у моделей нет. У них есть статистическое представление о том, чем их учили, но заметная часть текстов для обучения не содержит и зачатков здравого смысла, увы. Но сверить свои выводы с реальным миром модели не могут, так как (пока еще) у них нет модели реального мира. И контекст из "воздуха" модели брать, увы, не умеют. 4. С моделями надо общаться не так, как с людьми - это да. Для них важны другие вещи, другие детали, другое описание контекста. И для разных моделей - важно разное, что делает разработку под модели еще интереснее, вспоминаются времена браузерных войн... 5. Модели многое делают лучше человека. А многое - хуже. Это утверждение - не имеет смысла.
Автор статьи говорит о том, что средний человек (без специальных умений и знаний) не сможет сформулировать "а что ему надо", для этого нужен специалист, которого традиционно называют программистом. И хороший программист (инженер) всегда и отличался умением переводить с русского на русский и умением задавать правильные вопросы, а знание языков программирования было уже вторичным. И вот этот навык пока еще у человека получается лучше. А кодеры - да, вымрут. Как вымерли наборщики перфоркарт.
Ну, если бы в 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.
Если в проекте длительное время погружения, то это проблемы организации проекта. Пользу от нового сотрудника на уровне миддл и выше можно начать получать практически сразу (неделя-две максимум). Ну и текущие методы проверки - все равно не дают какой-то вменяемой информации о кандидате, так что через месяц тоже легко выяснится, что кандидат не соответствует.
Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки? Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список. И что именно "все равно не выигрывает по скорости", можешь уточнить?
А как проверять качество звукоизоляции на каждом шаге?
Там же дофига возможностей: не сделать мостик, не сделать звукоизоляцию подрозетников (если внутри квартиры), сделать стык полов между комнатами, пробить плавающий пол каким-нибудь крепежом - и так далее и так далее...
Потребление памяти вообще не существенно, в описанном примере просто можно через синглтон получать данные по объекту и не плодить кучу экземпляров одной сущности в одном сервисе (и в нормальной архитектуре клиента такая потребность даже не должна была возникнуть).
При работе с кэшами (и не только, при распределенном взаимодействии вообще) много сил уходит на сам процесс сериализации/десериализации и часто хочется оптимзировать его, а не доступ к БД.
А есть пример продуктов, сделанных в аутсорсе такими командами? Ну и разница в разработке в "в пять раз" - это не очень много, это (на уровне всего продукта) где-то процентов 15 экономии. А с учетом "стало дешевле делать фичи - значит будем делать больше ненужных фич", реально для продуктов практически ничего не поменяется.
Интересно будет, когда весь процесс разработки (от идеи и до продуктовой аналитики после выкатки) удастся упаковать в AI-цикл, там разница может быть существенной. Сейчас такие примеры есть, но крайне редкие и для микробизнесов.
Тем более, что нормальных описаний предметных областей в моделях нет и научиться им пока неоткуда (
Хмм,
1. Вот тут хочется какое-то конкретное исследование увидеть, а не "слова". Ну хотя бы понять, на каком именно бенчмарке неточные формулировки улучшают результаты.
2. Нет, агенты категорически не понятливы. Они пытаются делать иллюзию понятливости (потому что так обучены), но понятливости им неоткуда взять.
3. Нет, здравого смысла у моделей нет. У них есть статистическое представление о том, чем их учили, но заметная часть текстов для обучения не содержит и зачатков здравого смысла, увы. Но сверить свои выводы с реальным миром модели не могут, так как (пока еще) у них нет модели реального мира. И контекст из "воздуха" модели брать, увы, не умеют.
4. С моделями надо общаться не так, как с людьми - это да. Для них важны другие вещи, другие детали, другое описание контекста. И для разных моделей - важно разное, что делает разработку под модели еще интереснее, вспоминаются времена браузерных войн...
5. Модели многое делают лучше человека. А многое - хуже. Это утверждение - не имеет смысла.
Автор статьи говорит о том, что средний человек (без специальных умений и знаний) не сможет сформулировать "а что ему надо", для этого нужен специалист, которого традиционно называют программистом. И хороший программист (инженер) всегда и отличался умением переводить с русского на русский и умением задавать правильные вопросы, а знание языков программирования было уже вторичным.
И вот этот навык пока еще у человека получается лучше.
А кодеры - да, вымрут. Как вымерли наборщики перфоркарт.
Интересно, откуда вообще появился миф, что 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.
Если в проекте длительное время погружения, то это проблемы организации проекта.
Пользу от нового сотрудника на уровне миддл и выше можно начать получать практически сразу (неделя-две максимум).
Ну и текущие методы проверки - все равно не дают какой-то вменяемой информации о кандидате, так что через месяц тоже легко выяснится, что кандидат не соответствует.
Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки?
Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список.
И что именно "все равно не выигрывает по скорости", можешь уточнить?