Как повысить качество клиентских данных
Привет, Хабр. В этой статье делюсь опытом повышения качества клиентских данных в онлайн-обучении и выводами, к которым я пришел по итогам.
Узнать, как улучшить качество данных
Читать: https://habr.com/ru/companies/otus/articles/957286/
#ru
@database_design | Другие наши каналы
Привет, Хабр. В этой статье делюсь опытом повышения качества клиентских данных в онлайн-обучении и выводами, к которым я пришел по итогам.
Узнать, как улучшить качество данных
Читать: https://habr.com/ru/companies/otus/articles/957286/
#ru
@database_design | Другие наши каналы
Семантика «ровно один раз» для Agentic AI
В статье объясняется, почему exactly-once важна для нагрузок Agentic AI и как Oracle Transactional Event Queue обеспечивает доставку ровно один раз и согласованность транзакций, снижая дубли и ошибки.
Читать подробнее
#en
@database_design | Другие наши каналы
В статье объясняется, почему exactly-once важна для нагрузок Agentic AI и как Oracle Transactional Event Queue обеспечивает доставку ровно один раз и согласованность транзакций, снижая дубли и ошибки.
Читать подробнее
#en
@database_design | Другие наши каналы
Oracle
Achieving Exactly-Once Semantics for Agentic AI with Oracle TxEventQ
This blog explains the importance of exactly-once semantics, why it is relevant to Agentic AI workloads and how Oracle Transactional Event Queue enables this.
❤1
Как связать Apache Kafka и Oracle TxEventQ — 2 подхода
В блоге кратко объясняют два способа интеграции Apache Kafka с Oracle TxEventQ: прямой обмен сообщениями и через адаптеры/мосты. Разбирают плюсы и сценарии применения каждого варианта — полезно архитекторам и разработчикам.
Читать подробнее
#en
@database_design | Другие наши каналы
В блоге кратко объясняют два способа интеграции Apache Kafka с Oracle TxEventQ: прямой обмен сообщениями и через адаптеры/мосты. Разбирают плюсы и сценарии применения каждого варианта — полезно архитекторам и разработчикам.
Читать подробнее
#en
@database_design | Другие наши каналы
Oracle
Oracle TxEventQ and Apache Kafka Integration: Two Powerful Paths to Modern Event Streaming
The blog explains two distinct ways in which your Apache Kafka and Oracle TxEventQ can interoperate
Мой путь к «умному» LibreChat: боль, радость и 20 тестовых вопросов к RAG
Помню тот момент, когда я в очередной раз пытался вытащить конкретную спецификацию из стопки PDF‑отчетов. «Вот бы ИИ мог сам в этом покопаться», — подумал я. Это чувство знакомо многим, кто работает с большими массивами текстовой информации.
Тогда я и решил, что хватит это терпеть. Последующий день превратился в марафон по установке и настройке RAG (генерация с дополнением извлеченной информацией). Это был путь проб и ошибок, который в итоге увенчался успехом. И теперь я хочу поделиться этим опытом с вами.
В этом материале мы:
• Пошагово установим rag_api в уже развёрнутый LibreChat;
• Воспользуемся Python 3.12, PostgreSQL 17;
• В командной строке соберём PostgreSQL‑аддон pg_vector через x64 Native Tools Command Prompt for VS 2022;
• Протестируем RAG‑систему 20 вопросами к вымышленной документации, сгенерированной в Gemini 2.5 Pro;
• Узнаем, во сколько раз медленнее запускать через CPU, чем через GPU.
Приятного прочтения!
Читать: https://habr.com/ru/companies/bothub/articles/956892/
#ru
@database_design | Другие наши каналы
Помню тот момент, когда я в очередной раз пытался вытащить конкретную спецификацию из стопки PDF‑отчетов. «Вот бы ИИ мог сам в этом покопаться», — подумал я. Это чувство знакомо многим, кто работает с большими массивами текстовой информации.
Тогда я и решил, что хватит это терпеть. Последующий день превратился в марафон по установке и настройке RAG (генерация с дополнением извлеченной информацией). Это был путь проб и ошибок, который в итоге увенчался успехом. И теперь я хочу поделиться этим опытом с вами.
В этом материале мы:
• Пошагово установим rag_api в уже развёрнутый LibreChat;
• Воспользуемся Python 3.12, PostgreSQL 17;
• В командной строке соберём PostgreSQL‑аддон pg_vector через x64 Native Tools Command Prompt for VS 2022;
• Протестируем RAG‑систему 20 вопросами к вымышленной документации, сгенерированной в Gemini 2.5 Pro;
• Узнаем, во сколько раз медленнее запускать через CPU, чем через GPU.
Приятного прочтения!
Читать: https://habr.com/ru/companies/bothub/articles/956892/
#ru
@database_design | Другие наши каналы
Кластер Patroni в docker контейнерах
В статье рассматривается создание кластера Patroni и etcd в одной виртуальной машине в контейнерах docker. Приводится пример, когда Patroni не будет автоматически восстанавливать кластер PostgreSQL.
Patroni в докере
Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.
Читать: https://habr.com/ru/companies/tantor/articles/957790/
#ru
@database_design | Другие наши каналы
В статье рассматривается создание кластера Patroni и etcd в одной виртуальной машине в контейнерах docker. Приводится пример, когда Patroni не будет автоматически восстанавливать кластер PostgreSQL.
Patroni в докере
Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.
Читать: https://habr.com/ru/companies/tantor/articles/957790/
#ru
@database_design | Другие наши каналы
Toshiba разработала HDD с 12 пластинами: до 40 ТБ в одном корпусе. Что за новинка?
В октябре 2025 года Toshiba представила жесткий диск, который сразу привлек внимание рынка. Дело в том, что разработчикам удалось разместить двенадцать пластин в стандартном 3,5-дюймовом корпусе, где раньше помещалось не больше десяти. Более того, это решение открывает путь к появлению моделей емкостью до 40 ТБ уже в ближайшие пару лет — при тех же размерах и уровне энергопотребления.
Стоит отметить, что во втором квартале 2025 года доля Toshiba на рынке жестких дисков была около 17 % — меньше, чем у Seagate и Western Digital. Компания развивается и продолжает развивать собственные технологии, делая ставку на повышение плотности записи и надёжности носителей. Последняя разработка с двенадцатью пластинами стала следующим шагом в этой стратегии. Новинка рассчитана прежде всего на дата-центры, где особенно важны высокая ёмкость, стабильная работа и низкая цена за гигабайт.
Читать: https://habr.com/ru/companies/selectel/articles/957952/
#ru
@database_design | Другие наши каналы
В октябре 2025 года Toshiba представила жесткий диск, который сразу привлек внимание рынка. Дело в том, что разработчикам удалось разместить двенадцать пластин в стандартном 3,5-дюймовом корпусе, где раньше помещалось не больше десяти. Более того, это решение открывает путь к появлению моделей емкостью до 40 ТБ уже в ближайшие пару лет — при тех же размерах и уровне энергопотребления.
Стоит отметить, что во втором квартале 2025 года доля Toshiba на рынке жестких дисков была около 17 % — меньше, чем у Seagate и Western Digital. Компания развивается и продолжает развивать собственные технологии, делая ставку на повышение плотности записи и надёжности носителей. Последняя разработка с двенадцатью пластинами стала следующим шагом в этой стратегии. Новинка рассчитана прежде всего на дата-центры, где особенно важны высокая ёмкость, стабильная работа и низкая цена за гигабайт.
Читать: https://habr.com/ru/companies/selectel/articles/957952/
#ru
@database_design | Другие наши каналы
Эволюция архитектуры баз данных
Система управления базами данных — крайне сложный программный продукт, и рассказ о его архитектуре потянет на целый увесистый том. А поскольку заголовок обещает нам не просто «архитектуру», а даже «эволюцию архитектуры», сегодня остановимся на одном из компонентов, ключевом с точки зрения производительности, — системе хранения данных. А заодно посмотрим, каково место самых современных систем на рынке и почему оно такое.
Привет, Хабр! Я Владимир Комаров — программист, администратор, архитектор данных и инфраструктуры, преподаватель и автор. В этой статье по мотивам моего доклада на Highload++ мы посмотрим, как развивались системы управления базами данных: с чего всё начиналось, как система хранения данных СУБД эволюционировала, и в каком состоянии эта область находится сейчас. А заодно узнаем, существует ли идеальная СУБД, и если нет, то как приблизиться к идеалу.
Читать: https://habr.com/ru/companies/oleg-bunin/articles/950454/
#ru
@database_design | Другие наши каналы
Система управления базами данных — крайне сложный программный продукт, и рассказ о его архитектуре потянет на целый увесистый том. А поскольку заголовок обещает нам не просто «архитектуру», а даже «эволюцию архитектуры», сегодня остановимся на одном из компонентов, ключевом с точки зрения производительности, — системе хранения данных. А заодно посмотрим, каково место самых современных систем на рынке и почему оно такое.
Привет, Хабр! Я Владимир Комаров — программист, администратор, архитектор данных и инфраструктуры, преподаватель и автор. В этой статье по мотивам моего доклада на Highload++ мы посмотрим, как развивались системы управления базами данных: с чего всё начиналось, как система хранения данных СУБД эволюционировала, и в каком состоянии эта область находится сейчас. А заодно узнаем, существует ли идеальная СУБД, и если нет, то как приблизиться к идеалу.
Читать: https://habr.com/ru/companies/oleg-bunin/articles/950454/
#ru
@database_design | Другие наши каналы
❤1
Гид по Cloudberry ч.2: advanced-возможности, дорожная карта и планы развития
В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы.
Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.
Читать: https://habr.com/ru/companies/yandex_cloud_and_infra/articles/957662/
#ru
@database_design | Другие наши каналы
В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы.
Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.
Читать: https://habr.com/ru/companies/yandex_cloud_and_infra/articles/957662/
#ru
@database_design | Другие наши каналы
Гид по Cloudberry ч.2: advanced-возможности, дорожная карта и планы развития
В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы.
Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.
Читать: https://habr.com/ru/companies/yandex_cloud_and_infra/articles/957662/
#ru
@database_design | Другие наши каналы
В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы.
Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.
Читать: https://habr.com/ru/companies/yandex_cloud_and_infra/articles/957662/
#ru
@database_design | Другие наши каналы
Что выгоднее и безопаснее для хранения фото, видео и других данных: облако или собственный NAS
Думаю, не будет большой ошибкой предположить, что ваш смартфон имеет накопитель минимум на 128 ГБ, больше половины из которых почти наверняка занимают фотографии, какие-то случайные видео и, конечно, скриншоты. Держать это все во встроенной памяти, конечно, можно. Но тогда есть риск, что оставшегося пространства банально не хватит для новых приложений и Телеграма с Ватсапом, которые имеют свойство разрастаться очень и очень сильно. Значит, все это добро надо куда-то деть. Вопрос в том – куда. Облако – ненадежно. Свое железо – надежно, но дорого. Или наоборот… В общем, давайте посмотрим на вещи объективно и постараемся понять, где лучше всего хранить свои данные.
Читать: https://habr.com/ru/companies/finops_ru/articles/958198/
#ru
@database_design | Другие наши каналы
Думаю, не будет большой ошибкой предположить, что ваш смартфон имеет накопитель минимум на 128 ГБ, больше половины из которых почти наверняка занимают фотографии, какие-то случайные видео и, конечно, скриншоты. Держать это все во встроенной памяти, конечно, можно. Но тогда есть риск, что оставшегося пространства банально не хватит для новых приложений и Телеграма с Ватсапом, которые имеют свойство разрастаться очень и очень сильно. Значит, все это добро надо куда-то деть. Вопрос в том – куда. Облако – ненадежно. Свое железо – надежно, но дорого. Или наоборот… В общем, давайте посмотрим на вещи объективно и постараемся понять, где лучше всего хранить свои данные.
Читать: https://habr.com/ru/companies/finops_ru/articles/958198/
#ru
@database_design | Другие наши каналы
Я выполнил реверс-инжиниринг веб-обфускации Amazon, потому что приложением Kindle пользоваться невозможно
TL;DR
• Я впервые купил на Amazon электронную книгу
• Android-приложение Kindle самой компании Amazon было очень забагованным и часто вылетало
• Попробовал скачать мою книгу, чтобы читать её в реально работающем приложении для чтения
• Осознал, что Amazon больше не позволяет этого делать
• Решил назло выполнить реверс-инжиниринг её системы обфускации
• Обнаружил множество слоёв защиты, в том числе рандомизированные алфавиты
• Победил их все при помощи колдунства с сопоставлением шрифтов
Читать: https://habr.com/ru/articles/958132/
#ru
@database_design | Другие наши каналы
TL;DR
• Я впервые купил на Amazon электронную книгу
• Android-приложение Kindle самой компании Amazon было очень забагованным и часто вылетало
• Попробовал скачать мою книгу, чтобы читать её в реально работающем приложении для чтения
• Осознал, что Amazon больше не позволяет этого делать
• Решил назло выполнить реверс-инжиниринг её системы обфускации
• Обнаружил множество слоёв защиты, в том числе рандомизированные алфавиты
• Победил их все при помощи колдунства с сопоставлением шрифтов
Читать: https://habr.com/ru/articles/958132/
#ru
@database_design | Другие наши каналы
Представляем XBRL-CSV — машиночитаемую отчетность в формате для людей
Примечание: Статья посвящена формату XBRL-CSV2 (тэг
Авторство формата принадлежит Банку России.
Автор статьи — архитектор, принимавший участие в разработке формата в качестве технического специалиста.
Введение.
Банк России использует стандарт XBRL для сбора отчетности от некредитных финансовых организаций. Несмотря на всю продуманность XBRL, при формировании и обработке отчетности возникает проблема, связанная с реестровыми формами.
Эти формы содержат гиперкубы с открытыми осями. При большой вариативности значений таких осей реестровые отчеты становятся чрезвычайно объемными.
Решение этой проблемы — создание производного от XBRL-XML формата: XBRL-CSV.
Основная предпосылка: CSV органически приспособлен для хранения реестровых форм. Открытые оси выносятся в начальные колонки, а комбинации значений ячеек открытых осей в каждой строке образуют составной открытый ключ, однозначно идентифицирующий запись.
Остальные колонки — это данные, которые определяют три аспекта показателя:
Читать: https://habr.com/ru/articles/958356/
#ru
@database_design | Другие наши каналы
Примечание: Статья посвящена формату XBRL-CSV2 (тэг
"@context":"www.cbr.ru/xbrl_csv2").Авторство формата принадлежит Банку России.
Автор статьи — архитектор, принимавший участие в разработке формата в качестве технического специалиста.
Введение.
Банк России использует стандарт XBRL для сбора отчетности от некредитных финансовых организаций. Несмотря на всю продуманность XBRL, при формировании и обработке отчетности возникает проблема, связанная с реестровыми формами.
Эти формы содержат гиперкубы с открытыми осями. При большой вариативности значений таких осей реестровые отчеты становятся чрезвычайно объемными.
Решение этой проблемы — создание производного от XBRL-XML формата: XBRL-CSV.
Основная предпосылка: CSV органически приспособлен для хранения реестровых форм. Открытые оси выносятся в начальные колонки, а комбинации значений ячеек открытых осей в каждой строке образуют составной открытый ключ, однозначно идентифицирующий запись.
Остальные колонки — это данные, которые определяют три аспекта показателя:
Читать: https://habr.com/ru/articles/958356/
#ru
@database_design | Другие наши каналы
Postgres 18 async IO – шаг к «взрослым» нагрузкам?
Давайте честно – пока что Postgres редко используется для действительно больших и нагруженных баз. Этому множество причин, но главная формулируется просто: «не тянет».
У каждого есть своя граница, где Postgres ещё применим, а дальше —уже нет. Обычно это где-то между одним и пятью терабайтами, дальше жить с этим «больно».
База просто не может обработать большой объем данных с той скоростью, которую способны выдать диски.
И вот — Postgres 18, впервые за долгое время, предлагает не косметическую, а фундаментальную новинку. То, что в Oracle есть уже 20+ лет — асинхронный ввод-вывод (аsync IO).
Попробуем посмотреть async IO и ответить на вопрос - стал ли Postgres ближе к «взрослым» нагрузкам?
Читать: https://habr.com/ru/articles/958382/
#ru
@database_design | Другие наши каналы
Давайте честно – пока что Postgres редко используется для действительно больших и нагруженных баз. Этому множество причин, но главная формулируется просто: «не тянет».
У каждого есть своя граница, где Postgres ещё применим, а дальше —уже нет. Обычно это где-то между одним и пятью терабайтами, дальше жить с этим «больно».
База просто не может обработать большой объем данных с той скоростью, которую способны выдать диски.
И вот — Postgres 18, впервые за долгое время, предлагает не косметическую, а фундаментальную новинку. То, что в Oracle есть уже 20+ лет — асинхронный ввод-вывод (аsync IO).
Попробуем посмотреть async IO и ответить на вопрос - стал ли Postgres ближе к «взрослым» нагрузкам?
Читать: https://habr.com/ru/articles/958382/
#ru
@database_design | Другие наши каналы
Документный хаос? RAG-система придёт на помощь
Статья описывает практическую реализацию системы Retrieval-Augmented Generation (RAG) для превращения документов в интерактивную базу знаний. Показано, как хранение эмбеддингов в Qdrant и интеграция с языковой моделью (LLM) позволяют быстро получать точные ответы на вопросы. Рассматриваются архитектура, ключевые компоненты и внутренние механизмы работы системы, полезные для разработчиков и новичков в области RAG.
Читать: https://habr.com/ru/articles/955768/
#ru
@database_design | Другие наши каналы
Статья описывает практическую реализацию системы Retrieval-Augmented Generation (RAG) для превращения документов в интерактивную базу знаний. Показано, как хранение эмбеддингов в Qdrant и интеграция с языковой моделью (LLM) позволяют быстро получать точные ответы на вопросы. Рассматриваются архитектура, ключевые компоненты и внутренние механизмы работы системы, полезные для разработчиков и новичков в области RAG.
Читать: https://habr.com/ru/articles/955768/
#ru
@database_design | Другие наши каналы
Решение проблемы двойного букинга: паттерны проектирования систем
Давно прошло то время, когда люди стояли в длинных очередях для покупки билетов на концерты, авиарейсы, фильмы, матчи и другие события.
Технологические компании наподобие Ticketmaster, BookMyShow, Airbnb, Delta Airlines и так далее сделали бронирование делом одного клика, позволившим покупать билеты из дома.
Эта простота стала возможной благодаря технологическим платформам и сервисам, которые прячут от пользователей всю сложность и решают неординарные инженерные задачи. Одна из таких задач — предотвращение бронирования одного места несколькими пользователями.
Представьте, в каком положении окажутся два пользователя, купивших одно и то же место на мероприятие и осознавших это только перед его началом. Из-за этого организатор теряет доверие покупателей, а пользователи дважды задумаются, прежде чем покупать билеты на следующее мероприятие.
Поэтому важно создать надёжное решение классической задачи — двойного букинга.
Из этой статьи вы узнаете, как эту задачу решают разные технологические компании. У каждой компании свои особенности, поэтому единого универсального решения нет.
Мы рассмотрим различные архитектурные паттерны и разберёмся в их плюсах и минусах. Статья поможет вам обрести глубокое понимание и наработать знания в системном мышлении.
Читать: https://habr.com/ru/articles/957954/
#ru
@database_design | Другие наши каналы
Давно прошло то время, когда люди стояли в длинных очередях для покупки билетов на концерты, авиарейсы, фильмы, матчи и другие события.
Технологические компании наподобие Ticketmaster, BookMyShow, Airbnb, Delta Airlines и так далее сделали бронирование делом одного клика, позволившим покупать билеты из дома.
Эта простота стала возможной благодаря технологическим платформам и сервисам, которые прячут от пользователей всю сложность и решают неординарные инженерные задачи. Одна из таких задач — предотвращение бронирования одного места несколькими пользователями.
Представьте, в каком положении окажутся два пользователя, купивших одно и то же место на мероприятие и осознавших это только перед его началом. Из-за этого организатор теряет доверие покупателей, а пользователи дважды задумаются, прежде чем покупать билеты на следующее мероприятие.
Поэтому важно создать надёжное решение классической задачи — двойного букинга.
Из этой статьи вы узнаете, как эту задачу решают разные технологические компании. У каждой компании свои особенности, поэтому единого универсального решения нет.
Мы рассмотрим различные архитектурные паттерны и разберёмся в их плюсах и минусах. Статья поможет вам обрести глубокое понимание и наработать знания в системном мышлении.
Читать: https://habr.com/ru/articles/957954/
#ru
@database_design | Другие наши каналы
Упрощаем Spark через Catalog API
Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.
Читать: https://habr.com/ru/articles/958478/
#ru
@database_design | Другие наши каналы
Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.
Читать: https://habr.com/ru/articles/958478/
#ru
@database_design | Другие наши каналы
Шпаргалка по работе с PostgreSQL для бэкенд-разработчиков
Лайфхаки для миграций, оптимизации и избегания граблей
Реальные лайфхаки и проверенные практики по миграциям, оптимизации запросов, управлению индексами и обратной совместимости кода. Узнайте, как:
- Не сломать прод при миграции.
- Избежать N+1 и других проблем SQL-запросов.
- Планировать откаты и работать безопасно на высоконагруженных БД.
Читать: https://habr.com/ru/companies/beget/articles/920772/
#ru
@database_design | Другие наши каналы
Лайфхаки для миграций, оптимизации и избегания граблей
Реальные лайфхаки и проверенные практики по миграциям, оптимизации запросов, управлению индексами и обратной совместимости кода. Узнайте, как:
- Не сломать прод при миграции.
- Избежать N+1 и других проблем SQL-запросов.
- Планировать откаты и работать безопасно на высоконагруженных БД.
Читать: https://habr.com/ru/companies/beget/articles/920772/
#ru
@database_design | Другие наши каналы
Интеграции без иллюзий: интервью с Владимиром Гантуриным, техническим директором Compo Soft
Интеграции и обмен данными сегодня — это не просто техническая задача, а фундамент цифровой зрелости бизнеса. Российский рынок переживает быстрые изменения: уход западных вендоров, рост требований к надёжности и безопасности, распространение микросервисных архитектур. Как компании справляются с вызовами, когда стоит менять старую интеграционную платформу, зачем бизнесу API Gateway и брокеры сообщений, и можно ли обойтись без интеграционной шины?
Читать: https://habr.com/ru/companies/compo/articles/958584/
#ru
@database_design | Другие наши каналы
Интеграции и обмен данными сегодня — это не просто техническая задача, а фундамент цифровой зрелости бизнеса. Российский рынок переживает быстрые изменения: уход западных вендоров, рост требований к надёжности и безопасности, распространение микросервисных архитектур. Как компании справляются с вызовами, когда стоит менять старую интеграционную платформу, зачем бизнесу API Gateway и брокеры сообщений, и можно ли обойтись без интеграционной шины?
Читать: https://habr.com/ru/companies/compo/articles/958584/
#ru
@database_design | Другие наши каналы
Где до сих пор используют дискеты и другие устаревшие носители, которые не умирают даже в 2025 году
В это может быть непросто поверить, на наших глазах уже выросло целое поколение, которое дискету не то что не использовало, а даже в глаза не видело. В целом, все логично. Технология давно умерла и предана забвению. Так, по крайней мере, принято считать. Но есть категория людей, которым об этом почему-то не рассказали, и они продолжают полагаться в своей работе даже не на диски DVD-RW, а на старые добрые дискеты. Разных форматов, конечно, но все-таки дискеты. И таких историй больше, чем кажется.
Читать: https://habr.com/ru/companies/x-com/articles/958624/
#ru
@database_design | Другие наши каналы
В это может быть непросто поверить, на наших глазах уже выросло целое поколение, которое дискету не то что не использовало, а даже в глаза не видело. В целом, все логично. Технология давно умерла и предана забвению. Так, по крайней мере, принято считать. Но есть категория людей, которым об этом почему-то не рассказали, и они продолжают полагаться в своей работе даже не на диски DVD-RW, а на старые добрые дискеты. Разных форматов, конечно, но все-таки дискеты. И таких историй больше, чем кажется.
Читать: https://habr.com/ru/companies/x-com/articles/958624/
#ru
@database_design | Другие наши каналы
Непопулярный вариант развертывания хранилища Nextcloud
Привет, Хабр. У меня тут такая история случилась: накопился массив фотографий с путешествий, всяких документов, семейных архивов и учебных материалов по всяких курсам — всего где-то гигов 300. Все важное, ценное, и, конечно, это все очень не хочется потерять.
Я почитал статьи здесь на Хабре, погуглил и понял, что многие покупают себе физические серверы с дисками и на них устраивают хранилища, например, Nextcloud. Звучит удобно: можно настроить синхронизацию со всех устройств, не надо переживать за безопасность, потому что на сервере уже есть защита, и я полностью управляю своими данными. Одно «но» — для меня это дороговато. Получается, что на средний вариант такого сервера и пары дисков, чтобы настроить рейд-массив, нужна приличная сумма. Плюс по комментариям к статьям понял, что придется заморочиться с установкой Nextcloud на сервер. Не уверен, что хочу ввязываться в такие сложности.
Пока изучал тему, увидел, что есть и другой вариант — более дешевый и вроде такой же простой по установке и настройке. Решил протестировать и рассказать, что же у меня в итоге получилось.
Читать: https://habr.com/ru/companies/cloud_ru/articles/957612/
#ru
@database_design | Другие наши каналы
Привет, Хабр. У меня тут такая история случилась: накопился массив фотографий с путешествий, всяких документов, семейных архивов и учебных материалов по всяких курсам — всего где-то гигов 300. Все важное, ценное, и, конечно, это все очень не хочется потерять.
Я почитал статьи здесь на Хабре, погуглил и понял, что многие покупают себе физические серверы с дисками и на них устраивают хранилища, например, Nextcloud. Звучит удобно: можно настроить синхронизацию со всех устройств, не надо переживать за безопасность, потому что на сервере уже есть защита, и я полностью управляю своими данными. Одно «но» — для меня это дороговато. Получается, что на средний вариант такого сервера и пары дисков, чтобы настроить рейд-массив, нужна приличная сумма. Плюс по комментариям к статьям понял, что придется заморочиться с установкой Nextcloud на сервер. Не уверен, что хочу ввязываться в такие сложности.
Пока изучал тему, увидел, что есть и другой вариант — более дешевый и вроде такой же простой по установке и настройке. Решил протестировать и рассказать, что же у меня в итоге получилось.
Читать: https://habr.com/ru/companies/cloud_ru/articles/957612/
#ru
@database_design | Другие наши каналы
Миграции Postgres с использованием логической репликации
Миграция PostgreSQL — редкий проект, где «быстро и безболезненно» почти никогда не совпадают. Дамп/восстановление годится для сотен гигабайт, потоковая репликация по WAL — для тех, у кого есть к ней доступ. Но когда простоя не хочется, а WAL недоступен, остаётся третий путь — логическая репликация.
В этом материале — практический сценарий: как заранее перенести схему, обеспечить уникальную идентификацию строк (PK/уникальный индекс/
Старт миграции
Читать: https://habr.com/ru/companies/otus/articles/958718/
#ru
@database_design | Другие наши каналы
Миграция PostgreSQL — редкий проект, где «быстро и безболезненно» почти никогда не совпадают. Дамп/восстановление годится для сотен гигабайт, потоковая репликация по WAL — для тех, у кого есть к ней доступ. Но когда простоя не хочется, а WAL недоступен, остаётся третий путь — логическая репликация.
В этом материале — практический сценарий: как заранее перенести схему, обеспечить уникальную идентификацию строк (PK/уникальный индекс/
REPLICA IDENTITY FULL), настроить публикации и подписки, следить за первичной загрузкой через pg_stat_subnoscription, корректно остановить запись на источнике и синхронизировать последовательности.Старт миграции
Читать: https://habr.com/ru/companies/otus/articles/958718/
#ru
@database_design | Другие наши каналы