Ребят, осталось 4 места 2 места на наше мероприятие, “Интенсив по очередям: Кафка и NATS” с Владимиром Перепелицей.
Это уникальный курс от крутого эксперта, с живыми сессиями и практикой, на котором группа изучит:
* принципы и архитектурные паттерны брокеров, алгоритмы, гарантии, топологии и масштабирование, observability
* очередь как гарант консистентности между микросервисами: проблемы и решения, transactional outbox, deduplication key; реализация сценария оплаты
* погружение в брокер Kafka: архитектура, kafka streams, построение отказоустойчивого кластера и разбор настроек
* погружение в брокер NATS: архитектура, pub/sub и стриминг, кластер, супер-кластер, федерация, edge; запуск и настройка суперкластера
Владимир работал больше 10 лет в VK, занимался Тарантулом, стоил облако VK (S3 в VK Cloud), а сейчас работает Solution Architect в Exness.
Старт 13-го ноября, 5 недель по 1 встрече в неделю по средам, 18:00 MSK (1.5 часа). Больше подробностей и запись на сайте devhands.ru.
В год мы проводим всего несколько подобных мероприятий, так что это уникальная возможность поучиться и получить любую консультацию по брокерам.
Это уникальный курс от крутого эксперта, с живыми сессиями и практикой, на котором группа изучит:
* принципы и архитектурные паттерны брокеров, алгоритмы, гарантии, топологии и масштабирование, observability
* очередь как гарант консистентности между микросервисами: проблемы и решения, transactional outbox, deduplication key; реализация сценария оплаты
* погружение в брокер Kafka: архитектура, kafka streams, построение отказоустойчивого кластера и разбор настроек
* погружение в брокер NATS: архитектура, pub/sub и стриминг, кластер, супер-кластер, федерация, edge; запуск и настройка суперкластера
Владимир работал больше 10 лет в VK, занимался Тарантулом, стоил облако VK (S3 в VK Cloud), а сейчас работает Solution Architect в Exness.
Старт 13-го ноября, 5 недель по 1 встрече в неделю по средам, 18:00 MSK (1.5 часа). Больше подробностей и запись на сайте devhands.ru.
В год мы проводим всего несколько подобных мероприятий, так что это уникальная возможность поучиться и получить любую консультацию по брокерам.
Highload++ Ноябрь-2024
До московского хайлоада остается месяц. Я там буду, и в этом году плотное расписание.
Во-первых, у меня там будет доклад “Можем ли мы с базой, но без кэш-слоя в 2024 году?”, на котором я представлю результаты последних нескольких месяцев исследований Redis, Valkey, Memcached, MySQL и PostgreSQL. Этот рисерч можно было бы назвать 1 Million RPS challenge. Я был уверен, что СУБД покажут плохой результат, и ответ на вопрос будет “конечно, не можем”, но реальность оказалась чуть иной (можем, но вот с такими-то ограничениями). Постгрес удивил (см аттач; график шумный, перемеряем - это без баунсера, без одиссея, high-concurrency нагрузка, сотни тысяч RPS). Подробнее расскажу на конференции.
Во-вторых, у нас (программный комитет) будет новая активность, которую я “задрайвлю” в этом году, нетворкинг-зона. Нам выделят зал на полдня, и мы там сделали 2 слота, по AI и СУБД. На слот с AI придет команда Raft и Женя Россинский ivi.ru, а на слот по СУБД я надеюсь придут ребята из Pоstgres Pro, YDB и Yandex Cloud, Picodata (пока со всеми договариваюсь, кто сможет по времени). Надеюсь, получится интересно.
В-третих, в этом году в Сколково будет комната Devhands.io со своим расписанием! Там можно будет поймать меня и наших экспертов. Мы запланировали несколько мини-сессий, я пока не вижу их в общем расписании, поэтому опубликую тут. Расписание предварительное, но лучше у меня чекнуть в ТГ, если планируете прийти и поговорить (расписание в следующем посте).
До встречи на хайлоаде!
P.S. За утро продали уже 3 из 4х оставшихся мест на интенсив по очередям Володи Перепелицы, так что если планируете записаться - поторопитесь, пару экстра-мест добавим, но всё равно похоже, сегодня всё закроем, за 2 недели до старта (программа и запись здесь). А в ближайшее время анонсируем ещё один супер-курс “PHP performance” (будет вести Михаил Курмаев aka demiurg).
До московского хайлоада остается месяц. Я там буду, и в этом году плотное расписание.
Во-первых, у меня там будет доклад “Можем ли мы с базой, но без кэш-слоя в 2024 году?”, на котором я представлю результаты последних нескольких месяцев исследований Redis, Valkey, Memcached, MySQL и PostgreSQL. Этот рисерч можно было бы назвать 1 Million RPS challenge. Я был уверен, что СУБД покажут плохой результат, и ответ на вопрос будет “конечно, не можем”, но реальность оказалась чуть иной (можем, но вот с такими-то ограничениями). Постгрес удивил (см аттач; график шумный, перемеряем - это без баунсера, без одиссея, high-concurrency нагрузка, сотни тысяч RPS). Подробнее расскажу на конференции.
Во-вторых, у нас (программный комитет) будет новая активность, которую я “задрайвлю” в этом году, нетворкинг-зона. Нам выделят зал на полдня, и мы там сделали 2 слота, по AI и СУБД. На слот с AI придет команда Raft и Женя Россинский ivi.ru, а на слот по СУБД я надеюсь придут ребята из Pоstgres Pro, YDB и Yandex Cloud, Picodata (пока со всеми договариваюсь, кто сможет по времени). Надеюсь, получится интересно.
В-третих, в этом году в Сколково будет комната Devhands.io со своим расписанием! Там можно будет поймать меня и наших экспертов. Мы запланировали несколько мини-сессий, я пока не вижу их в общем расписании, поэтому опубликую тут. Расписание предварительное, но лучше у меня чекнуть в ТГ, если планируете прийти и поговорить (расписание в следующем посте).
До встречи на хайлоаде!
P.S. За утро продали уже 3 из 4х оставшихся мест на интенсив по очередям Володи Перепелицы, так что если планируете записаться - поторопитесь, пару экстра-мест добавим, но всё равно похоже, сегодня всё закроем, за 2 недели до старта (программа и запись здесь). А в ближайшее время анонсируем ещё один супер-курс “PHP performance” (будет вести Михаил Курмаев aka demiurg).
Расписание комнаты Devhands.io на московском хайлоаде
2 декабря 2024
12:30 - Кто сможет в 1M RPS? В забеге участвуют: Valkey, Redis, Memcached, PostgreSQL, MySQL 😉
17:30 - Корпоративное обучение в области высоких нагрузок: подход devhands
18:30 - wrk2/wrkx: особенности использования, coordinated omission и способы компенсации, выжимаем 100K+ RPS из nginx/envoy
3 декабря 2024
12:00 - Корпоративное обучение в области высоких нагрузок: подход devhands
15:30 - Карта роста бэкендера. Что нужно учить, чтобы прокачаться в хайлоаде. Особенности системного дизайна в высоко-нагруженных проектах
16:30 - Рапределённые без “зауми”. CAP-теорема и PACELC-классификация простыми словами, их влияние на развитие разработки больших нагруженных проектов.
18:00 - Valkey vs Redis: что такое Valkey, как его использовать, демонстрация производительности
18:30 - Демонстрация Redis/Valkey Cluster: принципы организации данных в кластере, масштабируемость, отказоусточивость
2 декабря 2024
12:30 - Кто сможет в 1M RPS? В забеге участвуют: Valkey, Redis, Memcached, PostgreSQL, MySQL 😉
17:30 - Корпоративное обучение в области высоких нагрузок: подход devhands
18:30 - wrk2/wrkx: особенности использования, coordinated omission и способы компенсации, выжимаем 100K+ RPS из nginx/envoy
3 декабря 2024
12:00 - Корпоративное обучение в области высоких нагрузок: подход devhands
15:30 - Карта роста бэкендера. Что нужно учить, чтобы прокачаться в хайлоаде. Особенности системного дизайна в высоко-нагруженных проектах
16:30 - Рапределённые без “зауми”. CAP-теорема и PACELC-классификация простыми словами, их влияние на развитие разработки больших нагруженных проектов.
18:00 - Valkey vs Redis: что такое Valkey, как его использовать, демонстрация производительности
18:30 - Демонстрация Redis/Valkey Cluster: принципы организации данных в кластере, масштабируемость, отказоусточивость
Что общего между гибридной инфрой и гибридным графиком работы?
Один человек написал, что, мол, гибридная инфра словно гибридный график работы: не решает ни одной конкретной проблемы, но излишне усложняет ситуацию.
Что я про это думаю? Страх, вот нужное слово. Мы рабы своего страха. Слышу очень много “страха” в словах и про облака, и про работу в офисе. И гибридное рабочее пространство, и гибридная инфра решают конкретную задачу: сокращение расходов, которые мы готовы нести сами и перекладывать на свои команды, где-то переоценивая риски, где-то не имея должного опыта управления (и это не значит, что я “за” или “против” – по ситуации).
Я был убеждённым противником удаленки в принципе, поменял свое мнение, но постоянно встречаю насколько вопиющие кейсы злоупотребления, поэтому я понимаю этот страх. Я дважды садился писать про удалёнку – и не публиковал, настолько это чувствительная тема.
Что я понял за последние 7 лет, организуя удаленную работу в 4х компаниях. Удалёнка открывает массу возможностей для роста бизнеса, но только если (а) операционная деятельность компании позволяет такой формат в принципе (б) менеджмент начиная с руководства хочет и умеет учиться управлять удаленно. Ультимативно требовать (б) странно, игнорировать (а) глупо.
Один человек написал, что, мол, гибридная инфра словно гибридный график работы: не решает ни одной конкретной проблемы, но излишне усложняет ситуацию.
Что я про это думаю? Страх, вот нужное слово. Мы рабы своего страха. Слышу очень много “страха” в словах и про облака, и про работу в офисе. И гибридное рабочее пространство, и гибридная инфра решают конкретную задачу: сокращение расходов, которые мы готовы нести сами и перекладывать на свои команды, где-то переоценивая риски, где-то не имея должного опыта управления (и это не значит, что я “за” или “против” – по ситуации).
Я был убеждённым противником удаленки в принципе, поменял свое мнение, но постоянно встречаю насколько вопиющие кейсы злоупотребления, поэтому я понимаю этот страх. Я дважды садился писать про удалёнку – и не публиковал, настолько это чувствительная тема.
Что я понял за последние 7 лет, организуя удаленную работу в 4х компаниях. Удалёнка открывает массу возможностей для роста бизнеса, но только если (а) операционная деятельность компании позволяет такой формат в принципе (б) менеджмент начиная с руководства хочет и умеет учиться управлять удаленно. Ультимативно требовать (б) странно, игнорировать (а) глупо.
Мировые зарплаты программистов: о чем молчит статистика
Есть вот такое занятное распределение зарплат программистов по миру (картинка с гитхаба Tomaž Weiss, не ручаюсь за оригинальность).
Методика, цифры и их значение, сравнение стран – можно обсуждать вечно. Хочу рассказать об особенности, которая скрыта в такой статистике.
Представьте себе, вы CTO мирового проекта, который быстро растет. Вы решаете открыть несколько R&D-центров по всему миру и нанимать, нанимать, нанимать. Вы управляете бюджетом, поэтому вам нужно обоснование уровня зарплат. Будет ли правильным основывать цифры на подобной статистике? Не совсем, вот почему.
Давайте возьмём Турцию. Прекрасная страна, много людей (больше, чем в Германии), есть большие неплохие университеты. Смотрим картинку: зарплата около $20.000 в год. Это правда: мы нанимали в Турции, зарплаты в ecommerce проектах типа Trendyol действительно были чуть меньше $2000 евро в месяц. Всё это проверяется черех levels.fyi и Stack Overflow. Можно ли нанять турецких программистов за такие деньги в международный проект? Нет! Почему? Потому что как только человек получает достаточный опыт и начинает сносно говорить на английском, он либо переезжает в Германию, либо его мгновенно “сметает” европейский работодатель на удалёнку. А на какие деньги нанимают на удалёнку? Почти всегда эта зарплата определяется не уровнем доходов в стране-доноре, а уровнем расходов на единицу ФОТ в стране-акцепторе, потому что выгребают всех. То есть надо взять медиану на рынке страны-акцептора, взять от этого грубо 75% и это и будет сумма, за которую в массе работодатель из страны-акцептора будет готов отдавать за работника в стране-доноре.
Самое интересное: в зависимости от пропорций между долей программистов, которые работают на внутреннем продуктовом рынке и на внешние проекты - будет “ехать” эта медиана в сторону “увеличения” зарплат. Думаю, что распределение зарплат имеет два горба: для внутреннего рынка и для внешнего. Учитывайте это при планировании.
Есть вот такое занятное распределение зарплат программистов по миру (картинка с гитхаба Tomaž Weiss, не ручаюсь за оригинальность).
Методика, цифры и их значение, сравнение стран – можно обсуждать вечно. Хочу рассказать об особенности, которая скрыта в такой статистике.
Представьте себе, вы CTO мирового проекта, который быстро растет. Вы решаете открыть несколько R&D-центров по всему миру и нанимать, нанимать, нанимать. Вы управляете бюджетом, поэтому вам нужно обоснование уровня зарплат. Будет ли правильным основывать цифры на подобной статистике? Не совсем, вот почему.
Давайте возьмём Турцию. Прекрасная страна, много людей (больше, чем в Германии), есть большие неплохие университеты. Смотрим картинку: зарплата около $20.000 в год. Это правда: мы нанимали в Турции, зарплаты в ecommerce проектах типа Trendyol действительно были чуть меньше $2000 евро в месяц. Всё это проверяется черех levels.fyi и Stack Overflow. Можно ли нанять турецких программистов за такие деньги в международный проект? Нет! Почему? Потому что как только человек получает достаточный опыт и начинает сносно говорить на английском, он либо переезжает в Германию, либо его мгновенно “сметает” европейский работодатель на удалёнку. А на какие деньги нанимают на удалёнку? Почти всегда эта зарплата определяется не уровнем доходов в стране-доноре, а уровнем расходов на единицу ФОТ в стране-акцепторе, потому что выгребают всех. То есть надо взять медиану на рынке страны-акцептора, взять от этого грубо 75% и это и будет сумма, за которую в массе работодатель из страны-акцептора будет готов отдавать за работника в стране-доноре.
Самое интересное: в зависимости от пропорций между долей программистов, которые работают на внутреннем продуктовом рынке и на внешние проекты - будет “ехать” эта медиана в сторону “увеличения” зарплат. Думаю, что распределение зарплат имеет два горба: для внутреннего рынка и для внешнего. Учитывайте это при планировании.
Про ChatGPT
Недавно я “втащил” в наш “million RPS challenge” Memcached Plugin для MySQL. Его зачем-то Oracle “выпилил” из 8.4, хотя на мой взгляд это просто произведение искусства. Это персистентный мемкеш, плагин запускает memcached-сервис внутри MySQL и “бридж” к InnoDB-таблице. Эта хрень отлично скейлится как по ядрам, так и по числу одновременных соединений, и легко выдаёт миллион+ RPS на чтение. Но пост не об этом.
В течение долгого времени я крайне скептически относился к ChatGPT. В этом году всё поменялось. Всё больше и больше я ему начинаю доверять, и регулярно использовать в повседневной работе. Он не пишет за меня код, но подсказывает в настройках. Расскажу, как он мне помог с мемкеш-плагином.
У мемкеша стандартного есть несколько конфигурационных параметров, которые очень сильно могут повлиять на перфоманс. Во-первых, конечно, это общее количество памяти, которое выделяется под ключи. Затем это количество тредов (мемкеш тоже скейлится по ядрам, как – расскажу чуть позже). В третьих это размер TCP-бэклога (специальной очереди соединений, которые прошли хендшейк в ядре, но сервер им ещё не сделал accept), и наконец это общее количество одновременных соединений, которое может обслужить сервер. Сходу я не нашел, как эти параметры передавать в плагин, и решил использовать ChatGPT.
Сначала я cпросил его достаточно общо, и он “сгалюцинировал”: предложил настройку, которой просто нет (погрепал по сорцам). А затем я его спросил так: “In the source code of the memcached mysql plugin I found an option ’t’ which is used for the number of threads, how to use it?” И от мне дал абсолютно верный ответ с примером, после которого у меня сложился паззл, я наконец, понял, что делается в исходниках и понял, как передавать все эти параметры (их надо передавать единой строкой в одном атрибуте, как если бы мемкеш запускался с консоли - видимо, разработчики плагина не стали морочиться и заюзали оригинальный парсер параметров командной строки).
Короче, считаю, что ChatGPT супер-помощник для изучения любой новой области. Мне уже по многим вопросам значительно удобнее сделать запрос ему, чем в Google. Я использую free plan, но только потому, что пока не упёрся ни в какие лимиты. Иногда он мне пишет, что было слишком много запросов, и он будет делать запросы к модели более низкой версии и качества, но на моих запросах я разницы не замечаю.
Недавно я “втащил” в наш “million RPS challenge” Memcached Plugin для MySQL. Его зачем-то Oracle “выпилил” из 8.4, хотя на мой взгляд это просто произведение искусства. Это персистентный мемкеш, плагин запускает memcached-сервис внутри MySQL и “бридж” к InnoDB-таблице. Эта хрень отлично скейлится как по ядрам, так и по числу одновременных соединений, и легко выдаёт миллион+ RPS на чтение. Но пост не об этом.
В течение долгого времени я крайне скептически относился к ChatGPT. В этом году всё поменялось. Всё больше и больше я ему начинаю доверять, и регулярно использовать в повседневной работе. Он не пишет за меня код, но подсказывает в настройках. Расскажу, как он мне помог с мемкеш-плагином.
У мемкеша стандартного есть несколько конфигурационных параметров, которые очень сильно могут повлиять на перфоманс. Во-первых, конечно, это общее количество памяти, которое выделяется под ключи. Затем это количество тредов (мемкеш тоже скейлится по ядрам, как – расскажу чуть позже). В третьих это размер TCP-бэклога (специальной очереди соединений, которые прошли хендшейк в ядре, но сервер им ещё не сделал accept), и наконец это общее количество одновременных соединений, которое может обслужить сервер. Сходу я не нашел, как эти параметры передавать в плагин, и решил использовать ChatGPT.
Сначала я cпросил его достаточно общо, и он “сгалюцинировал”: предложил настройку, которой просто нет (погрепал по сорцам). А затем я его спросил так: “In the source code of the memcached mysql plugin I found an option ’t’ which is used for the number of threads, how to use it?” И от мне дал абсолютно верный ответ с примером, после которого у меня сложился паззл, я наконец, понял, что делается в исходниках и понял, как передавать все эти параметры (их надо передавать единой строкой в одном атрибуте, как если бы мемкеш запускался с консоли - видимо, разработчики плагина не стали морочиться и заюзали оригинальный парсер параметров командной строки).
Короче, считаю, что ChatGPT супер-помощник для изучения любой новой области. Мне уже по многим вопросам значительно удобнее сделать запрос ему, чем в Google. Я использую free plan, но только потому, что пока не упёрся ни в какие лимиты. Иногда он мне пишет, что было слишком много запросов, и он будет делать запросы к модели более низкой версии и качества, но на моих запросах я разницы не замечаю.
Merge-2024_Rybak_LoadTesting_v5_31oct2024.pdf
3.2 MB
Выступал в пятницу в Сколково на конференции Merge - делюсь слайдами, в аттаче.
Мне нужен был интро по нагрузочному с позиции архитектуры, как грузить нормально, а не по-детски – поэтому я решил совместить приятное с полезным и собрал несколько слайдов об архитектуре стрелялок, почему нужны все три параметра (соединения, треды/воркеры и рейт), про cooordinated omission, про LT-диаграммы, про почему p99, очень конспективно.
А ещё анонсирую вот такую утилиту-хелпер https://github.com/devhands-io/lsmt/: помогает генерить нагрузочные серии и парсить результаты, а скоро ещё будет генерить графики в формате observable plot. Поддерживет прямо сейчас memtier-json и wrk, но будет ещё redis-benchmark и sysbench.
Мне нужен был интро по нагрузочному с позиции архитектуры, как грузить нормально, а не по-детски – поэтому я решил совместить приятное с полезным и собрал несколько слайдов об архитектуре стрелялок, почему нужны все три параметра (соединения, треды/воркеры и рейт), про cooordinated omission, про LT-диаграммы, про почему p99, очень конспективно.
А ещё анонсирую вот такую утилиту-хелпер https://github.com/devhands-io/lsmt/: помогает генерить нагрузочные серии и парсить результаты, а скоро ещё будет генерить графики в формате observable plot. Поддерживет прямо сейчас memtier-json и wrk, но будет ещё redis-benchmark и sysbench.
В России 70+ тысяч стоек в датацентрах, и их не хватает
Не знал этого, интересно:
- Грубо 80% стоек в Москве, примерно по 10% Питер и остальные регионы
- Равновесие спроса и предложения, возможно, к 2026 году
- Растет потребление на стойку (видимо, AI, но может СХД? или тупо растет число ядер на ноду/юнит?)
- Повышенный интерес к мобильным и микро-ЦОДам (“коробочное решение” на несколько стоек, которое можно собрать, привести, установить, перевезти - хз, больше звучит как реклама возможностей интегратора)
Источник: https://trends.rbc.ru/trends/industry/cmrm/670e34e09a7947af33fc833d
Не знал этого, интересно:
- Грубо 80% стоек в Москве, примерно по 10% Питер и остальные регионы
- Равновесие спроса и предложения, возможно, к 2026 году
- Растет потребление на стойку (видимо, AI, но может СХД? или тупо растет число ядер на ноду/юнит?)
- Повышенный интерес к мобильным и микро-ЦОДам (“коробочное решение” на несколько стоек, которое можно собрать, привести, установить, перевезти - хз, больше звучит как реклама возможностей интегратора)
Источник: https://trends.rbc.ru/trends/industry/cmrm/670e34e09a7947af33fc833d
РБК Тренды
Займите стойку: что происходит на рынке дата-центров в России
Мощность дата-центров, которые строятся в России, за несколько лет выросла в два-четыре раза. Рассказываем, как меняется сфера и к чему готовиться компаниям, которым нужны услуги ЦОДов
Ребята, внезапно завтра в 18:15 сделаем вот такой часовой онлайн-стрим
Поскольку мы делаем “образовательное облако”, нас интересуют все популярные эко-системы и хайлоад во всех его “кровавых” проявлениях. Поэтому внимание всем адептам эко-системы PHP.
Тема: PHP performance & observability
Когда: пятница, 22 ноября 2024 года, 18:15 GMT+3/IST/MSK
Где: Zoom-комната + стрим на Youtube
- https://us06web.zoom.us/j/81914182860?pwd=t5ukRE67IJKlk4BH9Wwc62Mencsb9r.1
- https://www.youtube.com/@AlexeyRybak/streams
Кто придет:
- Алексей Гагарин и Павел Бучнев, Spiral Framework developers, Temporal-энтузиасты и известные “фартаны” – они делают ТГ-канал “PHP FartTime” (https://www.tgoop.com/php_fart) и обзоры “В мире PHP” (последний выпуск: https://www.tgoop.com/php_fart/136).
- Михаил Курмаев (развивает data planform в T-Банке), автор и ведущий курса devhands.io “PHP performance” (https://devhands.ru/php-perf).
- Алексей Рыбак, devhands.io. Мы с Михаилом много лет вместе занимались платформой в Badoo/Bumble, где php-fpm (и его, кстати тоже сделали в Badoo - Найт, Вова и Тони) - был главной рабочей лошадкой бекендов (наряду с C, C++ и golang).
Поскольку ребята работают в Spiral, а Михаил сделал курс по производительности PHP, центральной темой я бы хотел сделать следующую: как выбор пхпшного рантайма (PHP-fpm, RoadRunner, Franken, Swoole, Spiral) в целом влияет на перфоманс и какие обзервабилити-артефакты для современных рантаймов нужны.
Но это драфт, во-первых мы решили говорить обо всём вокруг и около общей темы, что будет интересно нам самим, а во-вторых вы можете прислать мне любые вопросы в комментариях или задать их на стриме - и мы их обсудим на встрече.
Поскольку мы делаем “образовательное облако”, нас интересуют все популярные эко-системы и хайлоад во всех его “кровавых” проявлениях. Поэтому внимание всем адептам эко-системы PHP.
Тема: PHP performance & observability
Когда: пятница, 22 ноября 2024 года, 18:15 GMT+3/IST/MSK
Где: Zoom-комната + стрим на Youtube
- https://us06web.zoom.us/j/81914182860?pwd=t5ukRE67IJKlk4BH9Wwc62Mencsb9r.1
- https://www.youtube.com/@AlexeyRybak/streams
Кто придет:
- Алексей Гагарин и Павел Бучнев, Spiral Framework developers, Temporal-энтузиасты и известные “фартаны” – они делают ТГ-канал “PHP FartTime” (https://www.tgoop.com/php_fart) и обзоры “В мире PHP” (последний выпуск: https://www.tgoop.com/php_fart/136).
- Михаил Курмаев (развивает data planform в T-Банке), автор и ведущий курса devhands.io “PHP performance” (https://devhands.ru/php-perf).
- Алексей Рыбак, devhands.io. Мы с Михаилом много лет вместе занимались платформой в Badoo/Bumble, где php-fpm (и его, кстати тоже сделали в Badoo - Найт, Вова и Тони) - был главной рабочей лошадкой бекендов (наряду с C, C++ и golang).
Поскольку ребята работают в Spiral, а Михаил сделал курс по производительности PHP, центральной темой я бы хотел сделать следующую: как выбор пхпшного рантайма (PHP-fpm, RoadRunner, Franken, Swoole, Spiral) в целом влияет на перфоманс и какие обзервабилити-артефакты для современных рантаймов нужны.
Но это драфт, во-первых мы решили говорить обо всём вокруг и около общей темы, что будет интересно нам самим, а во-вторых вы можете прислать мне любые вопросы в комментариях или задать их на стриме - и мы их обсудим на встрече.
Screenshot 2024-11-22 at 13.25.52.png
451.6 KB
Ошибки измерений
Рабочие будни исследований. Смотрите, вот график числа reads в секунду, которые выполняет 2 сетапа
* ванильный Memcached 1.6.32 (самый новый)
* Memcached Plugin поверх MySQL 8.0.39
По оси Y тысячи RPS, то есть это всё числа порядка миллиона запросов в секунду. 6.4 млн ключей, всё в памяти, xeon gold с 48 cpu при включенном гипертрединге и 128 гигами памяти.
Всё бы ничего, но график ошибочный. То, что мы видим на графике - это не столько как скейлится KV-база при количестве соединений, но и как скейлится сама стрелялка (это отдельный сервер, но стреляем локально, чтобы не тестировать сеть и инфру провайдера).
Стрелять одновременно и в мемкеш, и в редис стандартный redis-benchmark не умеет, поэтому я взял прежнюю “редисовскую” стрелялку, memtier-benchmark. И к сожалению, по аналогии с sysbench увеличивал число тредов стрелялки, а не число соединений на тред (такой функционал memtier поддерживает).
Придётся перемерять, и результат скорее всего будет лучше (меньшее снижение реальных RPS при росте числа соединений). Но всё равно отличный результат у мемкеш-плагина виден даже по этому графику.
Очень жаль, что Оракл его выпилил в 8.4, надеюсь, он там появится снова - у самого Оракла, или у форков. А про первый российский форк MySQL ещё напишу - там обещали Memcached-плагин сохранить ;)
Рабочие будни исследований. Смотрите, вот график числа reads в секунду, которые выполняет 2 сетапа
* ванильный Memcached 1.6.32 (самый новый)
* Memcached Plugin поверх MySQL 8.0.39
По оси Y тысячи RPS, то есть это всё числа порядка миллиона запросов в секунду. 6.4 млн ключей, всё в памяти, xeon gold с 48 cpu при включенном гипертрединге и 128 гигами памяти.
Всё бы ничего, но график ошибочный. То, что мы видим на графике - это не столько как скейлится KV-база при количестве соединений, но и как скейлится сама стрелялка (это отдельный сервер, но стреляем локально, чтобы не тестировать сеть и инфру провайдера).
Стрелять одновременно и в мемкеш, и в редис стандартный redis-benchmark не умеет, поэтому я взял прежнюю “редисовскую” стрелялку, memtier-benchmark. И к сожалению, по аналогии с sysbench увеличивал число тредов стрелялки, а не число соединений на тред (такой функционал memtier поддерживает).
Придётся перемерять, и результат скорее всего будет лучше (меньшее снижение реальных RPS при росте числа соединений). Но всё равно отличный результат у мемкеш-плагина виден даже по этому графику.
Очень жаль, что Оракл его выпилил в 8.4, надеюсь, он там появится снова - у самого Оракла, или у форков. А про первый российский форк MySQL ещё напишу - там обещали Memcached-плагин сохранить ;)
PHP performance & observability
Привет!
Стартуем стрим, приходите
Zoom: https://us06web.zoom.us/j/81914182860?pwd=t5ukRE67IJKlk4BH9Wwc62Mencsb9r.1
YouTube: https://www.youtube.com/@AlexeyRybak/streams
Кто пришел:
- Алексей Гагарин и Павел Бучнев, Spiral Framework developers, Temporal-энтузиасты и известные “фартаны” – они делают ТГ-канал “PHP FartTime” (https://www.tgoop.com/php_fart) и обзоры “В мире PHP” (последний выпуск: https://www.tgoop.com/php_fart/136).
- Михаил Курмаев (развивает data planform в T-Банке), автор и ведущий курса devhands.io “PHP performance” (https://devhands.ru/php-perf).
- Алексей Рыбак, devhands.io. Мы с Михаилом много лет вместе занимались платформой в Badoo/Bumble, где php-fpm (и его, кстати тоже сделали в Badoo - Найт, Вова и Тони) - был главной рабочей лошадкой бекендов (наряду с C, C++ и golang).
Привет!
Стартуем стрим, приходите
Zoom: https://us06web.zoom.us/j/81914182860?pwd=t5ukRE67IJKlk4BH9Wwc62Mencsb9r.1
YouTube: https://www.youtube.com/@AlexeyRybak/streams
Кто пришел:
- Алексей Гагарин и Павел Бучнев, Spiral Framework developers, Temporal-энтузиасты и известные “фартаны” – они делают ТГ-канал “PHP FartTime” (https://www.tgoop.com/php_fart) и обзоры “В мире PHP” (последний выпуск: https://www.tgoop.com/php_fart/136).
- Михаил Курмаев (развивает data planform в T-Банке), автор и ведущий курса devhands.io “PHP performance” (https://devhands.ru/php-perf).
- Алексей Рыбак, devhands.io. Мы с Михаилом много лет вместе занимались платформой в Badoo/Bumble, где php-fpm (и его, кстати тоже сделали в Badoo - Найт, Вова и Тони) - был главной рабочей лошадкой бекендов (наряду с C, C++ и golang).
Highload 2024 в Сколково. Выход MyDB из сумрака
Завтра в 11:00 в конгресс-холле мой доклад, “Можем ли мы с базой, но без кэш-слоя в 2024 году?”. Он про то, как современные “классические” базы ликвидируют “гэп” с KV/NewSQL и кто сейчас может эффективно отдать миллион PRS на кэш-нагрузке, c какими ограничениями. В исследовании участвовали Redis, Valkey, Memcached, PostgreSQL, MySQL/MyDB. Будет много performance-диаграмм и два сюрприза.
Первый сюрприз не то чтобы полный сюрприз – про Valkey уже многие слышали. Мы начали тестировать ещё пока этот самый многообещающий клон Redis был в RC-стадии. Расскажем, действительно ли он лучше, и в какой мере оправился от родовых травм Redis.
А вот второй сюрприз - сюрприз полный. По MyDB вы скорее всего слышите в первый раз. Это - первый в истории российский клон MySQL, в реестре, с саппортом, всё как положено. Фаундер этого проекта, Лёша Копытов, внёс неоценимый вклад в наши исследования. Он будет на Хайлоаде, и в нетворк-зоне, и в нашем девруме у кластера Индия (ищите название devhands.io) – можно будет обо всём расспросить его лично.
Кто будет на конференции – приходите знакомиться. Кластер Индия, комната 1.5, рядом с Пикодатой. Кто не будет – кажется, VK организует прямую трансляцию из основного зала.
P.S. Никаких образом не связан с запуском проекта MyDB, но знаю ребят как супер-профи, и надеюсь на разнообразное сотрудничество, в частности мы планируем совместный образовательно-практический воркшоп.
Завтра в 11:00 в конгресс-холле мой доклад, “Можем ли мы с базой, но без кэш-слоя в 2024 году?”. Он про то, как современные “классические” базы ликвидируют “гэп” с KV/NewSQL и кто сейчас может эффективно отдать миллион PRS на кэш-нагрузке, c какими ограничениями. В исследовании участвовали Redis, Valkey, Memcached, PostgreSQL, MySQL/MyDB. Будет много performance-диаграмм и два сюрприза.
Первый сюрприз не то чтобы полный сюрприз – про Valkey уже многие слышали. Мы начали тестировать ещё пока этот самый многообещающий клон Redis был в RC-стадии. Расскажем, действительно ли он лучше, и в какой мере оправился от родовых травм Redis.
А вот второй сюрприз - сюрприз полный. По MyDB вы скорее всего слышите в первый раз. Это - первый в истории российский клон MySQL, в реестре, с саппортом, всё как положено. Фаундер этого проекта, Лёша Копытов, внёс неоценимый вклад в наши исследования. Он будет на Хайлоаде, и в нетворк-зоне, и в нашем девруме у кластера Индия (ищите название devhands.io) – можно будет обо всём расспросить его лично.
Кто будет на конференции – приходите знакомиться. Кластер Индия, комната 1.5, рядом с Пикодатой. Кто не будет – кажется, VK организует прямую трансляцию из основного зала.
P.S. Никаких образом не связан с запуском проекта MyDB, но знаю ребят как супер-профи, и надеюсь на разнообразное сотрудничество, в частности мы планируем совместный образовательно-практический воркшоп.
Кейс использования K6 в Picodata
Внутри эко-системы Grafana Labs есть инструмент для нагрузочного тестирования k6. Он немного странный (прожорливость, автоматизация на ява-скрипте, паралеллизация не по тредам/соединениям, а по параллельным пользовательским сессиям whatever it means). Но он становится всё более популярным, и выглядит мощно в плане кастомизаций. Кейс про то, как Picodata прикрутили k6 к тестированию своей СУБД.
Лонг-рид: https://habr.com/ru/companies/arenadata/articles/864974/
Ниже - краткое саммари (кстати, как вам промт?)
Кому будет интересна статья
* Гошникам
* Разработчикам распределённых систем и баз данных.
* Инженерам по нагрузочному тестированию.
* Специалистам, занимающимся построением инфраструктуры тестирования производительности.
Статья посвящена подходу компании Picodata к нагрузочному тестированию распределённых баз данных (NewSQL СУБД). Рассматриваются проблемы, с которыми сталкиваются разработчики таких систем, и выбор инструментов для создания практики тестирования производительности. Основное внимание уделяется созданию собственного решения — системы Picostress, основанной на инструментарии k6.
Используемые продукты и решения
* Picostress - разработанный инструмент для нагрузочного тестирования.
* Go - язык программирования, на котором написан весь код Picostress, а также k6
* k6 - утилита для создания нагрузочных тестов, поддерживающая выполнение скриптов на JavaScript.
* xk6-модуль: расширение для k6, реализованное для взаимодействия с Picodata через её нативные протоколы (iproto и pgproto).
* Cobra - Go-библиотека для создания CLI-приложений, использованная для создания обёртки вокруг k6.
Основные выводы
* Среди множества утилит для нагрузочного тестирования именно k6 оказался наиболее подходящим благодаря гибкости, расширяемости и поддержке пользовательских сценариев.
* Наиболее интересные особенности k6: интеграции в CI/CD процессы, создание сложных сценариев тестирования на JavaScript, поддержка постоянной нагрузки (constant throughput load) с учётом проблемы coordinated omission.
* Разработка собственного модуля: В Picodata был создан xk6-модуль для взаимодействия с нативными протоколами системы, что позволило реализовать нагрузочное тестирование, учитывающее специфику распределённых систем.
* Автоматизация и адаптивность: Picostress, основанный на k6, стал не только инструментом тестирования, но и ключевым элементом мониторинга и оптимизации производительности для каждого релиза продукта.
Внутри эко-системы Grafana Labs есть инструмент для нагрузочного тестирования k6. Он немного странный (прожорливость, автоматизация на ява-скрипте, паралеллизация не по тредам/соединениям, а по параллельным пользовательским сессиям whatever it means). Но он становится всё более популярным, и выглядит мощно в плане кастомизаций. Кейс про то, как Picodata прикрутили k6 к тестированию своей СУБД.
Лонг-рид: https://habr.com/ru/companies/arenadata/articles/864974/
Ниже - краткое саммари (кстати, как вам промт?)
Кому будет интересна статья
* Гошникам
* Разработчикам распределённых систем и баз данных.
* Инженерам по нагрузочному тестированию.
* Специалистам, занимающимся построением инфраструктуры тестирования производительности.
Статья посвящена подходу компании Picodata к нагрузочному тестированию распределённых баз данных (NewSQL СУБД). Рассматриваются проблемы, с которыми сталкиваются разработчики таких систем, и выбор инструментов для создания практики тестирования производительности. Основное внимание уделяется созданию собственного решения — системы Picostress, основанной на инструментарии k6.
Используемые продукты и решения
* Picostress - разработанный инструмент для нагрузочного тестирования.
* Go - язык программирования, на котором написан весь код Picostress, а также k6
* k6 - утилита для создания нагрузочных тестов, поддерживающая выполнение скриптов на JavaScript.
* xk6-модуль: расширение для k6, реализованное для взаимодействия с Picodata через её нативные протоколы (iproto и pgproto).
* Cobra - Go-библиотека для создания CLI-приложений, использованная для создания обёртки вокруг k6.
Основные выводы
* Среди множества утилит для нагрузочного тестирования именно k6 оказался наиболее подходящим благодаря гибкости, расширяемости и поддержке пользовательских сценариев.
* Наиболее интересные особенности k6: интеграции в CI/CD процессы, создание сложных сценариев тестирования на JavaScript, поддержка постоянной нагрузки (constant throughput load) с учётом проблемы coordinated omission.
* Разработка собственного модуля: В Picodata был создан xk6-модуль для взаимодействия с нативными протоколами системы, что позволило реализовать нагрузочное тестирование, учитывающее специфику распределённых систем.
* Автоматизация и адаптивность: Picostress, основанный на k6, стал не только инструментом тестирования, но и ключевым элементом мониторинга и оптимизации производительности для каждого релиза продукта.
Хабр
Picostress — наш подход к нагрузочному тестированию
Привет, меня зовут Георгий Ломакин, и я инженер по нагрузочному тестированию в компании Picodata — разработчике одноимённой NewSQL СУБД. В этой статье я поделюсь своим опытом нагрузочного тестирования...
Antirez (Salvatore Sanfilippo) возвращается в Redis
https://antirez.com/news/144
Перспективы Redis после релиза Valkey были туманны
- все или почти все фичи Redis есть в Valkey
- Valkey ударил в больное место и показал очень хорошие результаты (см. например наши исследования в devhands)
- отток клиентов или случился или случится в ближайший год, Valkey маниакально следит за полной совместимостью, минимизируя усилия для перпехода не только девелоперам, но и инженерам инфры: апи тот же, для всех бинарей есть симлинки со старыми названиями
- многие чуваки перешли под крыло новой команды, особенно нет смысла продолжать сотрудничать с Redis облачным компаниям, а многие обновления шли от них, Valkey не писал ничего про участи Яндекса, но в кулуарах Хайлоада ребята из Яндекс.Облака мне подтвердили, что и они раньше патчили Redis, а теперь Valkey
Что может дать возвращение Salvatore, и прочие соображения:
- плюсище в карму, но фундаментально без изменения лицензии “перевес” пока на стороне облаков
- в среднесрочной можно собрать или пересобрать команду, выстроить бэкпортирование патчей Valkey, особенно оптимизационные – и если не уравнять, то сбалансировать разрыв в мозгах и руках
- лицензию Redis вероятно не поменяет, особенно после отдельной части поста Salvatore (иронично Петя Зайцев в посте на Линкедин в очередной раз вспоминает про обещание “open source навсегда” - но я согласен с Salvatore, запрет на использование managed без раскрытия обвязок не делает софт “закрытым”)
- фокус на вектора и RAG прикольный, но пока выглядит как частность, KV “берут” не за этим
Короче, похоже, Redis даже не собирается сдаваться и нам предсоить наблюдать интересную конкуренцию двух таланливых команд. Жду включения макретинга DragonFly, пиара вокруг родовых травм Redis/Valkey. Всё это очень интересно наблюдать, конкуренция – почти всегда хорошо.
https://antirez.com/news/144
Перспективы Redis после релиза Valkey были туманны
- все или почти все фичи Redis есть в Valkey
- Valkey ударил в больное место и показал очень хорошие результаты (см. например наши исследования в devhands)
- отток клиентов или случился или случится в ближайший год, Valkey маниакально следит за полной совместимостью, минимизируя усилия для перпехода не только девелоперам, но и инженерам инфры: апи тот же, для всех бинарей есть симлинки со старыми названиями
- многие чуваки перешли под крыло новой команды, особенно нет смысла продолжать сотрудничать с Redis облачным компаниям, а многие обновления шли от них, Valkey не писал ничего про участи Яндекса, но в кулуарах Хайлоада ребята из Яндекс.Облака мне подтвердили, что и они раньше патчили Redis, а теперь Valkey
Что может дать возвращение Salvatore, и прочие соображения:
- плюсище в карму, но фундаментально без изменения лицензии “перевес” пока на стороне облаков
- в среднесрочной можно собрать или пересобрать команду, выстроить бэкпортирование патчей Valkey, особенно оптимизационные – и если не уравнять, то сбалансировать разрыв в мозгах и руках
- лицензию Redis вероятно не поменяет, особенно после отдельной части поста Salvatore (иронично Петя Зайцев в посте на Линкедин в очередной раз вспоминает про обещание “open source навсегда” - но я согласен с Salvatore, запрет на использование managed без раскрытия обвязок не делает софт “закрытым”)
- фокус на вектора и RAG прикольный, но пока выглядит как частность, KV “берут” не за этим
Короче, похоже, Redis даже не собирается сдаваться и нам предсоить наблюдать интересную конкуренцию двух таланливых команд. Жду включения макретинга DragonFly, пиара вокруг родовых травм Redis/Valkey. Всё это очень интересно наблюдать, конкуренция – почти всегда хорошо.
Alexey Rybak HL 2024 v4.pdf
1.2 MB
Презентация с хайлоада MHL-2024
Cовсем забыл выложить презентацию с Highload – в аттаче.
Напомню, мы в devhands.io взяли Redis, Valkey, Memcached, PostgreSQL и MySQL и провели тесты на “железном сервере” в режиме read-only кеш-нагрузки. Результаты меня лично немного удивили, но не буду спойлерить – смотрите графики в презентации.
По докладу были вопросы: почему всего 10 млн ключей, неясна методика тестирования, почему такое неширокое продуктовое покрытие. Это всё справедливые замечания, на них отвечу кратко в следующих постах.
Пока не решил, отдавать ли назад сервер под облачную инфру для практических занятий слушателей школы. Всё-таки я бы хотел расширить линейку и самих тестов, и тестируемых продуктов, и регулярно обновлять результаты.
P.S. Один из слушателей заметил, что по его мнению в кластерном режиме Redis может работать без AOF, я пока не проверил, если это так – нужно будет собрать стенд с кластером без AOF.
Cовсем забыл выложить презентацию с Highload – в аттаче.
Напомню, мы в devhands.io взяли Redis, Valkey, Memcached, PostgreSQL и MySQL и провели тесты на “железном сервере” в режиме read-only кеш-нагрузки. Результаты меня лично немного удивили, но не буду спойлерить – смотрите графики в презентации.
По докладу были вопросы: почему всего 10 млн ключей, неясна методика тестирования, почему такое неширокое продуктовое покрытие. Это всё справедливые замечания, на них отвечу кратко в следующих постах.
Пока не решил, отдавать ли назад сервер под облачную инфру для практических занятий слушателей школы. Всё-таки я бы хотел расширить линейку и самих тестов, и тестируемых продуктов, и регулярно обновлять результаты.
P.S. Один из слушателей заметил, что по его мнению в кластерном режиме Redis может работать без AOF, я пока не проверил, если это так – нужно будет собрать стенд с кластером без AOF.
Миллион, миллион, миллион RPS
Привет всем вернувшимся к работе после праздников! Начинаю публиковать основные выводы, которые я для себя лично сделал после проведения прошлогоднего тестирования (презентация и графики в предыдущем посте).
Вывод номер один: действительно получить сейчас “миллион RPS” с одной “сторадж”-ноды в режиме чтения не составляет большого труда, причем с этим вполне справляются традиционные открытые СУБД. Достигается это исключительно использованием большого количества ядер, в пересчёте на 1 ядро процессора типа Xeon Gold почти все продукты выдают “грубо” 50-150 тысяч RPS.
Этот вывод сам по себе, наверное, имеет мало практического смысла для широкой аудитории, особенно если у вас нет этих миллионов RPS, если вы не маньячите со статистикой и не находитесь в режиме постоянной оптимизации производительности, но вот его следствие - имеет.
А следствие такое: огромное количество проектов, даже вполне себе немаленьких, возможно, “влезет” в несколько серверов, которые даже в режиме аренды суммарно обойдутся меньше зарплаты одного девопса (10 “железных” серверов типа того, что был у нас на тестах, обойдется примерно в 3000 евро в месяц).
Поэтому, ребята, не сбрасывайте со счетов вертикальное масштабирование и не гонитесь исключительно за облачной инфрой. Пусть в вашей инфраструктуре будет место гибриду, это всегда полезно: и сравнить производительность, и критичные сервисы/данные перетащить, и про скидку с облачным провайдером поговорить не абстрактно, а на основе реальных данных. А если нужна помощь в расчетах, в сборе данных, в проведении оптимизации – напишите мне, за спрос денег не берут, а мы любим оптимизировать, вдруг что-то интересное сможем предложить.
Привет всем вернувшимся к работе после праздников! Начинаю публиковать основные выводы, которые я для себя лично сделал после проведения прошлогоднего тестирования (презентация и графики в предыдущем посте).
Вывод номер один: действительно получить сейчас “миллион RPS” с одной “сторадж”-ноды в режиме чтения не составляет большого труда, причем с этим вполне справляются традиционные открытые СУБД. Достигается это исключительно использованием большого количества ядер, в пересчёте на 1 ядро процессора типа Xeon Gold почти все продукты выдают “грубо” 50-150 тысяч RPS.
Этот вывод сам по себе, наверное, имеет мало практического смысла для широкой аудитории, особенно если у вас нет этих миллионов RPS, если вы не маньячите со статистикой и не находитесь в режиме постоянной оптимизации производительности, но вот его следствие - имеет.
А следствие такое: огромное количество проектов, даже вполне себе немаленьких, возможно, “влезет” в несколько серверов, которые даже в режиме аренды суммарно обойдутся меньше зарплаты одного девопса (10 “железных” серверов типа того, что был у нас на тестах, обойдется примерно в 3000 евро в месяц).
Поэтому, ребята, не сбрасывайте со счетов вертикальное масштабирование и не гонитесь исключительно за облачной инфрой. Пусть в вашей инфраструктуре будет место гибриду, это всегда полезно: и сравнить производительность, и критичные сервисы/данные перетащить, и про скидку с облачным провайдером поговорить не абстрактно, а на основе реальных данных. А если нужна помощь в расчетах, в сборе данных, в проведении оптимизации – напишите мне, за спрос денег не берут, а мы любим оптимизировать, вдруг что-то интересное сможем предложить.
Telegram
System Design & Highload (Alexey Rybak)
Презентация с хайлоада MHL-2024
Cовсем забыл выложить презентацию с Highload – в аттаче.
Напомню, мы в devhands.io взяли Redis, Valkey, Memcached, PostgreSQL и MySQL и провели тесты на “железном сервере” в режиме read-only кеш-нагрузки. Результаты меня…
Cовсем забыл выложить презентацию с Highload – в аттаче.
Напомню, мы в devhands.io взяли Redis, Valkey, Memcached, PostgreSQL и MySQL и провели тесты на “железном сервере” в режиме read-only кеш-нагрузки. Результаты меня…
Самый странный мерч в моей жизни и трек по СУБД.
Я хотел написать этот пост в поддержку чего-то очень важного, и кажется такой момент настал. Это пост про мерч с богатой историей - в поддержку нашего нового трека по СУБД (да-да, наконец).
Много лет назад я был в Калифорнии на конференции MySQL. Света Смирнова (за что ей громаднейшее спасибо) где-то раздобыла дико смешной мерч, трусы MySQL, и на моё робкое замечание об их огромном размере сказала что-то типа “бери эти, взяла тебе последние”.
А потом мы попросили художника Николая Копейкина нарисовать картину, которая долго провисела в московском офисе Badoo. Ко мне даже приходили люди и спрашивали, мол, а правда, что у вас в офисе картина Копейкина висит. Правда, только теперь не в офисе - а у нас дома. Кстати, те самые трусы лежат на фото под картиной.
А теперь в честь чего пост. Ребята, у меня к вам огромная просьба: помогите нам понять приоритеты для нашего трека по СУБД. У нас есть 6 программ. Нам нужно понять, в каком порядке их лучше запустить - это определит голосование. Голосование публикую следующим постом. Если вам нравится этот пост или то, что мы делаем - пожалуйста, оставьте ваш голос.
Заранее спасибо!
Я хотел написать этот пост в поддержку чего-то очень важного, и кажется такой момент настал. Это пост про мерч с богатой историей - в поддержку нашего нового трека по СУБД (да-да, наконец).
Много лет назад я был в Калифорнии на конференции MySQL. Света Смирнова (за что ей громаднейшее спасибо) где-то раздобыла дико смешной мерч, трусы MySQL, и на моё робкое замечание об их огромном размере сказала что-то типа “бери эти, взяла тебе последние”.
А потом мы попросили художника Николая Копейкина нарисовать картину, которая долго провисела в московском офисе Badoo. Ко мне даже приходили люди и спрашивали, мол, а правда, что у вас в офисе картина Копейкина висит. Правда, только теперь не в офисе - а у нас дома. Кстати, те самые трусы лежат на фото под картиной.
А теперь в честь чего пост. Ребята, у меня к вам огромная просьба: помогите нам понять приоритеты для нашего трека по СУБД. У нас есть 6 программ. Нам нужно понять, в каком порядке их лучше запустить - это определит голосование. Голосование публикую следующим постом. Если вам нравится этот пост или то, что мы делаем - пожалуйста, оставьте ваш голос.
Заранее спасибо!
Devhands наконец-то запускает трек по базам данных. Какие темы и направления были бы наиболее интересны для вас?
Anonymous Poll
62%
Архитектуры СУБД и современные классы CУБД, их особенности и различия
43%
Redis/Valkey: архитектура, стратегии кеширования, observability, масштабирование и кластеры
65%
PostgreSQL SQL Tuning: архитектура PostgreSQL, типы индексов, анализ планов и оптимизация запросов
10%
MySQL SQL Tuning: архитектура MySQL, типы индексов, анализ планов и оптимизация запросов
7%
MySQL для DevOps: архитектура, настройки, бекап/восстановление, HA и кластерные решения
44%
PostgreSQL для DevOps: архитектура, настройки, бекап/восстановление, HA и кластерные решения
Вывод #2: PostgreSQL “сгладил” родовую травму
Второй вывод, который я сделал: PosgtreSQL к 17й версии (а может, и раньше – не изучал) значительно “смягчил” свою родовую травму, модель process-per-connection в обработке соединений. Я собственными глазами видел, как наша тестовая машинка “жила” с 5000 процессами. И это с 128G памяти, что по нынешним меркам немного, то есть при желании 20-25 тысяч одновременных соединений PostgreSQL может легко вытянуть на достаточно мощном железе просто даже без кеша соединений.
Конечно, другие СУБД справятся с таким количеством соединений на значительно более скромном железе, но поскольку я последовательно выступаю за “разумную” комбинацию горизонтального и вертикального масштабирования – большинство проектов PostgreSQL “потянет” даже без баунсера. С баунсером, кстати, тоже не всё гладко, дополнительное звено и extra-hop, это раз, но поскольку он по-прежнему однопоточный – это может ограничивать пропускную способность на больших нагрузках (надо делать пул баунсеров, уносить баунсеры на бекенд-машины – короче, всё это делается, но заметно увеличивает сложность). Тут интерес представляет мульти-поточный яндексовский одиссей – мы его даже поставили, но банально руки так и не дошли: с пол-пинка он не завелся, а ковырять уже времени не было.
Кстати, большое спасибо всем, кто голосовал за СУБД-направления (ещё можно это сделать). На мой взгляд, такой перевес интереса к PostgreSQL по сравнению c MySQL не соответствует реальному уровню этих СУБД и эко-систем вокруг них. Лично я считаю, что они равнозначны, и я ожидал бы распределения интереса 50% на 50%. Но объективно голосование лишь подтверждает известный факт: в русско-язычных командах PostgreSQL или связка PostgreSQL/Redis является самой популярной.
Для справки:
- презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- вывод #1
Второй вывод, который я сделал: PosgtreSQL к 17й версии (а может, и раньше – не изучал) значительно “смягчил” свою родовую травму, модель process-per-connection в обработке соединений. Я собственными глазами видел, как наша тестовая машинка “жила” с 5000 процессами. И это с 128G памяти, что по нынешним меркам немного, то есть при желании 20-25 тысяч одновременных соединений PostgreSQL может легко вытянуть на достаточно мощном железе просто даже без кеша соединений.
Конечно, другие СУБД справятся с таким количеством соединений на значительно более скромном железе, но поскольку я последовательно выступаю за “разумную” комбинацию горизонтального и вертикального масштабирования – большинство проектов PostgreSQL “потянет” даже без баунсера. С баунсером, кстати, тоже не всё гладко, дополнительное звено и extra-hop, это раз, но поскольку он по-прежнему однопоточный – это может ограничивать пропускную способность на больших нагрузках (надо делать пул баунсеров, уносить баунсеры на бекенд-машины – короче, всё это делается, но заметно увеличивает сложность). Тут интерес представляет мульти-поточный яндексовский одиссей – мы его даже поставили, но банально руки так и не дошли: с пол-пинка он не завелся, а ковырять уже времени не было.
Кстати, большое спасибо всем, кто голосовал за СУБД-направления (ещё можно это сделать). На мой взгляд, такой перевес интереса к PostgreSQL по сравнению c MySQL не соответствует реальному уровню этих СУБД и эко-систем вокруг них. Лично я считаю, что они равнозначны, и я ожидал бы распределения интереса 50% на 50%. Но объективно голосование лишь подтверждает известный факт: в русско-язычных командах PostgreSQL или связка PostgreSQL/Redis является самой популярной.
Для справки:
- презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- вывод #1
Вывод #3: Valkey “сгладил” родовую травму Redis, но Memcached их по-прежнему рвёт в cache-only сценарии
Disclaimer: всё, что дальше понаписано, касается исключительно специфичных кейсов, когда ваша инфра обрабатывает как минимум многие десятки/сотни тысяч запросов к кеш-слою в секунду. Если нет - вам отлично зайдёт Redis.
Третий вывод, который я сделал: Valkey действительно удалось сделать продукт, который в состоянии отдать миллион RPS с одного инстанса, а в целом Valkey отдает примерно в 2.5 раза больше RPS, чем Redis (график в презентации и в первом комментарии). У Евгения Дюкова из Яндекса был на эту тему достаточно подробный доклад на последнем хайлоаде – думаю, что скоро он окажется в свободном доступе.
Проблема (и сила) Redis заключается в простой до невозможности архитектуре. У Redis есть один единственный main thread, который отвечает “за всё”, и есть некоторое количество io-threads, которые отвечают за ввод-вывод. С ростом нагрузки, если вашему Redis можно отдать хотя бы несколько ядер, можно чуть поднять io-threads и таким образом слегка повысить пропускную способность. Это, кстати, не все знают: да, Redis можно немножечко “поскейлить” по ядрам, раза в 2 можно поднять RPS, но этот скейлинг крайне неэффективный, будет заметен рост в дипазоне 1-4 io-тредов, но дальше они начнут затыкаться в борьбе за локи (lock contention).
Что сделали в Valkey: они внесли много исправлений, позволивших “развязать” main-тред и io-треды и заметно повысили параллелизм в Redis. Плюс внесли ряд исправлений, позволивших лучше утилизировать префетч-возможности современных процессоров, что также заметно снижает latency. Короче, Valkey vjkjlws - но родовая травма всё-таки никуда не делась. На наших тестах хорошо видно, что поднимать число io-threads выше 8-10 уже не имеет особенного смысла, сколько бы ядер у вас не было.
В свою очередь Memcached, который конечно по сравнению c Redis/Valkey не умеет почти ничего кроме базовых get/set/del/incr операций, может выдать значительно бОльшую пропускную способность, нежели Valkey. У Memcached есть похожие проблемы с lock contention, но насколько я понимаю, используется другой подход к партиционированию данных, что снижает contention. Если вам нужен только кеш без персистенстности - Memcached по-прежнему отличный вариант.
Для справки
- Собственно презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
Disclaimer: всё, что дальше понаписано, касается исключительно специфичных кейсов, когда ваша инфра обрабатывает как минимум многие десятки/сотни тысяч запросов к кеш-слою в секунду. Если нет - вам отлично зайдёт Redis.
Третий вывод, который я сделал: Valkey действительно удалось сделать продукт, который в состоянии отдать миллион RPS с одного инстанса, а в целом Valkey отдает примерно в 2.5 раза больше RPS, чем Redis (график в презентации и в первом комментарии). У Евгения Дюкова из Яндекса был на эту тему достаточно подробный доклад на последнем хайлоаде – думаю, что скоро он окажется в свободном доступе.
Проблема (и сила) Redis заключается в простой до невозможности архитектуре. У Redis есть один единственный main thread, который отвечает “за всё”, и есть некоторое количество io-threads, которые отвечают за ввод-вывод. С ростом нагрузки, если вашему Redis можно отдать хотя бы несколько ядер, можно чуть поднять io-threads и таким образом слегка повысить пропускную способность. Это, кстати, не все знают: да, Redis можно немножечко “поскейлить” по ядрам, раза в 2 можно поднять RPS, но этот скейлинг крайне неэффективный, будет заметен рост в дипазоне 1-4 io-тредов, но дальше они начнут затыкаться в борьбе за локи (lock contention).
Что сделали в Valkey: они внесли много исправлений, позволивших “развязать” main-тред и io-треды и заметно повысили параллелизм в Redis. Плюс внесли ряд исправлений, позволивших лучше утилизировать префетч-возможности современных процессоров, что также заметно снижает latency. Короче, Valkey vjkjlws - но родовая травма всё-таки никуда не делась. На наших тестах хорошо видно, что поднимать число io-threads выше 8-10 уже не имеет особенного смысла, сколько бы ядер у вас не было.
В свою очередь Memcached, который конечно по сравнению c Redis/Valkey не умеет почти ничего кроме базовых get/set/del/incr операций, может выдать значительно бОльшую пропускную способность, нежели Valkey. У Memcached есть похожие проблемы с lock contention, но насколько я понимаю, используется другой подход к партиционированию данных, что снижает contention. Если вам нужен только кеш без персистенстности - Memcached по-прежнему отличный вариант.
Для справки
- Собственно презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)