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

Загружал пару лет переписки из Telegram в Apache Doris на ноутбуке. Первый запуск 2 часа. После оптимизации 206 400 сообщений за 5 секунд.

Полез в исходники разобраться, почему Stream Load (HTTP-загрузка данных) в Doris работает так быстро. В статье разбор C++ кода: от HTTP PUT до Segment-файла на диске.

Что внутри:
— 14 шагов одного HTTP-запроса (с диаграммой и кодом)
— StreamLoadPipe: буфер 4 MB с backpressure
— Иерархия записи: LoadChannel → DeltaWriter → MemTable → async flush
— 6 практических выводов: что крутить, что мерить, где смотреть compaction score

Когда у вас 50+ узлов Tarantool в кластере, ручное управление соединениями превращается в боль. Узлы падают, реплики становятся мастерами, новые инстансы добавляются — и все это нужно отслеживать в реальном времени. 

Рассказываем, как мы спроектировали go-discovery — библиотеку для автоматического обнаружения узлов кластера Tarantool 3.0.

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

В этой статье я расскажу, как устроен централизованный, надёжный и удобный способ асинхронного взаимодействия сервисов внутри Wildberries. Я Виктор Такташов, Golang-разработчик в команде Trust & Safety. С задачами Highload знаком не понаслышке, потому что когда-то занимался сервером популярной онлайн-игры. К тому же я больше шести лет занимался борьбой, так что с проблемами расправляюсь умело и хладнокровно :-)

Почему мы решили сделать Databus

В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями.

Примеры на Ruby, Go, Java.

Привет, Habr! Наша команда LLM-разработки подготовила статью о реальном практическом опыте тюнинга и тонкой настройке RAG-системы в области охраны труда. Каждый, кто начинал работать с LLM, проходил через этот «медовый месяц»: вы берете LangChain, загружаете с десяток PDF-файлов в ChromaDB, пишете простенький промпт — и происходит магия. Бот отвечает, эксперты в восторге, MVP готов за выходные.

Но магия исчезает ровно в тот момент, когда в базу знаний прилетает тысяча документов, а цена ошибки из «просто забавной галлюцинации» превращается в юридические риски и штрафы. В нашем проекте «Марк» (протестировать тут: @AI_assistantOT_bot)  — ИИ-эксперте по охране труда — мы столкнулись именно с этим: наивный RAG на больших данных не просто работает хуже, он разваливается.

Мы заглянем под капот системы, которая прошла путь от локального скрипта до сложной архитектуры на LangGraph.

Мы подробно разберем:

За почти десять лет, прошедших с момента выхода MySQL 5.7, в мире баз данных многое изменилось. Появились новые подходы к обработке данных, ужесточились требования к безопасности, и даже сам характер приложений стал совершенно иным. MySQL 8.0, увидевший свет в 2018 году, попытался ответить на все эти вызовы, привнеся не только новую функциональность, но и фундаментально иной подход к хранению и обработке данных. 

Тем не менее, большое количество команд остаются верны MySQL 5.7, и на то есть веские причины. Для этой статьи мы в команде платформы данных Yandex Cloud постарались непредвзято посмотреть на производительность обеих версий и протестировать её на реальных нагрузках облачной платформы, а не в рамках стерильного тестового стенда. После прочтения вы сможете обоснованно решить, обновляться ли в ближайшем будущем, или точно понять, почему именно в вашем случаем этого делать не стоит.

Uber держит огромные объёмы данных сразу в своих дата-центрах и в облаке, поэтому их нужно постоянно и быстро копировать между регионами для аналитики и аварийного восстановления.

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

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

Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.

Контейнеры давно стали стандартом современной разработки. Согласно отчету Docker State of Application Development 2025, они используются примерно в 92% IT-организаций и фактически стали универсальным способом упаковки и запуска приложений независимо от платформы и окружения. Это тот случай, когда инфраструктура перестает мешать и начинает экономить время.

Именно поэтому Digital Q.DataBase доступна, в том числе, в виде Docker-образа. Это позволяет за несколько минут попробовать Oracle- и MS SQL-совместимую СУБД на Windows, Linux и macOS, ограничившись несколькими командами, без сложной установки и длительного онбординга. Полноценная рабочая среда готова к использованию сразу после старта контейнера.

По сути, после того как вы скачали архив и подготовили директорию, для запуска Digital Q.DataBase достаточно четырех команд.

Привет, Хаброжители!

От выбора подхода к поглощению данных может зависеть успех или провал работы конвейера данных

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

Микросервисы на схемах выглядят стройно, но в проде часто вырождаются в распределённый монолит: общая БД, синхронные цепочки вызовов и каскадные падения. В этой статье разберемся, как проводить границы сервисов так, чтобы система оставалась автономной — почему декомпозиция по слоям ломает независимость, как опираться на bounded context и бизнес-возможности, как аккуратно выводить legacy через Strangler, и где на практике помогают Database per Service, CQRS и Saga.

Всем привет! Меня зовут Максим, я Go-разработчик в Wildberries & Russ. В высоконагруженных системах сотни сервисов взаимодействуют ежесекундно, и любой малейший простой системы напрямую влияет на прибыль бизнеса. Чтобы уметь быстро находить причины и устранять их за короткие сроки придуманы инструменты, обеспечивающие наблюдаемость приложения. Сегодня поговорим о том, как обеспечить observability и почему без нее жизнь продукта превращается в «черный ящик».

Привет! Меня зовут Антон, я ведущий программист департамента аналитических решений ЮMoney. Хочу поделиться историей о том, как наша команда ускорила один из самых рутинных процессов в работе дата-инженера — загрузку информации из нового источника данных в хранилище. Мы не просто оптимизировали процесс, а практически свели к нулю многодневную рутину и тем самым высвободили время для решения более интересных задач.

Наше технологичное решение помогает превратить сложный и долгий процесс в понятный и быстрый. Если вы строите хранилище данных, развиваете data-платформу или просто устали от однотипных ETL-задач, отнимающих недели, — этот разбор будет вам полезен. Покажу, какие архитектурные решения мы рассматривали и что в итоге сработало.

Когда система растёт, нагрузка на базу становится критичной, а готовых решений для шардирования PostgreSQL не хватает. Стандартные подходы не подошли — поэтому команда сделала свое решение для шардирования в ядре процессинга заказов. Оно позволяет решардировать данные без простоев и деградации метрик.

Привет, Хабр! Меня зовут Игорь Березняк, я руковожу группой процессинга в Техплатформе Городских сервисов Яндекса. В этой статье по мотивам моего доклада на Highload++ расскажу, как мы проектировали шардирование PostgreSQL, чтобы выдерживать нагрузку, сохранить доступность и уложиться в строгие требования по latency.

Transactional outbox обычно внедряют ради консистентности, а в итоге получают новый источник «случайной» задержки и постоянный фон нагрузки на базу из-за поллинга. В этой короткой статье разберем простой поворот идеи: не выбрасывая outbox и relay-процесс, попробовать отправлять событие сразу после коммита и превращать поллинг в редкий fallback. Посмотрим, что это даёт по задержкам и нагрузке, и какие неприятные нюансы всплывают с порядком доставки, дублями и наблюдаемостью.

Всем привет! Меня зовут Денис Захаров, я инженер в Автотеке Авито. В этой статье я расскажу о нелёгкой судьбе SRE на своём опыте: с чем я столкнулся в работе и как в общих чертах SRE-направление представлено в Авито. Статья будет полезна как разработчикам, так и малюткам, желающим узнать, что есть в мире IT. 

Мы сравнили OpenLiteSpeed и классический LEMP для WordPress на реальных серверах. RPS, latency, TTFB, потребление CPU и RAM, поведение под нагрузкой до 500 пользователей. И вот какие итоги у нас получились.

В конце января компания OpenAI порадовала статьёй про то, как у них устроен backend, вот её перевод на русский. Хороший материал для размышлений о system design и, в частности, для поиска ответов на два вопроса: стоит ли идти таким путём начинающему стартапу? стоило ли OpenAI так делать?

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

Меня зовут Никита Шехов, я руковожу командой разработки «Единой цифровой платформы» (ЕЦП) в РСХБ.Цифра. В этой статье хочу рассказать, как мы создавали платформу для автоматизации бизнес-процессов банка, с какими вызовами столкнулись и какие решения оказались ключевыми. Вайб того времени: у нас было два часа на сон, семьдесят пять созвонов в день, пять бизнес-линий или стримов, план, целиком наполненный большими амбициями, целое море разношерстных систем, продуктов и групп разработки, а также ящик прогхантерского энергетика, литры чистого адреналина, ящик зеленого мерча и 12 пузырьков жидкого магния. 

В прошлой статье я закончил полноценную настройку сервера сбора событий и тегов Matomo. Кроме того, я дал наглядную методику расчета нагрузки, исходя из посещаемости ресурса, который вы планируете отслеживать. Сегодняшняя статья из разряда оптимизационных, она нужна только для профессионалов, которые тонко настраивают свои серверы для отслеживания высоконагруженных ресурсов. Важно сразу обозначить границу: эта настройка почти не влияет на маркетологов и аналитиков в интерфейсе Matomo, но радикально воздействует на сервер, базу данных и разработчиков, которые поддерживают всю эту инфраструктуру. По сути, мы переводим Matomo из реактивного режима («пользователь зашел - система начала считать») в предсказуемый серверный процесс с контролируемой нагрузкой.