Высоконагруженные системы *

WAL — один из ключевых компонентов внутреннего устройства Postgres. Файлы WAL для истории бэкапов ужимаются в несколько раз, что говорит об избыточности. Изменяя физические параметры кластера, можно существенно повысить и эффективность локальной записи, и пропускную способность репликации, а можно создать неприятные инциденты.

Привет, Хабр! Я — Андрей Бородин, работаю над Postgres и Apache Cloudberry для Yandex Cloud и вообще. Поддерживаю WAL-G, SPQR, Odyssey и всякое такое. В этой статье на основе доклада для конференции Saint HighLoad++ я расскажу о причинах избыточности, о действиях сообщества, а также о своей работе в рамках подсистемы WAL. Понимание работы WAL поможет вам проектировать ваши сервисы с учетом специфики этой подсистемы.

Привет, Хабр!

В этой статье мы расскажем о заочной борьбе с разработчиками объектного хранилища Hitachi Content Platform. Сначала мы столкнулись с критическим заполнением файловых систем индексов, а в процессе лечения обнаружили вторую, гораздо более глубокую проблему — одна из нод кластера фактически выпала из схемы хранения данных, оставаясь при этом «зелёной» в консоли. Материал будет полезен инженерам, работающим с HCP и другими объектными СХД, а также всем, кто любит истории о нетривиальных расследованиях в недрах корпоративного ПО.

В понедельник в 11 утра по тихоокеанскому времени Дженсен Хуанг выйдет на сцену в куртке, которая давно стала мемом, и скажет то, что уже заставило рынок замереть. “Чип, который потрясет мир”. Без оговорок, без “мы надеемся”, без скучных слайдов с оговорками. Просто констатация факта.

Я перечитал стенограммы шести презентаций Nvidia. Пролистал десятки патентов. И чем больше я погружался в технические детали, тем яснее становилось: нас готовят не к очередному апгрейду, а к смене физической парадигмы. Пока все ждут цифр терафлопсов, Хуанг, кажется, собрался пересадить чипы с медных дорожек на световые лучи. И это меняет всё – от планировки дата-центров до глобального баланса сил в ИИ-гонке.

О создании системы ситуационно-аналитического центра рассказывает Александр Таскаев, директор департамента интеллектуальных систем автоматизации компании САТЕЛ.

Давно уже наступил срок End of Life у Enterprise Linux 7, но возможно на ваших серверах он еще есть в работе. Затягивание процесса переноса могло произойти по разным причинам: сложные процессы миграции, необходимость в дополнительных мощностях для маневра, длительность процесса переноса, зависимость от бизнес-процессов заказчиков.

Зачастую upgrade ОС на месте — самый удобный способ. В данной статье я описываю инструменты и трудности, с которыми вы можете столкнуться в процессе.

«Больше» — не всегда значит «лучше». К пользовательским приложениям в облаках это замечание относится в полной мере. Производительность любой системы определяется ее самым медленным компонентом — «бутылочным горлышком».

Когда проект вырастает до высоких нагрузок, простое «накликивание» дополнительных виртуальных процессоров или оперативной памяти в стандартной конфигурации может не решить корневую проблему. Это все равно, что расширять дорогу перед железнодорожным переездом — новых полос много, но быстрее доехать не получится.

Сегодня мы разберем, почему стандартных, универсальных инструментов бывает недостаточно для высокопроизводительных задач. Мы также покажем, как правильно диагностировать узкие места и подбирать сбалансированную конфигурацию — процессор, диски, сеть — под конкретные рабочие нагрузки.

Сделаем это на примере реальных сценариев и продуктов. Посмотрим, что могут специализированные решения дать там, где универсальные подходы не справляются.

Когда у компании много сервисов и данных, то лучше всего иметь план Б на любую ситуацию, например когда нужно быстро оптимизировать ресурсы и работать в режиме «минус один дата‑центр» без просадок, в то время как утилизация серверов при этом стремится к 100%. Смертельный номер? Вполне посильная задача, с которой справилась команда Яндекс Go. 

Мы провели аудит и поняли, что у нас очень много синхронных походов из критичных сервисов в некритичные, а ещё и поллинг. И это требовало внедрения событийной модели. Тысяча микросервисов, 150 команд разработки, несколько языков программирования, и у каждого разработчика своё представление о том, как правильно читать сообщения из Kafka. Библиотека, которую мы раздали командам, быстро бы обросла форками, заплатками и костылями.

За шесть месяцев командой из шести человек мы превратили эту библиотеку в централизованную платформу Немезида. Сейчас на ней крутится больше 500 интеграций, а новую можно запустить меньше чем за четыре часа. 

Меня зовут Алексей Терентьев, я руководитель одной из служб отдела эффективности Яндекс Go. В этой статье я расскажу, как мы прошли путь от простого «прочитал — обработал — закоммитил» к по‑настоящему масштабной архитектуре: со всеми граблями, факапами и конкретными решениями.

Договоримся о терминах:·       

*Шардинг БД (db sharding) — это метод горизонтального масштабирования, при котором большая база данных разбивается на более мелкие, независимые части (shards), размещаемые на разных физических или виртуальных серверах. Каждый шард содержит подмножество данных, что снижает нагрузку на отдельные узлы, ускоряет запросы и позволяет хранить большие объемы информации, преодолевая ограничения вертикального масштабирования

**Read consistency (согласованность чтения) в БД — это гарантия того, что транзакция видит согласованное состояние данных, соответствующее определенному моменту времени (обычно моменту начала транзакции или запроса).

Группа исследователей впервые смоделировала полный жизненный цикл живой бактериальной клетки с наномасштабным разрешением, отследив поведение каждого гена, белка и химической реакции от репликации ДНК до клеточного деления. Результаты исследования, опубликованные в журнале Cell, открывают возможность заменить сотни реальных лабораторных экспериментов одной комплексной 4D-симуляцией.

Привет, Хабр! Я — Сева, разработчик в Yandex Infrastructure. Уже больше десяти лет я занимаюсь разработкой внутреннего облака Яндекса, которое охватывает около 150 000 физических хостов и поддерживает все сервисы платформы.

Сегодня я представлю вам практический кейс по обеспечению очень высокой надёжности комплексной системы на примере собственного облака Яндекса. Принципы обеспечения надёжности будут продемонстрированы на всех уровнях архитектуры системы, чтобы в итоге сложилась картина, как достичь наивысшей отказоустойчивости. Статья написана по мотивам моего доклада для HighLoad++.

Привет, Хабр!

Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 1С с Microsoft SQL Server на Digital Q.DataBase.

Привет, Хабр! Меня зовут Андрей Шукшов. Я пишу YNMT в Яндекс R&D — это движок инференса, на котором работают почти все наши большие языковые модели (LLM). Бо́льшую часть времени я пытаюсь понять, почему некоторые вещи работают медленно и как сделать так, чтобы у них это получалось чуточку быстрее.

Если вы запускали локальную LLM, то, возможно, тоже удивлялись: почему железо, способное рендерить фотореалистичные миры в реальном времени, работает в темпе печатной машинки? В своей статье я попробую хотя бы отчасти ответить на этот вопрос. Под микроскопом посмотрим на механизм Attention в режиме генерации (декодирования) и, вооружившись лучшими современными практиками ускорения на GPU, объединим всю математику в один эффективный kernel, который выжмет максимум производительности из имеющегося у нас железа.

После первой статьи в комментариях несколько раз прозвучало примерно одно и то же:
"Всё правильно, но это же про любую зрелую СУБД — что с этим делать?"

Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде
"возьмите правильный инструмент X" — а попробовать честно сформулировать:
какими свойствами OLTP-БД должна обладать сама по себе, независимо от того,
насколько хорош ваш оператор, консультант или runbook.

Что такое "контракт" — и почему это не маркетинг

Попробую объяснить не через определение, а через ощущение.

Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро.
Вы просто знаете: нажал педаль — машина тормозит. Это контракт. Он не зависит от того,
правильно ли вы настроили тормозную жидкость этим утром или не забыли включить
"режим торможения" в меню.

СУБД PostgreSQL давно закрепилась в топе благодаря открытости, надёжности и расширяемости, однако ее архитектурный консерватизм порождает ряд нерешённых проблем: отсутствие горизонтального масштабирования, деградация при тысячах соединений, узкое место WAL при высоком commit rate, невозможность полноценной HTAP-обработки и другие.

В статье рассказываем как в новом, третьем поколении машин баз данных Tantor XData Gen3 эти ограничения преодолеваются через глубокую переработку архитектуры — от полного разделения Compute и Storage с протоколом RDMA и распределённой файловой системой PFS до внедрения механизмов CSN для MVCC без блокировок, конвейерной обработки WAL и встроенного MPP‑движка, превращающего PostgreSQL в систему, способную конкурировать с Oracle Exadata уже по‑настоящему. И все это — со 100% сохранением совместимости с «обычным» PostgreSQL.

«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.

Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».

А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.

Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.

Казалось бы, сейчас мы наблюдаем всё, но факт в том, что не управляем ИТ-ландшафтом в целом. Упор на автономию команд и разрозненные инструменты приводит к «разрывам» в управлении: нет единой картины при инцидентах, SLA считаются в табличках, корреляция событий происходит «в головах людей», интеграции держатся на 1–2 специалистах, а построение CMDB и моделей ИТ ландшафта часто игнорируется. В этой статье мы постараемся переосмыслить роль зонтичного мониторинга, и докажем, что это не еще один мониторинг, а важный архитектурный слой.

Ещё в 1987 году Майкл Стоунбрейкер в основополагающем документе «The Design of POSTGRES» написал, что транзакции должны быть 64-битными. Прошло почти 40 лет — и Postgres до сих пор живёт в мире 32-битных счётчиков. Но в декабре 2025 года в кодовую базу тихо вошёл мой коммит, который стал первым реальным шагом к тому, о чём думал Стоунбрейкер. Расскажу, что именно изменилось и почему это важнее, чем кажется.

В этой статье мы продолжаем разбирать возможности веб‑сервера Angie по борьбе с DoS (и немного DDoS) атаками. В предыдущей части мы разобрали стандартные средства, а в этой обсудим возможности сторонних модулей и системы Fail2Ban.

Монолит тормозит, бизнес требует новых отчётов, а каждая правка ломает всё вокруг? Знакомо! В этой статье рассматриваются примеры внедрения CQRS и Event Sourcing. разбираются практики разделения команд и запросов, построение асинхронной архитектуры на Kafka. Под катом — код, Mermaid-схемы и best practices, которые реально работают.

Продолжим разбирать тему параллелизма для баз 1С, но сегодня разговор будет не о MS SQL, а о PostgreSQL. Принципы работы тут отличаются, поэтому нужно пояснение.