Базы данных *

Система управления базами данных — крайне сложный программный продукт, и рассказ о его архитектуре потянет на целый увесистый том. А поскольку заголовок обещает нам не просто «архитектуру», а даже «эволюцию архитектуры», сегодня остановимся на одном из компонентов, ключевом с точки зрения производительности, — системе хранения данных. А заодно посмотрим, каково место самых современных систем на рынке и почему оно такое.

Привет, Хабр! Я Владимир Комаров — программист, администратор, архитектор данных и инфраструктуры, преподаватель и автор. В этой статье по мотивам моего доклада на Highload++ мы посмотрим, как развивались системы управления базами данных: с чего всё начиналось, как система хранения данных СУБД эволюционировала, и в каком состоянии эта область находится сейчас. А заодно узнаем, существует ли идеальная СУБД, и если нет, то как приблизиться к идеалу.

Помню тот момент, когда я в очередной раз пытался вытащить конкретную спецификацию из стопки 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.

В статье рассматривается создание кластера Patroni последней версии 4.0.7 и etcd 3.6.5 в контейнерах docker. Приводится пример, когда Patroni не может автоматически восстановить и запустить кластер PostgreSQL. 

Patroni в докере

Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.

Как поддерживать свыше 2300 кластеров MySQL без заметных простоев? В Uber это решают разделением на плоскости данных, управления и обнаружения и строгим приведением фактического состояния к desired state. В материале — анатомия control plane (Odin, Cadence, контроллер с правилами), как устроены плавные и аварийные переключения primary, замена узлов и онлайн-изменения схемы; как discovery на etcd и реверс-прокси даёт стабильный VIP; как наблюдаемость, CDC (Storagetapper→Kafka→Hive) и бэкапы закрывают эксплуатацию. ФВ фокусе — инженерные решения, которые позволяют удерживать 99,99% доступности без ручной магии.

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

1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

В этой части мы возьмём простой советский...

Привет, Хабр! С вами Александр Константинов, технический эксперт по облачным технологиям из Cloud.ru. Сегодня хочу показать вам наглядно, как можно оптимизировать производительность веб-приложения. Рассмотрим это на усредненном примере кейса, который типичен для многих наших клиентов, пройдем весь путь настройки, выполним нагрузочное тестирование и сравним до/после.

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

Привет, Хабр! Хочу поделиться историей о том, как столкнулся с проблемой, возможно знакомой многим разработчикам: необходимость внедрить систему рекомендаций в проект, который все еще работает на старой версии php.

Обновление версии php в legacy-проекте — это часто настоящий квест. То времени нет, то бизнес-фичи надо пилить, то еще какие-то причины. И часто бывает, что обновление версии php в командах откладывается на потом.

Данные без информации — это просто цифры. Чтобы они «заговорили», их нужно извлечь и преобразовать. Для этого существуют ETL‑системы, а для анализа данных и визуализации — BI и Data Science.

Сегодня бизнес выбирает между тремя классами ETL-решений...

150 млн чтений в секунду — итог скрупулёзной инженерии кэша. В этом кейсе Uber — как ужесточить консистентность без удушения записи: инвалидация «по пути записи» из слоя запросов, дедупликация по commit-timestamp из БД, сочетание TTL и CDC на бинлогах, плюс измерение «черствости» через Cache Inspector. Разобраны реальные источники stale-данных (лаг CDC, реплики, негативное кэширование) и компромиссы вроде read-your-writes — с практическими схемами, которые масштабируются до сотен миллионов RPS.

Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается не в том, чтобы синхронизировать состояние удалённо по сети, а в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.

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

В статье я расскажу о практических кейсах и сложностях, возникающих (и возникавших) в процессе миграции данных между СУБД (Oracle -> Postgres), а также о собственном инструменте миграции данных, который вы также можете попробовать.

Недавно рассказывал про мониторинг истории активных сессий в базах данных Oracle, PostgreSQL, ClickHouse и MS SQL Server с использованием desktop-приложения Dimension-UI (link). В комментариях @KPSB92 задал вопрос о преимуществах/отличиях связки exporter Prometheus/Grafana и Dimension-UI, решил оформить ответ в эту небольшую статью.

Итак, возьмем для примера просмотр данных активных сессий в базе данных PostgreSQL и сравним визуализацию в Grafana и Dimension-UI. Посмотрим работу с интерфейсами обоих систем в динамике с помощью скринкастов.

... писать без транзакций?
... сохранять без кворума?
... стирать прод без бэкапов?
... сливать базу самому?

И всё это безопасно, надёжно, доступно!

Приветствуем, коллеги. На связи Олег Сивченко @OlegSivchenko.

Уместен и закономерен ваш интерес, как мы обзаводимся правами на перевод зарубежных книг и где берём новинки. Такой вопрос задал нам читатель @PopovGP. Действительно, книгоиздательская отрасль не один год приспосабливалась к современным реалиям, но один интересный новый тренд действительно стоит раскрыть подробнее: мы стали активнее искать и рассматривать небольшие издательства, настроенные на сотрудничество. Так, уважаемый коллега @Holmogorov завершил длительный поиск базовой книги по Jetpack Compose, найдя в небольшом американском издательстве «Payload Publishing» отличный труд Нила Смита «Основы JetPack Compose: Разработка приложений для Android с помощью Jetpack Compose, Android Studio и Kotlin». Эта книга вышла в августе.

О другой очень похожей находке я хочу рассказать вам сегодня. Это совсем свежая новинка «Программирование бэкенда на Python. Практическое руководство» под авторством Тима Питерса. Обнаружили мы её в каталоге маленького индийского издательства «GitForGits».

Я прочитал статью, и меня поразило, сколько сомнительных решений можно использовать для одной простой задачи.

В этой статье я расскажу, как правильно создать сервис для конкурентных обновлений остатков данных в базе данных. Буду использовать .NET, C#, Entity Framework и PostgreSql.

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

Все существующие языки предназначены для уменьшения цифровой энтропии и оснащены инструментами для уборки цифрового навоза (кроме брейнфака, пожалуй). В том числе и инструментами для сбора в кучу разрозненных полей, да ещё и с возможностью как-то назвать эту структуру. В ООП языках это вообще часть парадигмы с далеко идущими последствиями, можно сказать, это у них в крови. А ООП языков, работающих между БД и экраном пользователя, осмелюсь предположить, большинство. Естественно, у разработчика возникает сразу желание воспользоваться структурными инструментами языка, чтобы утрамбовать поля таблицы в класс. Вот так и появляются дтошечки, энтитички, поджошечки и прочие попочки.

И вроде не велика проблема - делаем структуру в нашем любимом языке, такую же, как в БД и из наших кубиков складывается слово "счастье". Складываться-то оно складывается, но ненадолго. Очень быстро структура БД и структура в коде начинают разъезжаться. А если не начинают, то потыкайте в свой проект палочкой - скорее всего он уже умер. Как говорится "не щебечет дохлый щегол, а мёртвый проект не меняет свою структуру". Ну и далее по тексту...

Здравствуйте. Меня зовут Олег Юрченко. Расскажу о своём опыте создания хранилища данных для отчётов с синхронизацией близкой реальному времени.

В мире, где абстракции правят бал, а скорость важнее эффективности, говорить о C — значит идти против течения. Для многих это «устаревший» язык с ручным управлением памятью и «опасными» указателями. Но что, если именно эти его особенности — не минусы, а ключи к системному программированию, где нет права на ошибку? Программистом Postgres Professional с 22-летним стажем Максим Орлов убеждён, что C — не про мгновенный дофамин и быстрые прототипы, а про суть, контроль и философское понимание того, как действительно работает железо. Погрузитесь в историю любви к C, которая началась с раздражения на Pascal, и узнайте, почему этот «бастион спокойствия» актуален и сегодня.

Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:

«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.

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

Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.

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

И если Opera Unite так и не обрела полноценную жизнь, на предложенную Тимом спецификацию обратили пристальное внимание через несколько лет, когда сменившие один другой кризисы конфиденциальности явно указали на необходимость повышения степени независимости и контроля со стороны пользователей в веб-среде.

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.