Привет, Хабр! Тут я хочу подробно разобрать архитектурные решения, которые позволили проекту расти, и показать реальные куски кода, отвечающие за ключевую логику. Будет как и само изложение фактически проделанной работы, так и спорные ситуации, а также открытые вопросы, без которых масштабирование сложно будет в дальнейшем.
Последнее время вся моя работа связана с энтерпрайзом и бигтехом. Но так было не всегда. Лет 12-15 назад работал в производственной компании, и там довелось создать «на коленке» систему мониторинга для промышленного оборудования.
У компании были современные импортные станки с проприетарным софтом, дорогим обслуживанием. Непрерывное круглосуточное производство. Но собственная IT-инфраструктура была слаба – всего несколько разработчиков, а аналитики бизнесовые. Всё же бизнесу нужно было следить за оборудованием: кто работает, кто простаивает, кто отключает датчики. Крайне необходимо было снизить вероятность поломок и простаивания.
В статье расскажу, как «на коленке» собрали многомодульную систему.
Когда речь заходит об оптимизации базы данных, разработчики обычно перечисляют привычный набор приёмов: слегка переписать запрос, накинуть индекс на колонку, денормализовать, сделать analyze, vacuum, cluster, и так по кругу. Классические техники, конечно, работают, но иногда креативный подход даёт гораздо больше.
В этой статье Haki Benita показывает нетипичные техники оптимизации в PostgreSQL.
Привет, Хабр! Меня зовут Александр, я DevRel команды Selena Lakehouse. Пишу про СУБД StarRocks, архитектуры Lakehouse и Streamhouse в Telegram-канале @starrocks_selena (https://t.me/starrocks_selena).
Полгода назад термин Streamhouse начал всплывать на конференциях и в блогах. При этом многие русскоязычные источники, которые я читал, сводят его к «замене Iceberg на Paimon и обновлению Flink» или путают с обычным Lakehouse. На самом деле за Streamhouse стоит интересная архитектурная логика. Конкретный набор компонентов, где каждый решает свою задачу: Apache Flink для вычислений, Apache Fluss как горячий потоковый слой, Apache Paimon как холодное хранилище. Вместе они дают потоковый Lakehouse с задержкой в секунды вместо минут.
Мне стало интересно: можно ли на этом стеке построить полноценный аналитический конвейер? Не на слайдах, а руками в Docker Compose, с SQL и реальным сценарием.
В этой статье:
ClickHouse быстрый. Настолько быстрый, что первые полгода можно жить без оптимизаций вообще — агрегации по миллиарду строк отрабатывают за секунды. Потом данных становится больше, запросов тоже, дашборд начинает подтормаживать, и вы задумываетесь: «а можно ли считать агрегаты заранее?»
Можно. В ClickHouse для этого есть два механизма: materialized views и проекции (projections). Оба пересчитывают данные на этапе вставки. Оба ускоряют чтение. Но работают по-разному.
Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную
вот пример:
SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
...
Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.
Но не суть, вам хочется один раз вычислить значение, без дублирования кода.
Long story short, это делается так:
Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Data Mesh, Fabric, Lakehouse – все говорят, но никто толком не объясняет, чем они отличаются и можно ли их использовать вместе. Разобралась и делюсь структурированно и без воды.
➕ Сравнительная таблица и чек-лист: что выбрать под свою боль.
✔️Сохраняйте, чтобы больше никогда не путаться.
С 1960-х годов в архивы по всему миру начали поступать на хранение цифровые документы. Изначально небольшая, их доля среди собраний возрастала каждое десятилетие. Цифровые фонды при этом бросают вызов одной из главных функций архива: сохранять поступившее в неизменном виде. Неизменяемость для цифрового документа означает смерть, ведь уже через несколько десятков лет может не найтись ни одной машины, которая способна его открыть.
О том, как архивисты и программисты десятилетиями искали выход из этой ситуации, и как цифра меняет основы архивного дела рассказывает германский архивист Кристиан Кайтель. С его разрешения (и благословения издательства) мы публикуем отрывок из его книги «Двенадцать путей в архив. Контуры открытого и прикладного архивоведения».
Keitel C. Zwölf Wege ins Archiv. Umrisse einer offenen und praktischen Archivwissenschaft. Stuttgart: Franz-Steiner-Verlag, 2018. S. 188-202. Перевел Никита Ломакин (телеграм-канал Архивный гик), редактировала Анастасия Тарасова.
Все мы прекрасно знаем, join – одна из самых важных вещей в любой базе данных, но в то же время одна из самых ресурсозатратных операций. Да что уж там, в мире аналитики (OLAP) десятилетиями адепты различных подходов моделирования данных все спорят без остановки что лучше: нормализация (то есть много join) или денормализация (то есть мало join). Но все понимают, если можно без join, лучше без. Проблема в том, что они нужны практически всегда.
В этой статье давайте посмотрим, можно ли реально обойдись без join и в каких ситуациях? А также 4 способа, которые кратно ускорят ваши запросы.
Привет! Недавно мы с проектом (а по факту я в гордом одиночестве) переезжали с MySQL на PostgreSQL. Зачем? Проект — гео‑сервис для рыбаков: карта с точками, поиск рядом, фильтры по регионам, водоёмам и рыбам. MySQL стал тормозить на гео‑запросах, а PostGIS обещал скорость и порядок. Плюс мы всё равно переезжали на новый VDS – решили заодно сменить СУБД, пока данных не стало неприлично много.
Со мной опять произошла какая-то мистика.
С тех пор как начал писать серию статей под названием «Пятьдесят лет по стезе программирования», особенно когда готовил третью статью, мне хотелось найти рукопись с исходными кодами, написанного мною транслятора с языка РПГ (RPG) для ЭВМ М-220:
Вечный конфликт: аналитики требуют свободы маневра, а DBA закрывают доступ к базе, опасаясь одного «убийственного» запроса, который положит весь кластер. В Postgres Professional мы разработали Tengri — систему, где каждый пользователь получает изолированные вычислительные ресурсы. Рассказываю, как архитектура индивидуальных вычислителей позволяет избежать конкуренции за ресурсы и почему после такого опыта возвращаться к общим очередям запросов уже не хочется.
Привет, Хабр! Меня зовут Игорь Березняк, и мы с командой делаем Техплатформу Городских сервисов Яндекса. Я уже писал на Хабре про архитектуру платформы, рассказывал на «Хайлоаде» (и на Хабре) про шардирование и миграцию на YDB.
Эта статья написана по мотивам последнего доклада. В ней я рассказываю не о самой миграции (ну мигрировали и мигрировали, этим сейчас никого не удивишь), а о её причинах.
Дело в том, что PostgreSQL — потрясающая система. Инженерное чудо, позволяющее сейчас нескольким разработчикам собирать системы, для которых всего пару десятков лет назад потребовалась бы команда архитекторов и контракт с вендором.
Но, разрабатывая любую систему, программисты пишут код, который лучше всего работает в ожидаемых сценариях. Эта статья о том, с какими ограничениями PostgreSQL сталкиваются системы масштаба Яндекс Такси при росте. Я расскажу про время выбора нового мастера при репликации, лимиты количества соединений, разработку холодного хранилища.
В моём рассказе переход на YDB — это в первую очередь смена одних ожидаемых сценариев работы на другие. Со своими последствиями, компромиссами, необходимостью адаптировать и переписывать код.
Если вы уже используете Битрикс24, но вручную анализируете сделки через фильтры и стандартные отчеты, то теряете скорость и масштаб аналитики. В статье рассказываю, как встроенный BI-конструктор помогает собирать кастомные метрики без подключения внешних BI-платформ.
Привет, Хабр!
Продолжаем рассказывать, как построить отказоустойчивую связку на кластере MySQL.
Краткое содержание первой серии части (гиперссылка) нашего мануала:
мы развернули двухузловой кластер MySQL с асинхронной репликацией по GTID, улучшенной полу-синхронностью, и добавили два уровня отказоустойчивости: на уровне сервиса IP и роли БД.
Теперь пришло время рассмотреть, как происходит отказоустойчивое переключение пошагово в разных сценариях.
В начале января 2026 года стало известно, что проект Anna's Archive, основная цель которого — поиск и скачивание бесплатных пиратских книг и другого контента, теперь не контролирует свое основное доменное имя: оно было переведено в статус serverHold. Возможная причина такой ситуации — неоднократные и многочисленные претензии со стороны правообладателей.
📊 Хотите стать аналитиком данных, но не знаете, с какой стороны подойти?
Я собрала чек-лист для старта в 2026 году, никакой воды - только то, что реально спросят на собеседовании:
🛠 Что учить: SQL (с оконными функциями), Python (Pandas), BI-системы.
🧠 Важный софт-скилл, о котором молчат курсы — управление ожиданиями заказчика.
🔮 Бонус: что нужно знать про DWH и ML, чтобы выделяться среди других джунов.
JDBC — технология, которую каждый Java-разработчик учил на курсах, но мало кто применяет правильно. В этой статье расскажу о лучших практиках работы с базами данных из Java-приложений, которые обеспечивают максимальную производительность в продакшене.
За 30+ проектов я использовал RAG в 80% случаев, Fine-tuning — в 15%, комбинацию — в 5%. В статье — практическая матрица выбора: когда RAG достаточно, когда нужен fine-tuning, а когда гибрид. С примерами кода, реальными сценариями и разбором ошибок.2
MySQL, который выживает: отказоустойчивый кластер с Orchestrator
Разбираем настройку HA-кластера с Keepalived и Orchestrator для тех, кто предпочитает контроль облачным black box-решениям.
Хабр, привет!
Почему проблема отказа мастера в кластере MySQL до сих пор актуальна? Потому что сегодня 10 минут простоя у крупных заказчиков – это ЧП, а человеческий фактор в кризисной ситуации – главный источник риска. Многие проекты, мигрируя на MySQL 8.0, заново проходят путь настройки отказоустойчивости. И далеко не все готовы доверить свою основную базу данных облачным managed-сервисам, иногда нужен полный контроль на своей инфраструктуре.
