Методы получения высокой производительности систем
Привет! Продолжаю разбирать классические задачи с System Design интервью на стримах (за анонсами можете следить тут https://t.me/siliconchannel), а это текстовая версия стрима. В прошлый раз была бесконечная лента, сегодня очередная классика жанра - веб-краулер. Условие звучит примерно так:
Приветствую!
На связи корпоративный архитектор банка Уралсиб - Моне Даниил!
СА говорит ''это срочно для бизнеса'', а КА — ''это не по стратегии''? Узнаете себя? Мы нашли способ, как помирить их в одном домене, не жертвуя ни скоростью, ни качеством
Привет, Хабр!
Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.
Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.
Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.
В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.
В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.
Вы написали struct ради zero-allocation, прошли code review — а в проде Gen0-коллекции всё равно идут косяком. Самая дорогая аллокация та, которой нет в исходниках: компилятор молча упаковывает ваш value-тип в кучу там, где вы этого не просили.
Разбираю, где скрытый боксинг живёт и на .NET 10 (интерфейс на struct, foreach по IEnumerable, ValueType.Equals, params object[], замыкания), а где рантайм его уже вырезал — и почему слепо чинить HasFlag по гайдам 2015 года вредно. Два прод-кейса, шпаргалка-таблица, бенчмарк на BenchmarkDotNet и охота на box через DOTNET_JitDisasm и dotnet-gcdump.
При большом масштабе компании требования к стабильности и скорости разработки становятся критичными. Долгое время бэкенд платформы Flowwow оставался монолитным, и в какой-то момент это начало серьезно тормозить развитие продукта. В этой статье я расскажу, как мы пришли к модернизации, как поменяли архитектуру и что получилось в итоге.
Чтение сериализованных данных — это инфраструктурный налог, который платит каждый сервис при получении информации из внешних источников, например по сети или с диска. В индустрии для схематизированных данных стандартом де‑факто стал Protobuf, и чаще всего этот налог выражается в существенных затратах CPU на его парсинг. В продвинутых случаях парсинг пытаются заменить на значительно более дешёвую, но при этом куда менее удобную работу с zero‑copy представлением FlatBuffers.
Мы открыли исходники YaFF (Yet Another Flat Format) — формата, который убирает этот налог, не заставляя отказываться от Protobuf. На масштабе Яндекса это особенно важно, потому что менять такие базовые вещи, как формат, дорого и больно. Поэтому YaFF изначально спроектирован как альтернативный wire format для существующих экосистем Protobuf (и в перспективе FlatBuffers). Это позволяет дёшево и бесшовно встраиваться в существующие проекты, не переписывая десятки тысяч строк кода.
Как это работает на практике, мы покажем на примере Яндекс Рекламы: в рекомендательной системе, где каждый из сотен тысяч запросов обрабатывает десятки тысяч объектов, нужно особое внимание к представлению данных. Благодаря YaFF мы смогли постепенно, шаг за шагом, оптимизировать систему и без дорогих рефакторингов сэкономить 10–20% CPU в масштабах крупных рантаймов.
В каждом бэкенде рано или поздно рядом появляются id, UUID, slug, token и request_id. Все они выглядят как строки, но отвечают за разные вещи.
Когда это забывают, UUID становится защитой, slug — вечной айдишкой, а token — просто ещё одним идентификатором.
Каждый раз, когда в компании возникают проблемы с производительностью PostgreSQL, обсуждение обычно идет по одному и тому же сценарию.
Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.
Недавно мы в Tarantool столкнулись именно с такой ситуацией у одного из клиентов. В этой статье расскажем подробно об этой ситуации, поделимся, как мы ее решили и почему такой подход в целом стоит использовать практически всем, кто имеет дело с PostgreSQL.
О четвёртой промышленной революции говорили так долго, что к разговорам успели привыкнуть. А она тем временем уже разворачивается прямо в редакторах кода. Все прошлые промышленные революции ускоряли физический труд. Эта впервые взялась за труд когнитивный: за проектирование, написание кода, ревью, отладку, за всё, чем инженер занят каждый день. Куда это приведёт, честно не знает пока никто. Понятно при этом одно: разбираться придётся всем, и разбираться всерьёз. Под этот сдвиг команда Saint HighLoad++ пересобрала всю программу. И вместе с этим появилась новая логика, по которой всё устроено.
«Контейнер для DI — это лишний оверхед, передай зависимость руками и не выдумывай». Я тоже так считал, пока не замерил: наивный контейнер резолвил типичный сервис-граф примерно в 200 раз медленнее ручной сборки.
Рассказываю, как тремя шагами — кэш плана, удаление проверки, которая всё равно не срабатывает, и компиляция графа в одну плоскую функцию — довёл резолв с 52.9 до 0.40 мкс/оп, почти как руками. И как при этом не дал exec-кодогенерации тихо собирать не те объекты в проде.
Приёмы переносимые: профилирование микрооверхеда, выкидывание мёртвой защиты, фаззинг на эквивалентность.
Привет, Хабр.
Сегодня я постараюсь максимально понятным языком объяснить Hazard pointers, с схемой и примерами.
Новая статья из цикла про нашу OLTP-СУБД на Rust.
С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.
Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.
В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.
Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.
В задаче проектирования Rate Limiter важны сразу несколько вещей: выбор алгоритма лимитирования, централизованное хранение состояния, работа через API Gateway и масштабирование до 1 млн запросов в секунду. В статье разберём, почему для такого сценария часто выбирают Token Bucket, как использовать Redis для хранения счётчиков и что делать, когда одного инстанса уже недостаточно.
Привет, Хабр! Меня зовут Андрей Серебрянский. Раньше я строил платформы потоковой обработки данных в банках, а теперь вместе с командой разрабатываю YDB Topics и YMQ. После своих докладов на конференциях мы с коллегами по индустрии часто обсуждаем брокеры сообщений. И меня, как разработчика таких решений, огорчает упрощённый подход: «RabbitMQ не нужен, всё можно собрать на Kafka».
Вспоминая известную шутку: да, с помощью буханки бородинского и двух спиц можно собрать модель троллейбуса. Но зачем? Да, я люблю Kafka и с удовольствием про неё рассказываю на Хабре и Хайлоаде. Но, кроме Kafka и RabbitMQ, есть и третий класс брокеров сообщений: SQS-совместимые очереди в облачных платформах (и не только), которые для многих продакшн-задач подходят лучше, чем Kafka.
Опытные разработчики, проводя system design interview, любят спрашивать друг друга о разнице между брокерами сообщений. А мне каждый раз хочется ответить: «Зависит от контекста». В статье под катом я начну с такого контекста: напомню, для чего изначально создавались SQS, RabbitMQ, Kafka. После этого расскажу про принцип «простой API, умный сервер» и про задачи, которые в эпоху микросервисов решаются с помощью брокеров. А в завершение — про реализацию SQS, над которой сейчас работаю: Yandex Message Queue.
Когда у приложения появляется несколько хостов PostgreSQL, начинается головная боль: нужно динамически находить мастера после failover, выбирать реплику с нужным отставанием и гарантировать что пользователь не увидит устаревшие данные после своей же записи. DNS кешируется минутами, libpq не знает про lag, HAProxy не слышал про LSN. Разбираем как устроены существующие решения и как закрыть все три задачи через лёгкий HTTP сервис — pg-status.
# Как мы четыре раза неправильно диагностировали зависание на джобе 281 339
Несколько месяцев назад я писал, [как мы четыре раза неправильно чинили мерцание](https://habr.com/ru/articles/1042962/) при рендеринге 4,4 миллиона полигонов. Тогда казалось, что это рекорд: месяц блужданий, четыре отброшенных подхода, решение на неделю. Эта история хуже. Баг пережил четыре диагноза подряд, два из которых мы успели «подтвердить числами», получил по дороге три работающих фикса от несуществующих причин - и в итоге оказался файлом, который лежал на рабочем столе.
Напомню контекст: мы небольшой командой пишем на Rust + Vulkan редактор топологий интегральных схем + верификатор (DRC/LVS/Antenna/PEX) с прицелом на российский рынок. Команда - три человека, я в роли CTO направляю архитектуру и принимаю основные решения. В том числе неверные, о которых ниже. Тестовый основной дизайн всё тот же - Caravel SkyWater SKY130: 4,4 миллиона полигонов, 1014 уникальных ячеек, 22 уровня иерархии, 278 МБ GDS (недавно воспользовались прекрасным проектом [TinyTapeout]( https://github.com/TinyTapeout/) - для прогона на различных gds)
К моменту этой истории мы только что закончили перф-кампанию по паразитной экстракции (PEX). Если коротко: чтобы посчитать ёмкости, нужно сначала собрать цепи - обойти иерархию чипа BFS-ом от каждого "сида" (точки на цепи устройства) и выяснить, какие фигуры электрически связаны. На Caravel это 537 748 сидов. Кампания ужала полный холодный прогон с 962 секунд до 70: пространственный грид вместо квадратичного перебора пар, параллельные трейсы на 14 потоках, кеш результата. Все гейты бит-идентичности зелёные, CLI летает.
Приветствуем, уважаемые читатели! На связи Олег Сивченко @OlegSivchenko.
Пару месяцев назад мы анонсировали выход русскоязычного издания знаменитой в узких кругах книги Дениса Бахвалова, которая в оригинале называется «Performance Analysis and Tuning on Modern CPUs» или просто «perf-book». Теперь она, наконец, в продаже и на полках магазинов. Русское издание называется «Оптимизация производительности современных процессоров. 2-е изд.». Это один из моих наиболее сложных, выстраданных, многоэтапных и при этом ценных проектов за последние четыре года. Уверен, он бы не состоялся без активного участия автора, его искренней заинтересованности и содействия в редактуре, проверке терминологии и в целом качества перевода, а также при составлении глоссария.
Если вы читали восторженные статьи о том, как ИИ трансформирует финансовые услуги, у вас могло сложиться впечатление, что внедрение больших языковых моделей и агентных систем в институциональные торговые среды — это в первую очередь инженерная задача: нужно лишь выбрать подходящую модель, настроить нужные параметры и дождаться роста эффективности.
В этой статья мы постарались привести архитектурный взгляд на внедрение языковых моделей в высокочастотную торговую инфраструктуру.
В телеком-сети возник класс «тихих» деградаций: абоненты сообщали, что при отличном уровне сигнала невозможно совершить или принять голосовой вызов, при этом вендорский мониторинг не фиксировал аварий. С точки зрения метрик оборудование оставалось «зеленым», а проблема обнаруживалась только по пользовательским жалобам.
Задача сводилась к автоматическому выявлению таких инцидентов на десятках тысяч объектов сети, используя только исторические временные ряды в ClickHouse, без вынесения вычислений во внешние системы.
Сложность заключается в том, что поведение объектов существенно различается: для большинства базовых станций периодическое отсутствие трафика является нормой, поэтому фиксированные пороги либо дают ложные срабатывания, либо пропускают реальные инциденты.
В статье разбирается инженерный подход: построение индивидуальных исторических профилей нагрузки, медианные бейзлайны и детекция отклонений от ожидаемого поведения.
Показана реализация на SQL в ClickHouse с применением паттерна Islands & Gaps для выделения инцидентов во временных рядах.
На связи Денис из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой системы SPQR, которая помогает легко реализовать горизонтальное масштабирование PostgreSQL с помощью шардирования. И это не теоретическая задача на два шарда и десять таблиц. Необходимо сделать систему, которая в пределе хранит петабайты данных и выдерживает сотни тысяч запросов в секунду.
В прошлой статье мы показывали SPQR со стороны пользователя: как выбрать ключ шардирования, как разложить таблицы на распределённые (distributed) и справочные (reference), как создать распределения и определить диапазоны ключей, а затем перевезти монолит на несколько шардов. Эта статья будет про инженерный путь: архитектуру, компромиссы и грабли, которые встретились по дороге.