Ну, вообще нормальные знания для senior-dev. Вернее, знание, что гарантий обработки в общем случае не бывает и если знать парочку вариантов для частных случаев.
В общем виде - решения нет. Например, если при обработке отправляется неидемпотентный внешний вызов, то ничего не придумать внутри обработки. В частных случаях - да, можно что-то придумать.
Как я понимаю, речь идет о городских сервисах Яндекса (Такси, Доставка, Еда и так далее)? Вроде бы общее число каких-то пользовательских операций (поездок, покупок) скорее около десятков в секунду, а признаки нужны при проведении каких-то пользовательских действий. Вот я и пытаюсь понять, как 5 поездок в секунду в Яндекс.Такси (примерно) превращаются в тысячи и десятки тысяч запросов на чтение признаков.
И на схеме есть PG и Redis, какие задачи они выполняют?
Хм, а в чем проблема со стандартизацией? Там же договорится о десятке основных полей (без которых централизованное логирование все равно смысла не имеет) - и все. А уж всякую специфику типа "идентификатор сущности, специфичный для логов конкретного сервиса" не вытаскивать в колонку на CH, а писать в мапу.
Т.е. не понятно, почему не справились со связкой vector+CH, она как раз нормально работает на подобных задачах.
(Хотя VictoriaLogs - хорошее решение, кто бы спорил).
А почему нельзя стандартизировать логи, даже на 2000 сервисах? Вроде бы это задача платформенной команды или, хотя бы, соглашения и без единого формата (наличия базовых общих полей) единое хранилище логов не имеет особого смысла - зачем логи, если нет даже correlationId? А в CH нет особых проблем только базовые (стандартные) поля писать в отдельные колонки, а всякую специфику - раскладывать в массив. Более того, подготовку для этого не сложно сделать прямо на vector.
Если в проекте длительное время погружения, то это проблемы организации проекта. Пользу от нового сотрудника на уровне миддл и выше можно начать получать практически сразу (неделя-две максимум). Ну и текущие методы проверки - все равно не дают какой-то вменяемой информации о кандидате, так что через месяц тоже легко выяснится, что кандидат не соответствует.
Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки? Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список. И что именно "все равно не выигрывает по скорости", можешь уточнить?
Во-первых, ты не привел ссылок (или каких-то уникальных параметров, по которым можно найти исследования). Во-вторых, те исследования, что удалось найти - не про "сравнение времени разработки", да и корректными их не назвать (
Хм, меньше всего строк получается на APL (впрочем, он действительно высокоуровневый). И вот на MUMPS гораздо компактнее выглядит код, нежели на SQL (но тут дело не в уровне).
Наверно и разрабатывать на этих языках быстрее (но нет...). Ну и когнитивная нагрузка от числа строк вообще не зависит, разумеется )
Исследование про оплату - никак не оценивает относительное качество кандидатов, так что его можно сразу выбросить, оно не дает никакой информации.
Все процитированные исследования про ЯП - не дают никакой информации про скорость разработки, у них просто дизайн такой, что к скорости разработки не имеет значения. А вот качество дефектов на функциональную точку у Питона выше (по той же статье Capers Jones, но это тоже не важно, так как это про абстрактный Питон, а не про реальную разработку.
Ты не привел никакой информации про сокращения из мира Java. В Сбере используется куча технологий, в PT вообще нет Java в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.
И, да, производительность таки важна. Так как число rps на сервис - это не число входящих запросов на систему. Вон, в Озоне больше 5 миллионов событий в секунду только на кафка, не считая всех прочих взаимодействий - и при этом число показываемых страниц около 1000 в секунду, да и то не всегда. И число активных клиентов заметно меньше 100 млн. Статистика - это сложная штука и с ней надо обращаться аккуратно.
На Java скорость промышленной разработки с использованием существующей экосистемы как минимум не ниже, нежели на Python. Общее TCO скорее ниже, так как выше средний уровень разработчиков, выше качество библиотек и проще достигается высокое качество кода.
Оплата при равных навыках - примерно одинаковая во всех стеках (ну, разве что в Go сейчас заметно больше в РФ). Ключевое - "при равных навыках".
Ни одно из указанных исследований не показывает преимущество Python перед Java по скорости разработки, так как ни одно из них не измеряет скорость разработки хоть сколь-нибудь корректным образом. И это очевидно для любого, кто прочтет хотя бы одно исследование.
Ну, собственно на java делать микросервисы очень удобно, там для этого все есть. Другое дело, что на java можно и не делать микросервисы, а вот это более редкая возможность )
Расчеты как раз внимательно рассматривают. Но, увы, расчеты некорректные, начиная от исходных данных (придуманных автором и нигде не подтвержденных) и заканчивая непониманием базовых вещей в современной разработке (стоимость исправления дефектов, стоимость изменений, ориентированность на фреймворки и так далее).
Если бы статья была ровно про "производительность сервиса не так важна, как эффективность разработки" с указанием конкретных случаев, то вопросов к автору было бы гораздо меньше (ну, если бы с арифметикой не налажал бы). Но автор пытается сравнивать языки, не будучи достаточно компетентным в этом (т.е. просто не разбираясь ни в одном языке кроме Питона, да и в Питоне не очень).
Нет, в статье нет никаких ссылок на осмысленные международные исследования (о чем тебе много раз сказали). Более того, даже выводы из этих исследований сделать не получилось, так как со статистикой надо уметь работать. О чем тебе много раз и указывали.
Ну, вообще нормальные знания для 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 в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.
От "добавили возможность" до "разработчики научаться и библиотеки подтянутся" обычно проходит лет пять )
И, да, производительность таки важна. Так как число rps на сервис - это не число входящих запросов на систему. Вон, в Озоне больше 5 миллионов событий в секунду только на кафка, не считая всех прочих взаимодействий - и при этом число показываемых страниц около 1000 в секунду, да и то не всегда. И число активных клиентов заметно меньше 100 млн.
Статистика - это сложная штука и с ней надо обращаться аккуратно.
На Java скорость промышленной разработки с использованием существующей экосистемы как минимум не ниже, нежели на Python. Общее TCO скорее ниже, так как выше средний уровень разработчиков, выше качество библиотек и проще достигается высокое качество кода.
Оплата при равных навыках - примерно одинаковая во всех стеках (ну, разве что в Go сейчас заметно больше в РФ). Ключевое - "при равных навыках".
Ни одно из указанных исследований не показывает преимущество Python перед Java по скорости разработки, так как ни одно из них не измеряет скорость разработки хоть сколь-нибудь корректным образом. И это очевидно для любого, кто прочтет хотя бы одно исследование.
Ну, собственно на java делать микросервисы очень удобно, там для этого все есть. Другое дело, что на java можно и не делать микросервисы, а вот это более редкая возможность )
Расчеты как раз внимательно рассматривают. Но, увы, расчеты некорректные, начиная от исходных данных (придуманных автором и нигде не подтвержденных) и заканчивая непониманием базовых вещей в современной разработке (стоимость исправления дефектов, стоимость изменений, ориентированность на фреймворки и так далее).
Если бы статья была ровно про "производительность сервиса не так важна, как эффективность разработки" с указанием конкретных случаев, то вопросов к автору было бы гораздо меньше (ну, если бы с арифметикой не налажал бы). Но автор пытается сравнивать языки, не будучи достаточно компетентным в этом (т.е. просто не разбираясь ни в одном языке кроме Питона, да и в Питоне не очень).
Кстати, я так и не понял, какая именно статья Capers Jones имеется в виду.
В статье от 2017 года https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf указывается, что затраты на одну функциональную точку для Java, Go и Python - одинаковые. У C#, кстати, чуть-чуть поменьше. Но там анализ из "общих принципов", без конкретной статистики.
Я не смог найти у Caper Jones статьи, где бы говорилось о преимуществах Python перед Go.
Нет, в статье нет никаких ссылок на осмысленные международные исследования (о чем тебе много раз сказали). Более того, даже выводы из этих исследований сделать не получилось, так как со статистикой надо уметь работать. О чем тебе много раз и указывали.