Базы данных *

Синхронный WAL очень частое явление в базах данных, делая их durability максимальной. При таком исходе каждый батч записи это вызов fsync, и это дало мне 956k opr/s на 16кб значениях , звучит хорошо, но на самом деле: скорость записи упала в 5 раз.

В этой статье я расскажу:

Что такое групповой коммит на пальцах

Почему групповой коммит не для финтеха

Как это реализовано у меня

Как изменились цифры до и после внедрения

Во сколько раз ScoriaDB с group commit быстрее BadgerDB и Pebble.

Если вы пишете хранилище, логгер, кэш или просто любите копаться в LSM‑движках — добро пожаловать на борт, нас ждет короткое путешествие

В предыдущей статье я разобрал что умеет REDB на практике: code-first схемы, LoadAsync без Include, LINQ с оконными функциями, деревья, redb.Route и redb.Tsak. Если не читали — начните с неё, она даёт общую картину.

Теперь начинаю цикл «REDB изнутри» — серия статей про устройство хранилища: как хранятся объекты и свойства, как работают схемы и кэш структур, как LINQ превращается в SQL, как устроены деревья, права, оконные функции. Всё с реальным SQL под капотом.

Первая статья цикла — про саму базу данных. Без понимания схемы таблиц всё остальное будет висеть в воздухе.

Привет, Хабр! Меня зовут Дмитрий Кравчук, я занимаюсь всем, что связано с данными в блоке AI&ML MAGNIT TECH. Расскажу про фундамент прибыльных проектов, которыми мы занимаемся в департаменте. Эта начало цикла статей о наших достижениях за 5 лет и планах на будущее.

В 2020 году мы выбирали формат для больших ML-хранилищ: Delta Lake, Iceberg или Hudi. В итоге остановились на Delta Lake. За 5 лет вокруг него у нас выросла полноценная платформа данных для ML-нагрузок: Spark, Kubernetes, S3, YDB, Airflow, Flink, OpenMetadata, Trino, StarRocks и собственные фреймворки.

Я не буду пересказывать документацию Delta Lake, а расскажу, как это работает у нас в промышленном контуре: доставка данных, слои хранения, оркестрация, хранилище метаданных, lineage, data quality, observability и governance, а также доступ к данным.

Отдельно расскажу, в чём Delta Lake оказался силён, а где пришлось достраивать инфраструктуру: объектное хранилище вместо блочного, координировать коммиты для приближения к ACID, обеспечивать потоковую загрузку, оптимизировать хранение и эксплуатировать большие таблицы.

Материал будет полезен инженерам данных, ML-инженерам, Data scientist’ам, системным аналитикам, MLOps/DataOps/DevOps и всем, кто создаёт промышленную платформу данных под реальные нагрузки.

Здравствуйте, уважаемые читатели Хабра!

В первой части мы рассказали, как решили задачу сегментации полигона дороги в PostGIS. А теперь рассмотрим сопоставление сегментов двух разных версий дороги для сохранения учёта историчности привязанных к ним событий.

Привет, Хаброжители! SQL, «структурированный язык запросов» (Structured Query Language) — это универсальное средство создания, управления и составления запросов к реляционным базам данных, таким как SQL Server, PostgreSQL и Oracle. Для аналитиков данных SQL — суперинструмент, позволяющий выйти за пределы обычных табличных редакторов и систем бизнес-аналитики. При этом язык SQL интуитивен и на удивление прост: немного практики во время чтения книги — и вы уже с легкостью извлекаете данные, перестраиваете таблицы и создаете яркие, наглядные отчеты и презентации!

Всем привет!

Наверняка большинство инженеров, работающих с высоконагруженными системами, слышали о Aerospike.

Для тех, кто всё ещё не знает, что это, приведу короткую цитату из документации:

В этой статье разбираем пять конкретных ошибок при миграции индексов, которые мы совершали сами на реальных проектах. Почему B‑tree не работает в колоночной СУБД? Как правильно спроектировать ORDER BY и PRIMARY KEY? Когда использовать bloom_filter, а когда — материализованные представления?

Если вы работаете с временными рядами в PostgreSQL, скорее всего сталкивались с необходимостью в выгрузке данных в Python, а потом как-то возвращали результат обратно. Это работает, но неудобно и медленно. Я написала расширение pg_stl, которое позволяет делать всё это прямо внутри базы — на нативном C, без экспорта данных наружу.

В этой статье расскажу, что это такое, как работает и почему это быстрее, чем подход с Python.

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

Такая архитектура усложняет работу с клиентским профилем. У бизнеса нет единой истории взаимодействия с гостем, менеджеры работают с фрагментами данных, а сервис, маркетинг и аналитика опираются на неполную картину. Для ресторанной сети это напрямую влияет на персонализацию, качество обслуживания, LTV и повторные визиты.

В проекте для сети из 10 ресторанов была реализована единая база данных гостей. Задача системы — собрать в одном профиле все взаимодействия клиента с бизнесом: от первого контакта и переписки до бронирований, чеков, отзывов, оплат, технических инцидентов и повторных визитов.

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

Manticore Search поддерживает это из коробки. Внутри используется структура данных HNSW: граф, который соединяет близкие векторы и позволяет быстро находить ближайших соседей без сканирования каждого документа. Благодаря этому векторный поиск по миллионам документов выполняется за миллисекунды.

Типизированное хранилище для .NET поверх Postgres и MSSQL. C#-класс как схема — без миграций, без Include, с полным LINQ. Работает в проде.

В PostgreSQL процесс получения журналов walreceiver запускается на реплике только после того, как процесс startup применит все накопившиеся WAL. Это не создаёт особых проблем, если процесс startup успевает накатывать полученные журналы. Проблема проявляется, если используется реплика с отложенным применением журнальных записей, например, на сутки. Реплика не будет получать журналы сутки, слот репликации будет их удерживать на мастере.

Если процесс walreceiver остановится, то он не запустится до тех пор, пока не пройдёт время задержки, установленное параметром recovery_min_apply_delay. Команд ручного запуска процесса walreceiver нет. Получится, что сутки мастер копит журналы, только потом запускается walreceiver и начинает вытягивать журнальные файлы. Такое поведение нелогично, но его задокументировали: "When the standby is started and primary_conninfo is set correctly, the standby will connect to the primary after replaying all WAL files available in the archive. If the connection is established successfully, you will see a walreceiver in the standby, and a corresponding walsender process in the primary."

Всё время, до запуска walreceiver, слот репликации на мастере удерживает файлы журналов. На мастере скопится много журналов и, если не хватит места, то экземпляр мастера подвиснет по нехватке места в директории pg_wal (или слот инвалидируется по параметру max_slot_wal_keep_size и реплику придётся пересоздать).

Классическая проблема аналитических систем: кластер СУБД сайзится под пик, а 28 дней в месяц он задействован чуть больше чем наполовину. StarRocks (shared-data) и автоскейл Kubernetes убирают этот избыток. Compute добавляется под нагрузку и сворачивается на спаде. Внутри легкая пятничная статья: как это работает и где у эластичности потолок.

Если агент уже ходит в инструменты, читает документы, меняет состояние системы и принимает часть решений сам, проверка одного промпта почти ничего не говорит о надежности. Нужно смотреть на весь путь: вход, найденный контекст, вызовы инструментов, промежуточные состояния, итоговый ответ и побочные эффекты. Ниже - рабочая схема, как строить такие проверки до релиза и после выхода в прод.

Привет, Хабр! На связи системный аналитик Илья Глазунов и разработчик Захар Корсаков. Мы работаем с платформой карточного хранилища Т-Банка.

Когда данных становится много, а архитектура обязана оставаться простой, классические решения начинают упираться в ограничения стека. В нашем случае нужно было организовать асинхронную доставку событий из Cassandra, но без CDC, без отдельного брокера и без разрастания зоопарка технологий. Так мы пришли к Non-transactional Outbox — схеме, которая по духу напоминает Kafka Inside the Database, но живет в рамках наших ограничений и требований к отказоустойчивости.

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

Здравствуйте, уважаемые читатели Хабра!

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

Когда я начал поднимать PostgreSQL через Docker для своих проектов, всё выглядело просто: описал сервис в docker-compose.yml, запустил контейнер - база доступна.

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

Если вы делаете RAG (Retrieval-Augmented Generation) на .NET, то рано или поздно упираетесь в вопрос: куда складывать эмбеддинги и как быстро искать по ним.

Существующие варианты делятся на два лагеря.

Внешние сервисы (Pinecone, Qdrant, Weaviate) — хороши, но требуют отдельной инфраструктуры. Сеть, авторизация, сериализация, мониторинг. Каждый запрос — это миллисекунды на HTTP. Плюс вы привязываетесь к конкретному облачному провайдеру или контейнеру.

Существующие .NET-решения — часто либо заброшены, либо имеют проблемы с производительностью (избыточные аллокации, медленный ANN, отсутствие гибридного поиска).

Но есть и третий путь: встраиваемая (embedded) векторная БД, которая работает прямо внутри вашего процесса. Никакой сети. Никакого внешнего сервиса. Только ваш код и процессор.

Меня зовут Евгений Ефимкин, я руковожу группой Platform Reliability в Yandex Cloud. В числе прочего мы занимаемся безопасностью наших managed‑сервисов.

В managed PostgreSQL мы не выдаём клиенту привилегии superuser — иначе он сможет выйти за пределы своей базы прямо в операционную систему. Чтобы клиент при этом мог выполнять привилегированные операции: создавать базы, заводить роли, менять настройки кластера, — мы пишем сервисы Control Plane и выдаём специальные ограниченные роли (без выхода в ОС и без обхода проверок прав).

Несколько лет назад, занимаясь поддержкой логической репликации, я понял, что и этого мало: у PostgreSQL остаются места, где он сам, изнутри, выполняет код от superuser в обход всей конструкции. Дальше — два случая повышения привилегий у двух разных публичных облачных провайдеров. Оба вектора к моменту публикации закрыты — и в апстриме PostgreSQL, и у самих сервисов; оба провайдера своевременно проинформированы.

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

Основная задача проекта — заменить разрозненные FAQ, Wiki, документы и чаты единым интерфейсом доступа к корпоративным знаниям. Сотрудник может задать вопрос в свободной форме и получить ответ с учётом своей должности, прав доступа и актуальной версии документа.