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

Привет, Хабр! Меня зовут Роман Ананьев из команды DBA в Авито. В этой статье я расскажу о поиске альтернативы для многошардовых инсталляций MongoDB. Основная цель исследования — найти базу данных с поддержкой автошардирования, которая упростит эксплуатацию и лучше утилизирует ресурсы.

Когда проект вырастает из уютных нескольких шардов MongoDB и превращается в огромную систему на сотни узлов, стандартные подходы к масштабированию начинают пожирать железо и время инженеров. Здесь продуктовый инженер упирается в ресурсы, и у него начинается головная боль, как перелить данные из одних шардов в другие.

Это текст не про то, что MongoDB плохая, она — прекрасный стандарт рынка, в топ-5 движков БД. Я расскажу про то, что происходит, когда у стандартной технологии заканчивается запас прочности на нужном масштабе, и про то, как мы в Авито перебрали множество NoSQL и NewSQL кандидатов, чтобы найти одного подходящего.

В статье я разберу результаты технического исследования, проведённого командой DBA. Мы сравнили производительность, утилизацию ресурсов и архитектурные грабли Cassandra 5, FoundationDB и других БД. Также объясню, почему погоня за низкой latency в случае с FDB обернулась трёхкратным перерасходом дискового пространства.

Когда речь заходит про Lakehouse и федеративный доступ, многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных.

В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks. Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

Всем привет, меня зовут Сергей Татарцев. Я эксперт-разработчик розничной АБС в банке Уралсиб. В финтехе уже много лет, в Уралсибе несколько месяцев и моя ключевая задача здесь – оптимизация в СУБД Oracle. Мне нравится эта тема, она дает развитие инженерному творчеству и очень похожа на спорт, где от подхода к подходу видишь, что взял бОльший вес штанги или планку выше предыдущей.

Мое погружение в работу проходило постепенно, не было задач из серии «бросаемся на амбразуру». Процесс онбординга шёл плавно, в том числе и на тестовых задачах.
В этой статье я хочу поделиться одним из таких тестовых заданий. Где мне удалось ускорить один простой запрос в 250 раз, а подход к решению задачи взят к применению на похожих кейсах.

Современный поиск по видеоконтенту — это высоконагруженная система, требующая молниеносной реакции и безупречной релевантности. Сервис VK Видео оперирует колоссальной базой в 500 миллионов видеороликов и ежедневно обрабатывает около 10 миллионов запросов пользователей. При времени ответа в 0,5 секунды и нагрузке в 1800 RPS алгоритмам необходимо моментально находить именно тот контент, который ожидает увидеть зритель. Однако развитие алгоритмов ранжирования невозможно без качественных данных, на которых они обучаются. 

Традиционный подход с использованием ручной разметки асессорами долгое время оставался индустриальным стандартом, но на масштабах сотен тысяч видео он неизбежно становится бутылочным горлышком продуктовой разработки.

Меня зовут Владислав Чернышев, я руководитель группы качества поиска по видео в AI VK. В этой статье подробно расскажу про путь перехода от классической ручной разметки к гибридной VLM-системе, разберу ошибки и инфраструктурные барьеры, которые пришлось преодолеть для кратного ускорения процессов подготовки обучающих датасетов и офлайн-оценки качества поиска.

Rust скор во время выполнения, а вот компилируется он не так шустро. Едва ли это удивит читателя, имевшего дело с серьёзными базами кода на Rust. В блогах сложился целый жанр постов, повествующих о том, как скостить пару секунд с cargo build.

В нашем проекте мы реализовали функцию, позволяющую пользователям писать прямо на SQL, определяя таким образом таблицы и представления. Под капотом этот код на SQL компилируется в код на Rust — который затем передаётся rustc и с его помощью компилируется в единый бинарник. В этом двоичном файле путём пошагового приращения все представления актуализируются по мере того, как новые потоковые данные поступают в таблицы.

Ранее мы уже предпринимали всевозможные ухищрения, чтобы ускорить компиляцию: стирали типы, активно продавливали дедупликацию кода, сокращали строки, связанные с генерацией кода. В этом мы достаточно преуспели. Но недавно мы стали осваивать работу с крупным новым клиентом (энтерпрайз), у которого оказалась масса сложного SQL-кода. Они написали при помощи наших инструментов много больших программ. Например, там был образец размером в 8562 строк на SQL, который наш компилятор в итоге превращал примерно в ~100k строк на Rust.

Как на самом деле квантование ломает вызов инструментов? Собрал бенчмарк QuantMCP, протестировав модели на 4 ГБ VRAM не на синтетике, а на реальных схемах MCP-серверов. Главный инсайт: популярные бенчмарки вроде BFCL систематически врут - корреляция их оценок с реальным падением качества оказалась отрицательной (-0.755). На живых схемах модели ведут себя иначе: Llama-3.2-1B начинает возвращать саму JSON-схему вместо вызова или галлюцинирует имена инструментов, а Qwen3-0.6B выдумывает несуществующие таблицы в SQLite. Также показал, что сложность схемы не гарантирует большую деградацию, а выбор кванта «по таблицам» может привести к обратному эффекту.

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS, а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных.

Первое, что приходит на ум, — обратиться к этим сервисам по API во время запроса и получить всё необходимое для расчёта. Но один запрос может затрагивать сотни и даже тысячи складов, не считая связанных сущностей. Такое число сетевых вызовов быстро превысит SLA и приведёт к клиентским таймаутам. Сетевые запросы к мастер-системам в нашем случае — непозволительная роскошь, поэтому мы вынуждены держать слепок данных прямо в памяти подов. А значит, появляется новая проблема: как быстро и надёжно доставлять постоянно меняющиеся данные из мастер-систем в оперативную память сотен подов.

У студенческих проектов часто есть проблема: после защиты они отправляются в архив. Студент получает оценку, преподаватель — отчёт, но результат редко кто-то использует.

Меня зовут Кирилл Курдюков, и мы в команде YDB стараемся строить работу иначе. Для нас диплом, курсовая или исследовательский проект — это возможность дать студенту реальную инженерную задачу, а не искусственный учебный пример. Такую задачу, у которой есть контекст, пользователи, ограничения, архитектурные решения и шанс стать частью продукта или его экосистемы.

Ранее мы уже рассказывали на Хабре, как начать контрибьютить в YDB и какие задачи могут подойти для первых опенсорс-вкладов. Эта статья — продолжение той же темы, но с фокусом на студентах: в ней мы делимся, как подбираем темы для дипломов и учебных проектов, как сопровождаем работу и почему стараемся делать так, чтобы результат был полезен не только на защите.

Разбираем мажорное обновление Greengage с версии 6 на 7: как работает pg_upgrade, какие шаги нужны для обновления кластера, чем помогает ggupgrade и какой выигрыш по времени дают копирование файлов и режим жестких ссылок.

В статье рассматривается shrink кластера Greengage DB с использованием ggrebalance: архитектура утилиты, FSM-подход, безопасное перераспределение данных через INSERT, сравнение с CTAS, поддержка rollback и результаты тестов производительности.

2 июня мой мониторинг аптайма разом отрапортовал, что упало почти всё: 932 инцидента за 25 минут. Сайты были живы — все до единого. Виноваты дефолтный лимит файловых дескрипторов 1024 и «оптимизация», тихо размножившаяся в 60 раз. Разбираю по приборам: /proc, ss, EMFILE и почему docker compose restart не спасает.

Что важнее при выборе СУБД: выручка разработчика или реальные возможности продукта?

На российском рынке долгое время ответ фактически сводился к рейтингам продаж. Но ситуация постепенно меняется. Исследование ЛАНИТ стало одной из первых попыток сравнить отечественные СУБД не по финансовым показателям, а по техническим характеристикам — от совместимости и миграции до безопасности и администрирования.

Однако при внимательном изучении результатов возникли вопросы ....

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

Хотели избежать копирования данных, придумали свою служебную разметку, а потом обнаружили: она занимает почти столько же места, сколько сам исходный текст. Мы перестали гадать, посмотрели на реальные данные и применили простые, но эффективные подходы: числа переменной длины, отказ от double в пользу целых типов и умные if-else вместо switch. 

Итог: мы сжали разметку в 2,5 раза и при этом даже немного выиграли в скорости. Рассказываем, как знание предметной области помогло нам не усложнять код, а сделать его быстрее и легче.

Представьте: пользователь добавляет одного сотрудника в группу где‑то в глубине иерархии — и сидит, смотрит на крутящийся лоадер почти минуту. А запрос «покажи всех участников этой группы» отрабатывает так долго, что проще сходить за кофе. Стоит иерархии стать чуть глубже — база и вовсе падает по тайм‑ауту. Именно так вела себя наша старая схема хранения оргструктуры, когда бизнес пришёл с новыми аппетитами: сотни тысяч человек в одной группе и вложенность втрое больше, чем та, на которую всё проектировалось.

Так выглядела наша точка отсчёта. Речь о Директории — компоненте B2B‑платформы Яндекс 360, который отвечает за жизненный цикл организаций и служит единым источником истины об их оргструктуре для других сервисов: Календаря, Почты, Мессенджера, Диска. Когда вы ставите встречу на целый отдел или отправляете общую рассылку для бухгалтерии, под капотом к Директории прилетает запрос «Дай мне всех пользователей этой группы с учётом всей вложенности». Это наш самый горячий запрос, и старая архитектура с ним перестала справляться.

Привет! Меня зовут Малик, я занимаюсь развитием B2B‑платформы в Яндекс 360. В этой статье я расскажу, зачем нам вообще понадобился граф при хранении оргструктур, почему мы решили засунуть этот граф именно в PostgreSQL и как мы это реализовали. А ещё — как нам удалось выкатить такое масштабное архитектурное изменение в продакшен без даунтаймов и что мы получили в итоге.

Как мы спасали Magento 2 с 1 млн товаров и 10 млн CMS страниц от 504 ошибок.

Разбор реального кейса оптимизации Magento 2-магазина с более чем 1 миллионом товаров и 10 миллионами CMS-страниц. Покажу, почему возникали ошибки 504 Gateway Timeout, какие узкие места были обнаружены в архитектуре, и как использование Redis, Varnish, MariaDB и OpenSearch позволило добиться стабильной работы системы под высокой нагрузкой.

В марте 2024 года Redis сменил лицензию и, тем самым, положил начало развитию Valkey. Два года Valkey активно развивался: набирал количество контрибьютеров, коммитов, был встроен в многие проекты — в общем, показал себя на практике. Пришло время подвести итоги и понять: есть ли в этом сравнении победитель.

В статье разберем обе технологии. Будет немного про историю развития и хронологические предпосылки, разбор ключевых фич и почти детективное расследование о жизни двух хранилищ. Также, покажем за кем будущее (по нашему мнению) и зачем мы контрибьютим в одно из них.

Приветствую!

На связи корпоративный архитектор банка Уралсиб - Моне Даниил!

СА говорит ''это срочно для бизнеса'', а КА — ''это не по стратегии''? Узнаете себя? Мы нашли способ, как помирить их в одном домене, не жертвуя ни скоростью, ни качеством

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

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД 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.