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

Если вы администрируете Postgres Pro Enterprise и ваша инфраструктура охватывает несколько дата-центров, вы наверняка сталкивались с одной и той же проблемой: репликация начинает «есть» межцодовый канал и нагружать основной сервер. В новой версии BiHA появилось решение — каскадная репликация. Рассказываем, как она работает и когда стоит использовать её.

Если API начинает тормозить, первое решение обычно очевидно — добавить Redis. Но иногда оказывается, что проблема гораздо проще. В одном из сервисов PostgreSQL начал упираться в повторяющиеся запросы. Одни и те же данные запрашивались тысячами клиентов. Практически каждый HTTP-запрос заканчивался одинаковым SQL-запросом. Любопытство победило — вместо готового решения был написан небольшой кэш прямо внутри сервиса. На это ушло примерно полчаса. Результат оказался неожиданным: некоторые эндпоинты ускорились почти в 7 раз. Вот, почему это произошло и как работает такая схема.

Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).

Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.

В высоконагруженных системах логирование может выполняться:

Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.

Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".

Рефакторинг — это не уборка, это хирургия на живом коде. Большинство провалов здесь не технические: смешали рефакторинг с улучшениями, сделали один огромный коммит, затянули релиз — и три недели работы ушли в мусор. Собрал 10 ошибок из реальных проектов: с примерами кода, разбором механики и способами не наступить на те же грабли.

Мы привыкли думать о вычислениях как о битах, регистрах и арифметике. А что, если базовой единицей вычисления сделать не бит, а локальную геометрическую конфигурацию тетраэдров? В этой статье я покажу дискретный тетраэдрический движок состояний, симметрийную канонизацию, аттракторы, иерархические jump-таблицы и реальные замеры на RTX 3090 — с измеренным exact-ускорением в 554.92 раза на одной и той же задаче.

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.