обновил гардероб :)
System Design & Highload (Alexey Rybak)
@rybakalexey
Архитектура больших проектов и управление продуктово-инженерными организациями; статьи, выступления по теме управление и разработка больших IT-проектов. Https://DevHands.io - хайлоад-прокачка бекендеров. ЛС: @alexeyrybak.
System Design & Highload (Alexey Rybak)
20 Oct, 08:59
Лайк, если знаешь, что общего между картинкой и 🦙-book :)
System Design & Highload (Alexey Rybak)
18 Oct, 15:18
DHH посчитал, что сэкономит более $10 млн, уйдя из облаков
David Heinemeier Hansson (hey.com, а также BaseCamp, Ruby-on-Rails, Rework, Remote, как говорится, to name a few) на днях поделился выкладками по экономии от перехода из клаудов в онпрем. Чтобы не читать восемь абзацов, вот вам сухие цифры в одном: потратили $700,000 на железо (Dell), облачный кост снизили с $3.2 million/year до $1.3 million. Оставшееся - 10 петабайт в S3 на Амазоне, на 4-х летнем котракте; за сумму равной годовому чеку, они закупят ещё железа, и уедут из облаков совсем. Сравнение, конечно, не совсем корректное, но в тренде! Так что следим и учимся системному дизайну и планированию мощностей, чтобы уметь в self managed или хотя бы считать и оптимизировать облачный кост 🙂
https://world.hey.com/dhh/our-cloud-exit-savings-will-now-top-ten-million-over-five-years-c7d9b5bd
David Heinemeier Hansson (hey.com, а также BaseCamp, Ruby-on-Rails, Rework, Remote, как говорится, to name a few) на днях поделился выкладками по экономии от перехода из клаудов в онпрем. Чтобы не читать восемь абзацов, вот вам сухие цифры в одном: потратили $700,000 на железо (Dell), облачный кост снизили с $3.2 million/year до $1.3 million. Оставшееся - 10 петабайт в S3 на Амазоне, на 4-х летнем котракте; за сумму равной годовому чеку, они закупят ещё железа, и уедут из облаков совсем. Сравнение, конечно, не совсем корректное, но в тренде! Так что следим и учимся системному дизайну и планированию мощностей, чтобы уметь в self managed или хотя бы считать и оптимизировать облачный кост 🙂
https://world.hey.com/dhh/our-cloud-exit-savings-will-now-top-ten-million-over-five-years-c7d9b5bd
System Design & Highload (Alexey Rybak)
18 Oct, 12:28
Cистемный дизайн №3 - ещё и с Перепелицей!
Наш следующий митап по системному дизайну уже в следующий четверг, 24-го октября, в 18:00 MSK. Мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
К гостям, которые у нас были на прошлых стримах, присоединится Володя Перепелица, и список гостей у нас ещё больше огого:
* Владимир Перепелица. Эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.
* Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке.
* Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.
В этот раз рассмотрим одну главу, зато какую:
* Проектирование хранилища типа “ключ-значение”
Внутри этой главы ни много ни мало CAP-теорема и собственно проектирование kv-хранилища.
И кстати! Владимир Перепелица на платформе devhands запускает новый поток своего мега-курса по очередям, на этот раз с прицельным фокусом на Kafka и NATS. Регистрация открыта, старт 13-го ноября, приходите, приводите друзей.
🗓 Чтобы не пропустить митап, не забудьте сделать два простых шага:
➡ Поставить в календарь напоминание о встрече (24-го октября 18:00 MSK)
➡ Вступите в чат https://t.me/AlexeyRybakChat: за сутки и за час до встречи там будут напоминания и все ссылки
Предыдущие стримы (первый, второй) смотрите на YouTube-канале: https://www.youtube.com/@AlexeyRybak
До встречи!
Наш следующий митап по системному дизайну уже в следующий четверг, 24-го октября, в 18:00 MSK. Мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
К гостям, которые у нас были на прошлых стримах, присоединится Володя Перепелица, и список гостей у нас ещё больше огого:
* Владимир Перепелица. Эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.
* Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке.
* Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.
В этот раз рассмотрим одну главу, зато какую:
* Проектирование хранилища типа “ключ-значение”
Внутри этой главы ни много ни мало CAP-теорема и собственно проектирование kv-хранилища.
И кстати! Владимир Перепелица на платформе devhands запускает новый поток своего мега-курса по очередям, на этот раз с прицельным фокусом на Kafka и NATS. Регистрация открыта, старт 13-го ноября, приходите, приводите друзей.
➡ Поставить в календарь напоминание о встрече (24-го октября 18:00 MSK)
➡ Вступите в чат https://t.me/AlexeyRybakChat: за сутки и за час до встречи там будут напоминания и все ссылки
Предыдущие стримы (первый, второй) смотрите на YouTube-канале: https://www.youtube.com/@AlexeyRybak
До встречи!
System Design & Highload (Alexey Rybak)
17 Oct, 07:27
ScyllaDB в Medium
Если интересуетесь распределенными базами данных вообще либо Сциллой в частности, то вот относительно свежая статья от инженерной команды Meduim про то, как в Medim используется распределенная СУБД ScyllaDB для хранения специализированных списков атрибутов, потребляемых ML-движком рекомендаций.
Статьи пишет один автор (Andréas Saudemont) в довольно академичном ключе, первая статья в этой серии вообще была чересчур общая на мой вкус. Но в этой второй статье интересен “немаркетинговый” рассказ об устройстве базы ScyllaDB простым языком, и это мне показалось интересным. А ещё, например, я с удивлением узнал, что движок Scylla поддердживает TTL аналогично кеш-сервисам и самостоятельно чистит устаревшие данные. Кто ещё из СУБД так умеет? Redis в качестве СУБД не предлагать 😉
Если интересуетесь распределенными базами данных вообще либо Сциллой в частности, то вот относительно свежая статья от инженерной команды Meduim про то, как в Medim используется распределенная СУБД ScyllaDB для хранения специализированных списков атрибутов, потребляемых ML-движком рекомендаций.
Статьи пишет один автор (Andréas Saudemont) в довольно академичном ключе, первая статья в этой серии вообще была чересчур общая на мой вкус. Но в этой второй статье интересен “немаркетинговый” рассказ об устройстве базы ScyllaDB простым языком, и это мне показалось интересным. А ещё, например, я с удивлением узнал, что движок Scylla поддердживает TTL аналогично кеш-сервисам и самостоятельно чистит устаревшие данные. Кто ещё из СУБД так умеет? Redis в качестве СУБД не предлагать 😉
System Design & Highload (Alexey Rybak)
11 Oct, 06:18
Про Python 3.13 без GIL и с JIT
Realpython опубликовал большой обзор релиза Python 3.13.
* GIL (global interpreter lock) – механизм синхронизации в Python, который сильно ограничивает писателей “наивно-мультитредовых” программ на питоне.
* JIT (just-in-time) компиляция – такая техника запуска интерпретируемого кода, когда интерпретатор в процессе исполнения компилирует байт-код в нативный машинный код (в отличие от обычной компиляции, когда машинный код генерится до исполнения).
Итак, ни много ни мало, исторический релиз питона. Скажу честно – пока не понял, что это даёт народному хозяйству. Разберемся.
GIL. Во-первых, код для веб-сервисов давно исполняется “воркерами” которыми управляет gunicorn/uWSGI. Воркеры работают независимо, поэтому есть у нас этот GIL, нет его – неважно. Для тех маньяков, что пишут сервера на питоне самостоятельно, есть Pool в multiprocessing.
Это для северов. Для не-серверов мультитредовость бы помогла известно где – AI и data-science задачи. Однако, насколько я понимаю, почти весь “успех” питона для таких задач строится вокруг библиотек, написанных не на питоне, а на C. Эти библиотеки стараются “внутри” запаралеллить по максимуму либо реализовать настраиваему в рантайме или вовсе автоматическую “мультитредовость” (на этапе компиляции) – в любом случае, GIL и этому классу задач не поможет.
Второе, JIT. Фича крутая, но вот картинка совсем не впечатляет: рост незначительный. Возможно, это лишь первый шаг. Питон разгоняют с рождения: Cython, pypy, numba, а это только самое известное и успешное, что я вспомнил, а там такой длинный список, чёрт ногу сломит. Если бы можно было в ядре питона всё переделать так, чтобы всё это добро оказалось не нужным либо включенным автоматом – было бы круто. Но пока результаты скромные.
Возможно, я не вижу общей картины, есть большой крутой роадмэп, из которого понятно, что со временем всё преобразится? В любом случае, на JIT больше надежд, чем на GIL.
Буду рад услышать ваше мнение, может, чего-то упускаю.
UPDATE: см 🔥 комменты
Realpython опубликовал большой обзор релиза Python 3.13.
* GIL (global interpreter lock) – механизм синхронизации в Python, который сильно ограничивает писателей “наивно-мультитредовых” программ на питоне.
* JIT (just-in-time) компиляция – такая техника запуска интерпретируемого кода, когда интерпретатор в процессе исполнения компилирует байт-код в нативный машинный код (в отличие от обычной компиляции, когда машинный код генерится до исполнения).
Итак, ни много ни мало, исторический релиз питона. Скажу честно – пока не понял, что это даёт народному хозяйству. Разберемся.
GIL. Во-первых, код для веб-сервисов давно исполняется “воркерами” которыми управляет gunicorn/uWSGI. Воркеры работают независимо, поэтому есть у нас этот GIL, нет его – неважно. Для тех маньяков, что пишут сервера на питоне самостоятельно, есть Pool в multiprocessing.
Это для северов. Для не-серверов мультитредовость бы помогла известно где – AI и data-science задачи. Однако, насколько я понимаю, почти весь “успех” питона для таких задач строится вокруг библиотек, написанных не на питоне, а на C. Эти библиотеки стараются “внутри” запаралеллить по максимуму либо реализовать настраиваему в рантайме или вовсе автоматическую “мультитредовость” (на этапе компиляции) – в любом случае, GIL и этому классу задач не поможет.
Второе, JIT. Фича крутая, но вот картинка совсем не впечатляет: рост незначительный. Возможно, это лишь первый шаг. Питон разгоняют с рождения: Cython, pypy, numba, а это только самое известное и успешное, что я вспомнил, а там такой длинный список, чёрт ногу сломит. Если бы можно было в ядре питона всё переделать так, чтобы всё это добро оказалось не нужным либо включенным автоматом – было бы круто. Но пока результаты скромные.
Возможно, я не вижу общей картины, есть большой крутой роадмэп, из которого понятно, что со временем всё преобразится? В любом случае, на JIT больше надежд, чем на GIL.
Буду рад услышать ваше мнение, может, чего-то упускаю.
UPDATE: см 🔥 комменты
System Design & Highload (Alexey Rybak)
09 Oct, 08:05
Valkey vs Redis: публикация на хабре.
* пропускная способность на одном графике, как попросил Олег
* больше про методику тестирования
Кстати, стал пользоваться для графиков такой штукой observable plot. Это типа те же чуваки, что и D3. Есть нарекания, но в целом удобно.
P.S. кто зареген на хабре - помогите плюсами, плз
* пропускная способность на одном графике, как попросил Олег
* больше про методику тестирования
Кстати, стал пользоваться для графиков такой штукой observable plot. Это типа те же чуваки, что и D3. Есть нарекания, но в целом удобно.
P.S. кто зареген на хабре - помогите плюсами, плз
System Design & Highload (Alexey Rybak)
09 Oct, 06:15
Redis vs Valkey (by DevHands.io): масштабируемость io-threads по ядрам процессора.
Саммари сравнения на картинке:
(1) Redis масштабируется по ядрам, но так себе
(2) Valkey выдает в 2.5 раза больше RPS при сильно меньшей latency
(3) Ни один, ни второй не увеличивают пропускную способность при числе тредов больше 8 - скорее всего, проблема single-main-thread архитектуры. Именно столько стоит у разработчиков valkey в якорных маркетинговых бенчмарках про unlocking 1 million RPS.
Дальше - PostgreSQL 17 (уже выдает на стенде свой миллион+ RPS, но отжирает весь проц), MySQL 8.4 (детка, верю в тебя) и Memcached и DragonFly.
Саммари сравнения на картинке:
(1) Redis масштабируется по ядрам, но так себе
(2) Valkey выдает в 2.5 раза больше RPS при сильно меньшей latency
(3) Ни один, ни второй не увеличивают пропускную способность при числе тредов больше 8 - скорее всего, проблема single-main-thread архитектуры. Именно столько стоит у разработчиков valkey в якорных маркетинговых бенчмарках про unlocking 1 million RPS.
Дальше - PostgreSQL 17 (уже выдает на стенде свой миллион+ RPS, но отжирает весь проц), MySQL 8.4 (детка, верю в тебя) и Memcached и DragonFly.
System Design & Highload (Alexey Rybak)
08 Oct, 13:11
Несерьёзный оффтоп-пост восторгания нейронками и про нобелевскую
Когда я был студентом МГУ, я увлёкся нелинейной динамикой. Это такая область науки, в которой изучают настолько нелинейные системы, что закон движения хоть и определен, но просчитать движения этих систем теоретически сложно либо просто невозможно, проще моделировать. Но в результате имеем кучу невероятной красоты: фракталы, экспоненциальное разбегание траекторий, хаос, самоорганизацию и вот это всё.
Много нелинейной динамики было в оптике (нелинейная оптика была моей специальностью), и однажды мне попался сборник статей, в котором помимо чисто оптических тем вдруг описывался метод коррекции изображений, из которого я узнал о существовании нейронных сетей. Я мало чего понял, только подумал, что понадобится немало счетного времени нашей альфа-станции, чтоб такое рассчитать даже на сетке 256x256. В это время в лабах стояли 486е и первые “пни”, и 8 мегабайт ОЗУ было роскошью.
И вот в этот момент, когда DEC альфа-станция была предметом гордости, нейронной сети Хопфилда уже было 15 лет! Вот как это пришло в голову людям в конце 70-х, и как они это всё проверяли - для меня загадка. Было понятно, что нейросети это круто, но мало кто понимал - насколько. Вот я вообще не понимал, например. Потом нейросетями стали активно заниматься математики, но если честно, у меня всегда было ощущение, что математики там мало - чистое такое инженерно-физическое моделирование, выход отсюда на вход сюда, о, круто, теперь попробуем это объяснить (или нет). Я и сейчас не очень в этом разбираюсь, но… будто бы всё встало на свои места, когда за нейронки премию дают Хопфилду, физику. Морали никакой нет, просто наблюдение. Ну и за физиков приятно.
Когда я был студентом МГУ, я увлёкся нелинейной динамикой. Это такая область науки, в которой изучают настолько нелинейные системы, что закон движения хоть и определен, но просчитать движения этих систем теоретически сложно либо просто невозможно, проще моделировать. Но в результате имеем кучу невероятной красоты: фракталы, экспоненциальное разбегание траекторий, хаос, самоорганизацию и вот это всё.
Много нелинейной динамики было в оптике (нелинейная оптика была моей специальностью), и однажды мне попался сборник статей, в котором помимо чисто оптических тем вдруг описывался метод коррекции изображений, из которого я узнал о существовании нейронных сетей. Я мало чего понял, только подумал, что понадобится немало счетного времени нашей альфа-станции, чтоб такое рассчитать даже на сетке 256x256. В это время в лабах стояли 486е и первые “пни”, и 8 мегабайт ОЗУ было роскошью.
И вот в этот момент, когда DEC альфа-станция была предметом гордости, нейронной сети Хопфилда уже было 15 лет! Вот как это пришло в голову людям в конце 70-х, и как они это всё проверяли - для меня загадка. Было понятно, что нейросети это круто, но мало кто понимал - насколько. Вот я вообще не понимал, например. Потом нейросетями стали активно заниматься математики, но если честно, у меня всегда было ощущение, что математики там мало - чистое такое инженерно-физическое моделирование, выход отсюда на вход сюда, о, круто, теперь попробуем это объяснить (или нет). Я и сейчас не очень в этом разбираюсь, но… будто бы всё встало на свои места, когда за нейронки премию дают Хопфилду, физику. Морали никакой нет, просто наблюдение. Ну и за физиков приятно.
System Design & Highload (Alexey Rybak)
07 Oct, 08:25
Uber’s 40M reads/sec: ByteByteGo постит интересную инфографику
Свежая статья ByteByteGo на самом деле рерайт старой большой статьи убера про то, как они сделали свой Integrated Cache / CacheFront на базе MySQL/Redis и еще каких-то мне неясных зверей.
Инсайдер в Убере говорит, что никакой больше публичной информации об этом нет. Интересно, что
- моя наглая критика паттерна кеширования read/write-through этим решением разбивается напрочь (но понятно почему - ведь это не кеш, а комплексное решение)
- если вы не знакомы с CDC (change data capture), обратите внимание, как решается проблема устаревших данных. Какой-то зверь Flux слушает бинлог и трёт кеш (trx log capture – это «ленивая» альтернатива решениям через trx db queue). Сам Flux я слышу впервые, что-то гуглится про Кубер. Знаю про Debezium, про Flux нет.
Вопрос к знатокам: что из CDC сейчас самое топовое, что умеет забрать поток и с MySQL, и с PosgtreSQL?
Свежая статья ByteByteGo на самом деле рерайт старой большой статьи убера про то, как они сделали свой Integrated Cache / CacheFront на базе MySQL/Redis и еще каких-то мне неясных зверей.
Инсайдер в Убере говорит, что никакой больше публичной информации об этом нет. Интересно, что
- моя наглая критика паттерна кеширования read/write-through этим решением разбивается напрочь (но понятно почему - ведь это не кеш, а комплексное решение)
- если вы не знакомы с CDC (change data capture), обратите внимание, как решается проблема устаревших данных. Какой-то зверь Flux слушает бинлог и трёт кеш (trx log capture – это «ленивая» альтернатива решениям через trx db queue). Сам Flux я слышу впервые, что-то гуглится про Кубер. Знаю про Debezium, про Flux нет.
Вопрос к знатокам: что из CDC сейчас самое топовое, что умеет забрать поток и с MySQL, и с PosgtreSQL?
System Design & Highload (Alexey Rybak)
05 Oct, 15:41
System Design & Highload (Alexey Rybak) pinned «»
System Design & Highload (Alexey Rybak)
05 Oct, 15:41
Пост-знакомство
Привет! За последнее время в канал пришли много новых ребят. Расскажите в комментариях, кто вы и что вам интересно?
А пока о себе:
- CTO, предприниматель. Начинал программистом. Окончил физфак МГУ.
- 12 лет проработал в Badoo/Bumble (глобальный и единственный серьёзный конкурент Tinder). С Badoo прошел путь от стартап-камикадзе до CTO. За это время мы выросли до проекта с миллиардной капитализацией, с нуля до 200 млн пользователей.
- Был генеральным директором Московского офиса и активно занимался тех-пиаром Badoo.
- Несколько лет проработал CIO в такси-сервисе “Везёт” (Лидер, Ру-Такси), до самой продажи в Яндекс.Текси, организовал технологическую составляющую сделки. В разные годы работал в Pizza Hut Technology Ventures, Constructor Group, Мамба.
Сейчас работаю над Ed&R&D-платформой devhands.io.
- Запустил несколько супер-продвинутых образовательных треков для программистов, архитекторов и инженеров инфраструктуры.
- Сотрудничаю с венчурными фондами, аудирую, помогаю продавать, покупать и интегрировать стартапы и зрелые компании.
- Слежу за технологиями и продолжаю работать руками (производительность, хайлоад, облака, распределенные системы). Член программного комитета конференции Highload.
Devhands.io: потоки, на которые ещё можно успеть:
- онлайн Итенсив по очередям: Kafka и NATS с Владимиром Перепелицей старт 13-го ноября 2024
- онлайн Системный дизайн высоко-нагруженных проектов
- онлайн хайлоад-буткемп с инфрой Производительность и масштабируемость
Devhands также предоставляет другие услуги:
- CTO-in-residence, Независимый Директор, CEO/CTO адвайзинг
- Запуск бизнесов/подразделений по модели Build-Operate-Transfer
- Аудит и оптимизация стоимости инфраструктуры (для проектов с костами от $300K/год)
- Аудит и внедрение performance review (продуктово-инженерные компании от 100 чел)
Избранные посты для IC:
- Карьера в хайлоад-проекте: часть 1 и часть 2
- Highload: cписок литературы
- CAP-теорема простыми словами
- Разбираем книгу про системный дизайн: часть 1, часть 2
- Как расти бекендеру и как подготовиться к интервью
Избранные посты для MС:
- СТО и CIO
- Удержать нельзя отпустить: часть 1 и часть 2
- CTO не CTO: часть 1 и часть 2
- Вечный вопрос про зарплаты и справедливость
- На чьём плече обезьяна
- О сроках
Привет! За последнее время в канал пришли много новых ребят. Расскажите в комментариях, кто вы и что вам интересно?
А пока о себе:
- CTO, предприниматель. Начинал программистом. Окончил физфак МГУ.
- 12 лет проработал в Badoo/Bumble (глобальный и единственный серьёзный конкурент Tinder). С Badoo прошел путь от стартап-камикадзе до CTO. За это время мы выросли до проекта с миллиардной капитализацией, с нуля до 200 млн пользователей.
- Был генеральным директором Московского офиса и активно занимался тех-пиаром Badoo.
- Несколько лет проработал CIO в такси-сервисе “Везёт” (Лидер, Ру-Такси), до самой продажи в Яндекс.Текси, организовал технологическую составляющую сделки. В разные годы работал в Pizza Hut Technology Ventures, Constructor Group, Мамба.
Сейчас работаю над Ed&R&D-платформой devhands.io.
- Запустил несколько супер-продвинутых образовательных треков для программистов, архитекторов и инженеров инфраструктуры.
- Сотрудничаю с венчурными фондами, аудирую, помогаю продавать, покупать и интегрировать стартапы и зрелые компании.
- Слежу за технологиями и продолжаю работать руками (производительность, хайлоад, облака, распределенные системы). Член программного комитета конференции Highload.
Devhands.io: потоки, на которые ещё можно успеть:
- онлайн Итенсив по очередям: Kafka и NATS с Владимиром Перепелицей старт 13-го ноября 2024
- онлайн Системный дизайн высоко-нагруженных проектов
- онлайн хайлоад-буткемп с инфрой Производительность и масштабируемость
Devhands также предоставляет другие услуги:
- CTO-in-residence, Независимый Директор, CEO/CTO адвайзинг
- Запуск бизнесов/подразделений по модели Build-Operate-Transfer
- Аудит и оптимизация стоимости инфраструктуры (для проектов с костами от $300K/год)
- Аудит и внедрение performance review (продуктово-инженерные компании от 100 чел)
Избранные посты для IC:
- Карьера в хайлоад-проекте: часть 1 и часть 2
- Highload: cписок литературы
- CAP-теорема простыми словами
- Разбираем книгу про системный дизайн: часть 1, часть 2
- Как расти бекендеру и как подготовиться к интервью
Избранные посты для MС:
- СТО и CIO
- Удержать нельзя отпустить: часть 1 и часть 2
- CTO не CTO: часть 1 и часть 2
- Вечный вопрос про зарплаты и справедливость
- На чьём плече обезьяна
- О сроках
System Design & Highload (Alexey Rybak)
04 Oct, 11:38
Запись стрима с разбором книги про системный дизайн #2
Делюсь с вами записью вчерашнего стрима с продолжением разбора книжки Алекса Сюя “Системный дизайн. Прохождение сложного интервью”.
Гости:
- Олег Волчков (Yandex, Ozon, ЖКХ-стартап)
- Михаил Курмаев (Badoo/Bumble, Т-Банк).
В этот раз дошли до 6-й главы и обсудили стратегии кеширования, проектирование ограничителя трафика, консистентное кеширование. В конце немного поездили по “косякам”, поспорили о полезности книги и методу подачи.
https://www.youtube.com/watch?v=ZxG1r5dxcKM
Можно ставить на скорость 1.5 и посмотреть всё за 40 минут.
Комментарии к формату, дополнения, пожелания - горячо привествуются!
Предыдущее видео с разбором первых глав (от нуля до миллиона пользователей, методика оценок посещяемости и нагрузки, общие принципы прохождения интервью) тут: https://www.youtube.com/watch?v=PoS5z9UrPO4
Делюсь с вами записью вчерашнего стрима с продолжением разбора книжки Алекса Сюя “Системный дизайн. Прохождение сложного интервью”.
Гости:
- Олег Волчков (Yandex, Ozon, ЖКХ-стартап)
- Михаил Курмаев (Badoo/Bumble, Т-Банк).
В этот раз дошли до 6-й главы и обсудили стратегии кеширования, проектирование ограничителя трафика, консистентное кеширование. В конце немного поездили по “косякам”, поспорили о полезности книги и методу подачи.
https://www.youtube.com/watch?v=ZxG1r5dxcKM
Можно ставить на скорость 1.5 и посмотреть всё за 40 минут.
Комментарии к формату, дополнения, пожелания - горячо привествуются!
Предыдущее видео с разбором первых глав (от нуля до миллиона пользователей, методика оценок посещяемости и нагрузки, общие принципы прохождения интервью) тут: https://www.youtube.com/watch?v=PoS5z9UrPO4
System Design & Highload (Alexey Rybak)
03 Oct, 06:48
Век живи, как говорится. У htop есть realtime-monitor загрузки ядер, который по умолчанию выглядит как эквалайзер: горизонтальный бар переменной длины слева направо.
Если у тебя 48 ядер, это неудобно, ничего не видно. Но можно переключиться вот в такой режим, как на картинке. Псевдо-графика, рисуется «график» нагрузки в области всего 3x4 символа (спасибо за уточнение, Булат)!
Достигается это за счёт всего нескольких готовых символов типа вот таких: ⠉⠛⠿⣿, но сходу в таблицах drawing characters я их почему-то не нашел (https://en.wikipedia.org/wiki/Box-drawing_characters). Кто балуется консольной графикой - можете взять на вооружение.
На графике можно видеть valkey, котрый пытается отдать под миллион RPS в solo-режиме. Как valkey скейлится по ядрам - в следующих постах.
Если у тебя 48 ядер, это неудобно, ничего не видно. Но можно переключиться вот в такой режим, как на картинке. Псевдо-графика, рисуется «график» нагрузки в области всего 3x4 символа (спасибо за уточнение, Булат)!
Достигается это за счёт всего нескольких готовых символов типа вот таких: ⠉⠛⠿⣿, но сходу в таблицах drawing characters я их почему-то не нашел (https://en.wikipedia.org/wiki/Box-drawing_characters). Кто балуется консольной графикой - можете взять на вооружение.
На графике можно видеть valkey, котрый пытается отдать под миллион RPS в solo-режиме. Как valkey скейлится по ядрам - в следующих постах.
System Design & Highload (Alexey Rybak)
02 Oct, 07:46
BFF: новое или хорошо забытое старое?
В какой-то момент чуваки, которые посчитали, что изоляция важнее всего на свете и решает просто все проблемы, вдруг обнаружили, что женить фронт с труъ-микросервисами, мягко говоря, не очень удобно. И переизобрели технологию, которой лет 20, но, как и принято, дали ей своё новое название – BFF, Backend For Frontend. Ведь бекенд и фронтенд - словно Болик и Лёлик, Вахмурка и Кржмелик (ой, палюсь) - лучшие друзья навсегда, да!
Что это за хрень BFF? Cобирательный образ, который означает следующее: вот всё то говнище, которое “приехало” во фронт из-за МСА, теперь уезжает назад на бекенд, но в отдельный слой, потому что нахер оно в Сияющем Фронте не сдалось, там и так программировать надо слишком много извилин иметь. Ну привет, ребята, вы изобрели архитектуру больших проектов 20-летней давности: внутренние высокопроизводительные сервисы, не торчащие “наружу”, в обвязке из “клея” (обычно скриптового), который довольно жёстко “сцеплен” с фронтом. И ничего плохого ни в этой сцепке, ни в самом клее нет. Просто это теперь как бы так вам сказать … это, граждане, немножочко монолит (но мы это не признаем, потому что уже сильно потратились на этот ярлык, и откатываться нельзя).
Значит, теперь на секциях сисдиза надо заучить и рисовать вот чего: фронт -> SLB -> GW -> BFF -> {MS}. А не, резонный вопрос: нафига нам теперь GW, давайте его сделаем единым с BFF! Вот, оставляю вас теперь с раздумьями, а нужен ли JWT и так ли плохо сессионное хранилище (как часть BFF).
Скажу честно, это - наброс. Где правда? Сможет ли рассыпающаяся в песок хайлоад-гвардия стряхнуть с себя паутину лет и признать, что будущее за микросервисами и кружочками? Жду срача Старого и Нового мира в каментах!
В какой-то момент чуваки, которые посчитали, что изоляция важнее всего на свете и решает просто все проблемы, вдруг обнаружили, что женить фронт с труъ-микросервисами, мягко говоря, не очень удобно. И переизобрели технологию, которой лет 20, но, как и принято, дали ей своё новое название – BFF, Backend For Frontend. Ведь бекенд и фронтенд - словно Болик и Лёлик, Вахмурка и Кржмелик (ой, палюсь) - лучшие друзья навсегда, да!
Что это за хрень BFF? Cобирательный образ, который означает следующее: вот всё то говнище, которое “приехало” во фронт из-за МСА, теперь уезжает назад на бекенд, но в отдельный слой, потому что нахер оно в Сияющем Фронте не сдалось, там и так программировать надо слишком много извилин иметь. Ну привет, ребята, вы изобрели архитектуру больших проектов 20-летней давности: внутренние высокопроизводительные сервисы, не торчащие “наружу”, в обвязке из “клея” (обычно скриптового), который довольно жёстко “сцеплен” с фронтом. И ничего плохого ни в этой сцепке, ни в самом клее нет. Просто это теперь как бы так вам сказать … это, граждане, немножочко монолит (но мы это не признаем, потому что уже сильно потратились на этот ярлык, и откатываться нельзя).
Значит, теперь на секциях сисдиза надо заучить и рисовать вот чего: фронт -> SLB -> GW -> BFF -> {MS}. А не, резонный вопрос: нафига нам теперь GW, давайте его сделаем единым с BFF! Вот, оставляю вас теперь с раздумьями, а нужен ли JWT и так ли плохо сессионное хранилище (как часть BFF).
Скажу честно, это - наброс. Где правда? Сможет ли рассыпающаяся в песок хайлоад-гвардия стряхнуть с себя паутину лет и признать, что будущее за микросервисами и кружочками? Жду срача Старого и Нового мира в каментах!
System Design & Highload (Alexey Rybak)
30 Sep, 07:23
Devhands Labs: результаты тестирования Redis.
Развенчиваем миф про Redis, который “не скейлится” по ядрам - на картинке.
Скейлится, но так себе. Миллион RPS с Redis-а не в кластерном режиме не отдать. Valkey, PostgreSQL (и надеюсь MySQL, но пока не проверили) – миллион получается. Но об этом – чуть позже :)
Xeon Gold 6312U 24/48vCPU, 128G, (10mln keys) x 256 bytes, redis-benchmark.
А кто хочет получить практику нагрузочного тестирования – приходи на буткемп.
Развенчиваем миф про Redis, который “не скейлится” по ядрам - на картинке.
Скейлится, но так себе. Миллион RPS с Redis-а не в кластерном режиме не отдать. Valkey, PostgreSQL (и надеюсь MySQL, но пока не проверили) – миллион получается. Но об этом – чуть позже :)
Xeon Gold 6312U 24/48vCPU, 128G, (10mln keys) x 256 bytes, redis-benchmark.
А кто хочет получить практику нагрузочного тестирования – приходи на буткемп.
System Design & Highload (Alexey Rybak)
28 Sep, 09:26
Devhands Open Sessions: Cистемный дизайн #2 - теперь с гостями!
Cледующий стрим по системному дизайну уже в следующий четверг, 3-го октября, в 18:00.
Мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
Вместе со мной на стрим придут замечательные гости:
◾️Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке. И скоро выпустит отличный курс на devhands!
◾️Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.
В этот раз рассмотрим темы:
◾️Стратегии кеширования и key-value хранилища
◾️Согласованное хэширование
◾️Проектирование хранилища типа “ключ-значение”"
◾️Проектирование ограничителя трафика
Запись, как обычно, через наш бот @devhands_meetup_bot (https://t.me/devhands_meetup_bot). Чтобы записаться, нужно либо нажать на кнопку “Start” в переписке (если только что добавили бота), либо просто написать “/start” (если бот уже в контактах). Важно: если вы уже записывались на наши встречи через бота - обязательно нужно его рестартовать через “/start”, иначе он не пришлёт вам ссылку на комнату и стрим.
До встречи!
P.S. Первый стрим в этой серии: https://www.youtube.com/watch?v=PoS5z9UrPO4
Предыдущие стримы см на YouTube-канале: https://www.youtube.com/@AlexeyRybak
Последний в этом году набор в осенний поток Devhands (системный дизайн, производительность, масштабирование), старт 22-го октября 2024.
Cледующий стрим по системному дизайну уже в следующий четверг, 3-го октября, в 18:00.
Мы продолжим разбирать книжку Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
Вместе со мной на стрим придут замечательные гости:
◾️Михаил Курмаев. 15 лет развивал платформу в Badoo/Bumble, сейчас в Т-Банке. И скоро выпустит отличный курс на devhands!
◾️Олег Волчков. Работал программистом в Яндексе и тимлидом в Озоне. Сейчас в ролях продукт-менеджера, разработчика и devops'а поднимает ЖКХ-стартап.
В этот раз рассмотрим темы:
◾️Стратегии кеширования и key-value хранилища
◾️Согласованное хэширование
◾️Проектирование хранилища типа “ключ-значение”"
◾️Проектирование ограничителя трафика
Запись, как обычно, через наш бот @devhands_meetup_bot (https://t.me/devhands_meetup_bot). Чтобы записаться, нужно либо нажать на кнопку “Start” в переписке (если только что добавили бота), либо просто написать “/start” (если бот уже в контактах). Важно: если вы уже записывались на наши встречи через бота - обязательно нужно его рестартовать через “/start”, иначе он не пришлёт вам ссылку на комнату и стрим.
До встречи!
P.S. Первый стрим в этой серии: https://www.youtube.com/watch?v=PoS5z9UrPO4
Предыдущие стримы см на YouTube-канале: https://www.youtube.com/@AlexeyRybak
Последний в этом году набор в осенний поток Devhands (системный дизайн, производительность, масштабирование), старт 22-го октября 2024.
System Design & Highload (Alexey Rybak)
27 Sep, 06:52
Видео стрима “Cистемный дизайн” #1
Запись вчерашнего стрима: https://www.youtube.com/live/PoS5z9UrPO4. Осенью разбираем книги (кстати, если вы вдруг что-то не читали – это отличный способ прочитать то, что откладывали). Начал с книги Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
В этот раз разобрали главы:
* Масштабирование от нуля до миллиона пользователей
* Приблизительные оценки
* Общие принципы прохождения интервью
Комментарии, замечания, пожелания по формату и предложения по дальнейшим книгам - горячо привествуются (пока хочу взять самую базу-базу хайлоада, сюя, кабанчика, видимо и книжку по ахритектурам баз и наверное database internals петрова, но, может быть, старую более фундаментальную – стоунбрейкера, и может быть что-то по производительности Linux Грегга либо старую Мисумеси-Лукидеса например - если это вообще кому-то сейчас интересно).
Запись вчерашнего стрима: https://www.youtube.com/live/PoS5z9UrPO4. Осенью разбираем книги (кстати, если вы вдруг что-то не читали – это отличный способ прочитать то, что откладывали). Начал с книги Алекса Сюя “Системный дизайн. Подготовка к сложному интервью”.
В этот раз разобрали главы:
* Масштабирование от нуля до миллиона пользователей
* Приблизительные оценки
* Общие принципы прохождения интервью
Комментарии, замечания, пожелания по формату и предложения по дальнейшим книгам - горячо привествуются (пока хочу взять самую базу-базу хайлоада, сюя, кабанчика, видимо и книжку по ахритектурам баз и наверное database internals петрова, но, может быть, старую более фундаментальную – стоунбрейкера, и может быть что-то по производительности Linux Грегга либо старую Мисумеси-Лукидеса например - если это вообще кому-то сейчас интересно).
System Design & Highload (Alexey Rybak)
25 Sep, 10:09
Ребята, редко такое публикую, но вот это – бомба. Яндекс.Облако завезло bare metal. Раньше из больших это делал только Selectel ЕМНИП плюс несколько движовых облаков поменьше типа Таймвеба. Я почему-то был уверен, что крупные гиперскейлеры такое никогда не сделают - был не прав. Возможно, тарифицируется не совсем как dedicated? Изучим.
https://yandex.cloud/ru/blog/posts/2024/09/bare-metal
https://yandex.cloud/ru/blog/posts/2024/09/bare-metal
System Design & Highload (Alexey Rybak)
25 Sep, 08:03
Ещё мифы о хайлоаде
По мотивам споров в комментариях к уютному. Есть ещё два распространенных “мифа” хайлоада.
Первый: коммерческие СУБД значительно превосходят производительность “свободных”. Это очень давно, мягко говоря, не совсем так. Да, есть миллион кейсов, и жаль, нет простого способа это проверить. Может быть, не всегда удобно. С косяками на enterprise-масштабах (сервера по ляму грина за 2-4 юнитовый бокс). С недостаточными гарантиями (спасибо АГ за комментарий). Но если говорить про производительность, то на большинстве OLTP-задач свободные СУБД работают так же производительно, как коммерческие. Если кого-то есть стенды типа моих (Xeon Gold 24/48C, 128G, NVMe) и вы готовы честно “погонять” тесты для современных версии MSSQL/Oracle - напишите, у нас может получиться интересный коллаб.
Второй: те, кто пишут на питоне (любом другом некомпилируемом языке) вообще смешно когда рассуждают о хайлоаде, потому что перейдите сначала на java, c#, c, c++, rust, golang. Верно, что производительность рантаймов компилированных приложений на синтетике может превышать на порядок python/php/ruby. Разберем, однако, что получается в реальности.
Во-первых почти везде уже JIT, или есть или будет, неважно насколько крутой, вода камень точит, поэтому разница на реальном приложении будет уже не порядок просто уже из-за этого. Вон v8 и nodejs так вообще сделал javascript внезапно супер-производительным языком (речь только про производительность, не про экосистему, удобство и тд).
Во-вторых, в современной инфре не-CPU-bound часть кластера (не сервера приложений с вашим кодом) - это грубо примерно 80% костов (в ML-задачах и того выше - спасибо за комментарий АК). То есть большинство оптимизаций всегда приходится на оптимизацию архитектуры и вспомогательных готовых кубиков - СУБД, кешей, очередей. Если вдруг так сошлись звезды и есть два проекта, один на C# другой на PHP и производительность кода вдруг отличается в три раза - это не значит, что инфра для второго будет стоить в 3 раза больше, первый будет “весить” 0.8xCost + 0.2xCost, второй 0.8xCost + 0.6xCost и в результате дельта будет 40%, а не 200%.
Использование же пары языков (второй на наиболее критичные сервисы/модули) или решений типа redis/tarantool, позволяющее в том числе писать достаточно производительные сервисы - и вовсе нивелируют эту разницу.
Это очень грубые прикидки для иллюстрации, пропорции могут быть чуть другими. Посчитайте, поспрашивайте или просто поверьте людям с опытом работы с $-миллиоными костами.
По мотивам споров в комментариях к уютному. Есть ещё два распространенных “мифа” хайлоада.
Первый: коммерческие СУБД значительно превосходят производительность “свободных”. Это очень давно, мягко говоря, не совсем так. Да, есть миллион кейсов, и жаль, нет простого способа это проверить. Может быть, не всегда удобно. С косяками на enterprise-масштабах (сервера по ляму грина за 2-4 юнитовый бокс). С недостаточными гарантиями (спасибо АГ за комментарий). Но если говорить про производительность, то на большинстве OLTP-задач свободные СУБД работают так же производительно, как коммерческие. Если кого-то есть стенды типа моих (Xeon Gold 24/48C, 128G, NVMe) и вы готовы честно “погонять” тесты для современных версии MSSQL/Oracle - напишите, у нас может получиться интересный коллаб.
Второй: те, кто пишут на питоне (любом другом некомпилируемом языке) вообще смешно когда рассуждают о хайлоаде, потому что перейдите сначала на java, c#, c, c++, rust, golang. Верно, что производительность рантаймов компилированных приложений на синтетике может превышать на порядок python/php/ruby. Разберем, однако, что получается в реальности.
Во-первых почти везде уже JIT, или есть или будет, неважно насколько крутой, вода камень точит, поэтому разница на реальном приложении будет уже не порядок просто уже из-за этого. Вон v8 и nodejs так вообще сделал javascript внезапно супер-производительным языком (речь только про производительность, не про экосистему, удобство и тд).
Во-вторых, в современной инфре не-CPU-bound часть кластера (не сервера приложений с вашим кодом) - это грубо примерно 80% костов (в ML-задачах и того выше - спасибо за комментарий АК). То есть большинство оптимизаций всегда приходится на оптимизацию архитектуры и вспомогательных готовых кубиков - СУБД, кешей, очередей. Если вдруг так сошлись звезды и есть два проекта, один на C# другой на PHP и производительность кода вдруг отличается в три раза - это не значит, что инфра для второго будет стоить в 3 раза больше, первый будет “весить” 0.8xCost + 0.2xCost, второй 0.8xCost + 0.6xCost и в результате дельта будет 40%, а не 200%.
Использование же пары языков (второй на наиболее критичные сервисы/модули) или решений типа redis/tarantool, позволяющее в том числе писать достаточно производительные сервисы - и вовсе нивелируют эту разницу.
Это очень грубые прикидки для иллюстрации, пропорции могут быть чуть другими. Посчитайте, поспрашивайте или просто поверьте людям с опытом работы с $-миллиоными костами.
2,617
subscribers
17
photos
2
videos
