DATABASE DESIGN – Telegram
DATABASE DESIGN
1.41K subscribers
2.08K photos
3 videos
5.3K links
Лучшие материалы по работе с хранилищами данных на русском и английском языке

Разместить рекламу: @tproger_sales_bot

Правила общения: https://tprg.ru/rules

Другие каналы: @tproger_channels

Другие наши проекты: https://tprg.ru/media
Download Telegram
Когда бизнесу нужно заключать соглашения о поручении обработки ПД

ПД — персональные данные.

Одни бизнесы пользуются услугами других бизнесов или частных исполнителей. Это база.

Пример: обучающий центр хранит данные работников и учащихся в CRM.

Другой пример: флористическая студия пользуется услугами курьерской компании (или самозанятого курьера) для доставки букетов.

В этих и подобных случаях организации, ИП или самозанятые, исполняющие поручения компании — это третьи лица, обрабатывающие ПД.
Разобраться, с кем заключать соглашения

Читать: https://habr.com/ru/articles/972070/

#ru

@database_design | Другие наши каналы
Проверяем популярные движки вычислений на задаче BI-доступа с помощью теста ClickBench

В сегодняшней публикации мы попробуем разобраться в производительности популярных MPP-движков в специализированной задаче ХД – предоставлении доступа к денормализованной витрине данных. Также ответим на вопрос: нужен ли ClickHouse в аналитическом ландшафте, спроектированном по принципу Lakehouse-платформ? Для этого будем использовать бенчмарк ClickBench.

ClickBench появился не так давно, в 2022 году. Методика создана и поддерживается командой ClickHouse. Авторы позиционируют его следующим образом -  «Этот бенчмарк представляет типичную рабочую нагрузку в следующих областях: анализ потоков кликов и трафика, веб-аналитика, машинно-генерируемые данные, структурированные журналы и данные о событиях. Он охватывает типичные запросы в ad-hoc аналитике и дашбордах реального времени». Последний сценарий вызывает у нас особый интерес, ведь редко встретишь архитектурный дизайн аналитического ландшафта, где не было бы решения на базе ClickHouse именно для этой цели, на вершине пирамиды тракта данных от источника до потребителя.


Читать: https://habr.com/ru/companies/datasapience/articles/978430/

#ru

@database_design | Другие наши каналы
Почему ночных загрузок стало недостаточно: опыт внедрения CDC в М2

Всем привет, меня зовут Игорь Горбенко, и я системный аналитик в компании М2.
Отчёты, которые обновляются раз в сутки, хорошо подходят для стратегической аналитики. Но в какой-то момент бизнесу становится важно понимать, что происходит в течение дня, а не только по итогам ночной загрузки.

В М2 мы столкнулись с этим, когда от продуктовых команд и службы поддержки начали приходить запросы на внутридневную отчётность и почти real-time метрики. Наш основной подход — ежедневная батчевая загрузка данных — перестал закрывать такие сценарии, и нам понадобился другой способ работы с изменениями в продуктовых базах.

В этой статье я расскажу, как мы внедряли Change Data Capture (CDC) с использованием Apache Flink, какие задачи это помогло решить, с какими ограничениями мы столкнулись и почему CDC — полезный, но не универсальный инструмент.
CDC и Apache Flink: кратко о технологии и нашем подходе

Давайте начнем разбираться. Некоторые из вас наверняка знакомы с понятием CDC, Change Data Capture — техника захвата изменений в базах данных.

Для контекста стоит отметить Apache Flink — движок для загрузки и обработки батчей и стриминговых данных в реальном времени. В статье речь пойдет про Flink CDC —   фреймворк с открытым исходным кодом для отслеживания изменений данных в базах данных в реальном времени.

В проектах нашего отдела в М2 основной метод загрузки — это ежедневное ночное
копирование продуктовых баз данных (PostgreSQL, MongoDB) в аналитическое хранилище на базе Apache Iceberg и последующая их обработка с помощью движка Trino.


Читать: https://habr.com/ru/companies/m2tech/articles/978258/

#ru

@database_design | Другие наши каналы
Retention в Kafka: Почему сообщения живут дольше, чем вы думаете?

Вы настроили retention.ms = 86400000 (24 часа) и отправили тестовое сообщение. Через сколько времени реально удалится сообщение?


Читать: https://habr.com/ru/articles/979026/

#ru

@database_design | Другие наши каналы
1
Анализ 400k вакансий hh.ru: как мы строили пайплайн и какие тренды нашли

Какие навыки реально нужны в IT? Разбор рынка по данным hh.ru. Мы обработали 393 000 вакансий за 2025 год и делимся результатами: универсальный стек технологий, медианные зарплаты по специальностям и доля удаленки. А еще — техническая реализация нашего open-source проекта для сбора данных.


Читать: https://habr.com/ru/articles/979118/

#ru

@database_design | Другие наши каналы
Более глубокий взгляд на старый UUIDv4 и новый UUIDv7 в PostgreSQL 18

UUIDv4 как первичный ключ в PostgreSQL обычно ругают за «случайность» — но за этим словом прячется конкретная физика: сплиты страниц B-дерева, рыхлый листовой уровень, фрагментация и лишний случайный I/O при чтении. В PostgreSQL 18 появился UUIDv7 — и это хороший повод посмотреть на проблему не на уровне вкусов, а на уровне того, как реально устроены индекс и heap: от корреляции и ctid до статистики страниц и плотности листьев.


Читать: https://habr.com/ru/companies/otus/articles/979212/

#ru

@database_design | Другие наши каналы
🔥1
Охота за недостающим типом данных: история о графах

(Ориентированный) граф — это набор узлов, соединённых стрелками (рёбрами). В узлах и рёбрах могут содержаться данные. Вот примеры графов:


Читать: https://habr.com/ru/articles/979220/

#ru

@database_design | Другие наши каналы
Система мониторинга ML-моделей: превращаем данные в полезный инструмент

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

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


Читать: https://habr.com/ru/companies/tochka/articles/976892/

#ru

@database_design | Другие наши каналы
Система мониторинга ML-моделей: превращаем данные в полезный инструмент

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

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


Читать: https://habr.com/ru/companies/tochka/articles/976892/

#ru

@database_design | Другие наши каналы
Как это сделано: объектное хранилище в MWS Cloud Platform

Всем привет. Я — Дмитрий Шапошников, Tech Lead в команде Object Storage в MWS Cloud Platform. Сегодня мы поговорим о том, как устроено наше объектное хранилище.

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


Читать: https://habr.com/ru/companies/mws/articles/979254/

#ru

@database_design | Другие наши каналы
Итоги 2025: как MongoDB строит платформу для эпохи ИИ
В статье подводятся итоги года: приобретение Voyage AI, запуск AMP для модернизации приложений, добавление поиска и векторного поиска в Community/Enterprise, истории клиентов (Factory, McKesson), смена руководства и прогнозы на 2026.

Читать подробнее

#en

@database_design | Другие наши каналы
MariaDB Connector/ODBC 3.2.8 — стабильный релиз с исправлениями

MariaDB объявила о выпуске Connector/ODBC 3.2.8 (Stable/GA): в релизе устранены различные проблемы. Подробности в заметках о выпуске на сайте MariaDB, доступна загрузка с официального портала.

Читать подробнее

#en

@database_design | Другие наши каналы
Patroni и логическая реплика в PostgreSQL: как не потерять данные при failover’е

Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.


Читать: https://habr.com/ru/companies/flant/articles/978322/

#ru

@database_design | Другие наши каналы
7 облаков, которые не падают в проде

Сравнение 7 российских облачных платформ: от быстрых PaaS-решений до отказоустойчивых IaaS и выделенных серверов. На что смотреть при выборе облака для продакшена.

Читать: «7 облаков, которые не падают в проде»

#ru

@database_design | Другие наши каналы
Как запускать PostgreSQL прямо из бэкапа без restore: FUSE и точечный флэшбэк через postgres_fdw

Несколько лет назад я трудился в проекте, где основной биллинг работал на Oracle. Однажды коллега захотел поправить тестовые начисления в таблице abon_charges и выполнил такой запрос:

UPDATE abon_charges SET amount = 0 WHERE service_id = 123 AND v_abon_id = v_abon_id;

На первый взгляд — ничего страшного. Но v_abon_id = v_abon_id истинно для любой строки. Oracle это не игнорирует. Условие становится:

WHERE service_id = 123 AND TRUE

Так запрос обнулил абсолютно все суммы для service_id=123 за десятки месяцев. В таблице было около 1,8 млн строк по этой услуге.

С такой неприятностью в Oracle может помочь механизм Oracle Flashback. Вкратце: находим проблемную транзакцию, в отдельной сессии включаем чтение таблицы на момент до обновления, снимаем копию в отдельную таблицу и отдаём её нашему виновнику для решения проблемы :).

Мы починили всё без простоя и полного восстановления всего кластера. С тех пор мне всегда хотелось иметь такой «точечный флэшбэк» и в PostgreSQL. Особенно в системах, где восстановление базы на несколько терабайтов может занимать часы. И вот недавно мне довелось организовать такое решение в нашем продукте Platform V CopyWala. Это инструмент для бэкапа от СберТеха, который работает с PostgreSQL. Покажу, как всё устроено.


Читать: https://habr.com/ru/companies/sberbank/articles/977804/

#ru

@database_design | Другие наши каналы
Как мы в объектном хранилище отказы реплик обрабатываем

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

Я Владислав Доронин — Go-разработчик в команде S3 облачной платформы Cloud.ru Evolition. Хочу рассказать про подход к управлению отказами реплик, который мы кристаллизовали опытом выхода из строя разных частей системы. Практика показала, что массовые и не очень отказы приводят к взлету задержки ответов и увеличению количества client-side повторов, которые тоже висят. Пускай на уровне записи из-за требований репликации и гарантии мы много поделать с ситуацией не можем (хотя и там не все безнадежно), то вот чтение гораздо более гибкое. У нас получилось сделать retry на чтении красивыми, об этом сегодня и поговорим.


Читать: https://habr.com/ru/companies/cloud_ru/articles/979412/

#ru

@database_design | Другие наши каналы
Eventually-consistent СУБД — всё?

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

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

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени?

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.


Читать: https://habr.com/ru/articles/980082/

#ru

@database_design | Другие наши каналы
Практический опыт StarRocks: импорт JSON и CSV из Kafka с помощью Routine Load

В архитектуре потоковой обработки данных Kafka, как высокопроизводительная очередь сообщений, обычно используется для агрегации данных, а StarRocks, как высокопроизводительная аналитическая СУБД, отвечает за хранение и анализ. С помощью Routine Load можно стабильно и эффективно загружать в StarRocks данные в форматах JSON и CSV из Kafka.


Читать: https://habr.com/ru/articles/980134/

#ru

@database_design | Другие наши каналы
Oracle — приблизительное разбиение на диапазоны

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.


Читать: https://habr.com/ru/companies/gnivc/articles/977350/

#ru

@database_design | Другие наши каналы
Обезличивание не по приказу — новый сезон подкаста Crosscheck

Привет, Хабр!
Команда CTSG запустила новый сезон подкаста Crosscheck. В одном из первых выпусков эксперты обсуждают актуальную, «горящую» на сегодняшний день, тему обезличивания баз данных: изменения в законодательстве, методы обезличивания, маскирование и многое другое.


Читать: https://habr.com/ru/companies/ctsg/articles/980226/

#ru

@database_design | Другие наши каналы
Обезличивание не по приказу — новый сезон подкаста Crosscheck

Привет, Хабр!
Команда CTSG запустила новый сезон подкаста Crosscheck. В одном из первых выпусков эксперты обсуждают актуальную, «горящую» на сегодняшний день, тему обезличивания баз данных: изменения в законодательстве, методы обезличивания, маскирование и многое другое.


Читать: https://habr.com/ru/companies/ctsg/articles/980226/

#ru

@database_design | Другие наши каналы