DATABASE DESIGN

Не знаете, в чём встречать Новый год? Не беда Мы как раз собрали стек новогодних нарядов, чтобы вы могли сиять ярче, чем любая гирлянда. Скорее заходите в нашу примерочную и выбирайте скин! Реклама

СУБД 2026: что выбирают российские компании null Читать: «СУБД 2026: что выбирают российские компании» #ru @database_design | Другие наши каналы

FTP‑сервер на Linux: настройка для домашнего проекта Флешки постепенно уходят в прошлое, а облачные хранилища не всегда подходят для домашних проектов и экспериментов. Иногда хочется простого и предсказуемого способа обмена файлами — без подписок, лимитов и лишней инфраструктуры. FTP-сервер — один из самых простых вариантов для решения этой задачи. Он не требует сложной инфраструктуры, минимально нагружает систему и поддерживается практически любыми клиентами. В этой статье вы найдёте пошаговый гайд по развёртыванию FTP-сервера на VPS UltraVDS под управлением Debian 12 с использованием vsftpd (Very Secure FTP Daemon). Читать: https://habr.com/ru/companies/ultravds/articles/980188/ #ru @database_design | Другие наши каналы

Сжать государственную VIN-базу с 1,5 ГБ до 21 МБ? Реально! Разработчик рассказал как Разработчик показал, как сократить государственную VIN-базу с 1,5 ГБ до 21 МБ: анализ данных, удаление лишних таблиц, индексов и грамотная оптимизация под чтение Читать: «Сжать государственную VIN-базу с 1,5 ГБ до 21 МБ? Реально! Разработчик рассказал как» #ru @database_design | Другие наши каналы

Инструменты и методы синхронизации данных из распространенных СУБД в StarRocks В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии. Читать: https://habr.com/ru/articles/980392/ #ru @database_design | Другие наши каналы

Как мы организовали полнотекстовый поиск: обзор вариантов Привет Хабр! Меня зовут Михаил. Я backend-разработчик в команде Биллинга в Тензоре. Эта статья — обзор вариантов индексации JSON и JSONB-полей и оптимального поиска текста в них, который мы проделали вместе с командой. Так как используем PostgresSQL, все варианты валидны для него. Читать: https://habr.com/ru/companies/tensor/articles/980222/ #ru @database_design | Другие наши каналы

Как работают CSI-драйверы в Kubernetes: принципы, архитектура и жизненный цикл томов (подробный гайд) В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы. Читать: https://habr.com/ru/companies/flant/articles/977092/ #ru @database_design | Другие наши каналы

Обзор Lakehouse: архитектура, которая объединяет порядок и хаос Вопрос: что же такого прорывного добавили в архитектуру, чтобы она стала считаться чем-то новым с точки зрения инженеров, а не маркетологов? Ответ: фундаментально изменилась парадигма хранения и обработки данных. В отличие от традиционных подходов, где Data Warehouse оперировал исключительно структурированными данными в табличной форме, а Data Lake работал с файлами в их исходном виде, разработчики Lakehouse сумели соединить лучшие качества обеих архитектур. Ключевым отличием стал формат OTF — Open Table Format, через который удалось реализовать единый стандарт доступа к данным и 4 технологически-культурных сдвига. Перечислю их: ... Читать: https://habr.com/ru/companies/cinimex/articles/978522/ #ru @database_design | Другие наши каналы

Обзор Lakehouse: архитектура, которая объединяет порядок и хаос Вопрос: что же такого прорывного добавили в архитектуру, чтобы она стала считаться чем-то новым с точки зрения инженеров, а не маркетологов? Ответ: фундаментально изменилась парадигма хранения и обработки данных. В отличие от традиционных подходов, где Data Warehouse оперировал исключительно структурированными данными в табличной форме, а Data Lake работал с файлами в их исходном виде, разработчики Lakehouse сумели соединить лучшие качества обеих архитектур. Ключевым отличием стал формат OTF — Open Table Format, через который удалось реализовать единый стандарт доступа к данным и 4 технологически-культурных сдвига. Перечислю их: ... Читать: https://habr.com/ru/companies/cinimex/articles/978522/ #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 | Другие наши каналы

Oracle — приблизительное разбиение на диапазоны Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного. Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере. Читать: https://habr.com/ru/companies/gnivc/articles/977350/ #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 | Другие наши каналы

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 | Другие наши каналы

Как мы в объектном хранилище отказы реплик обрабатываем Когда мы работаем с реплицированными системами, вопрос стратегии переключения между репликами, а тем более ее реализация — это довольно значительная головная боль. Если вашей системе необходимо работать с отказами штатно, то наш опыт может подсказать пару новых идей, как можно сделать отказы контролируемыми. Я Владислав Доронин — Go-разработчик в команде S3 облачной платформы Cloud.ru Evolition. Хочу рассказать про подход к управлению отказами реплик, который мы кристаллизовали опытом выхода из строя разных частей системы. Практика показала, что массовые и не очень отказы приводят к взлету задержки ответов и увеличению количества client-side повторов, которые тоже висят. Пускай на уровне записи из-за требований репликации и гарантии мы много поделать с ситуацией не можем (хотя и там не все безнадежно), то вот чтение гораздо более гибкое. У нас получилось сделать retry на чтении красивыми, об этом сегодня и поговорим. Читать: https://habr.com/ru/companies/cloud_ru/articles/979412/ #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 | Другие наши каналы

Под капотом управляемой базы данных в MWS Cloud Platform В 10-м выпуске реалити-проекта Building the Cloud разберут внутренности managed баз. Покажут, как устроена архитектура управляемых баз данных, как работают агенты и реконсиляция, и что нужно сделать инженеру managed-решения, чтобы оно было безопасным. → Эфир 25 декабря, 14:00 (мск) Розыгрыш мерча MWS за лучший вопрос. Зарегистрироваться Это #партнёрский пост

7 облаков, которые не падают в проде Сравнение 7 российских облачных платформ: от быстрых PaaS-решений до отказоустойчивых IaaS и выделенных серверов. На что смотреть при выборе облака для продакшена. Читать: «7 облаков, которые не падают в проде» #ru @database_design | Другие наши каналы

Patroni и логическая реплика в PostgreSQL: как не потерять данные при failover’е Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить. Читать: https://habr.com/ru/companies/flant/articles/978322/ #ru @database_design | Другие наши каналы

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