Общеизвестным является тезис о том, что от избыточного индексирования страдают только DML-операции, а SELECTы только получают разнообразные бенефиты.
Однако существуют определённые нюансы, которые могут разрушить данную стройную картину мира.
Я попробую продемонстрировать возможную проблему на тестовом примере (кстати, почти аналогичная проблема наблюдалась в реальной ПРОМ-системе).
Привет, сообществу Habr!
Хочу поделиться опытом с коллегами - как мы решили одну из наболевших проблем нашей команды разработки – отсутствие полноты данных для тестирования реализованного функционала в условиях ограниченного доступа к реальным данным компании. Если вы работаете с персональными данными, то наверняка сталкивались с такой проблемой.
Наша команда Neoflex работает на проектах заказчика. При старте работ мы всегда подписываем NDA, но все равно этого недостаточно, чтобы владелец доверил нам полный доступ к промышленным данным. Мы его прекрасно понимаем: данные - основа благополучия компании и видеть их должен ограниченный круг лиц, отвечающий за бизнес-результат.
Чтобы удовлетворить ожидания заказчика, выполнить вверенную нам работу и достичь высоких результатов при разработке функционала, нам нужны данные для тестирования, близкие к реальным. Тут возникает сложность – на тестовом контуре либо небольшой срез не консистентных промышленных данных, на которых нельзя протестировать полноценно функционал (например, витрину по операциям определенного сегмента клиентов с глубиной месяц, квартал), либо мы начинаем генерировать синтетику, не всегда попадая в нюансы вариативности данных, тратя на это дополнительные ресурсы.
Периодически наши члены команды на ретроспективе, разбирая проблемный кейс, обсуждали свою боль – нужен тестовый контур для тестирования с достаточным количеством данных, близких к бизнесовым, обновляемый по расписанию - иначе мы можем выкатить на прод слабо оттестированный функционал.
Многие проекты рано или поздно утыкаются в «потолок» стандартного поиска. Обычный LIKE перестает справляться, когда данных становится больше 100 тысяч строк, а пользователи начинают ошибаться в каждом втором слове. Типовым решением в такой ситуации считается внедрение Elasticsearch или Meilisearch.
Но внешние движки — это всегда «налог» на инфраструктуру: лишняя память, задержки на сетевой хоп и, самое главное, головная боль с синхронизацией данных. В этой статье мы разберем, как выжать из PostgreSQL производительность специализированного поисковика, используя Node.js как оркестратор параллельных стратегий и механизм AbortSignal для предотвращения лишней нагрузки на БД. Разбираем внутреннее устройство SDK pg-smart-search.
Шестая статья цикла о построении CDC-пайплайна с нуля. Данные уже текут из PostgreSQL в Kafka, но дальше просто исчезают по retention. Сегодня пишем Consumer на Python, реализуем криптографическую верификацию сообщений и строим трёхслойную архитектуру данных.
Рассказываю историю создания Mumin API — современной Open Source платформы для работы с хадисами. Внутри: битва с «кривыми» PDF-сканами через регулярки Python, ускорение Fuzzy Search в PostgreSQL почти в 2 раза с помощью GIN-индексов, публикация Kotlin SDK в Maven Central и опыт работы с AI как с Senior-напарником. Без «воды», только код, архитектура и реальные грабли 16-летнего разработчика
09:12 — db-replica-02 connection timeout
HTTP 5xx = 0.2%
HAProxy зелёный
p50 = 38-42ms
Replica в другой стойке недоступна
Отказоустойчивость потеряна
Инцидент не объявлен
Всем привет, меня зовут Илья Шишков, я пишу на С++ с 2006 года. Много лет я был разработчиком в больших C++-кодовых базах, но в 2024 году жизнь меня занесла в PostgreSQL. А именно в RnD-разработку СУБД Pangolin, это реляционная СУБД от СберТеха, PostgreSQL с нашими доработками под требования к усиленной безопасности, производительности и так далее. PostgreSQL, как известно, написан на чистом С. Так я поработал с этим языком несколько месяцев и… стал внедрять C++.
В этой статье я расскажу, зачем так сделал и почему это оказалось очень удобно. Например, некоторые технологии из C++ есть в PostgreSQL, при том, что их нет в C. Разберу практические примеры, как мне кажется, хороших абстракций на C++, которые упрощают программирование на C. И немного времени уделю разбору цены, которую нам приходится платить, когда мы используем в коде различные абстракции.
Кажется, что в ИТ всё меняется каждые пару лет. Фреймворки рождаются и умирают, архитектурные подходы сменяют друг друга, но SQL стабильно остается на месте. Он спокойно пережил хайп вокруг NoSQL, эпоху Big Data и повсеместное внедрение нейросетей.
Сегодня SQL давно перестал быть узким «языком админов». Это универсальный стандарт общения с данными, который жизненно необходим бэкендерам, аналитикам, QA-инженерам и даже продакт-менеджерам.
В этой статье мы пропустим скучную академическую теорию и разберем только то, что реально нужно в работе. Мы пройдем путь от анатомии таблиц и базовых джоинов до оконных функций. А в конце заглянем под капот базы данных и разберем логический порядок выполнения запроса — секретный ингредиент, который навсегда избавит вас от вопроса: «Почему эта строчка не работает?!».
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Традиционный DBA-анализ часто субъективен и опирается на опыт конкретного специалиста. PG_EXPECTO предлагает другой метод : автоматизация сбора и обработки статистики с помощью PG_EXPECTO v.7 и формирование выводов нейросети DeepSeek.
PG_EXPECTO рассчитал граничные значения и метрики ВКО, отсеяв незначимые события. DeepSeek, получив эти «чистые» данные, провел сравнительный анализ экспериментов , указав на скрытые доминанты и системные паттерны.
Клиент, с проблемы которого всё началось, решил её сам — сменил фреймворк и даже не стал дожидаться патча. Но Алёна Рыбакина всё равно продолжила работу — ещё год. Теперь её OR-ANY Transformation — часть PostgreSQL, а сама она — обладательница медали сообщества. Интервью о том, как случайный клиентский баг превращается в вклад в мировой open source.
Начать работу с массивами в PostgreSQL проще простого: объявили колонку как integer[], вставили значения — и готово. Или вообще собрали массив на лету.
Официальная документация дает неплохую базу. Но за этим простым интерфейсом скрывается куда более сложная механика, чем многие привыкли думать. Массивы в PostgreSQL — это не просто «списки, которые можно засунуть в поле таблицы». У них своя стратегия работы с памятью, собственная логика индексации и целый ворох граничных случаев.
В статье подробно разберем аспекты работы с массивами, которые могут неожиданно создать проблемы в продакшене.
Пятая статья цикла о построении CDC-пайплайна с нуля. HDFS и Hive работают, но управлять ими через консоль неудобно. Сегодня поднимаем веб-интерфейс Hue и разбираемся, почему в 2026 году сборка из исходников требует Python 2.7.
Вспомните, как вы онбордили аналитика: показывали данные, примеры рабочих SQL, неочевидные легаси и костыли — и через какое-то время он начинал перформить самостоятельно.
Чтобы научить AI-агента — нужно пройти ровно те же шаги, только вместо недель, на обучения потратятся часы, а в результате большая часть рутины аналитика будет автоматизирована.
В этой статье я расскажу, как я автоматизировал свой анализ данных, и дам пошаговую инструкцию, которую вы с легкостью сможете повторить это у себя в проекте.
Статья будет полезна как предпринимателям, которые хотят оптимизировать процессы, так и аналитикам, которые хотят прокачать себя. Погнали!
pgAdmin4 - де-факто стандартный GUI для PostgreSQL.
И при этом на Arch Linux его Desktop-версия годами находится в полурабочем состоянии.
Я разобрался, почему pgAdmin4 так плохо ложится на Arch, какие подходы стабильно ломаются,
и какой компромиссный, но реально рабочий вариант в итоге получился.
Если вам тоже надоело чинить pgAdmin после каждого обновления Python или Electron - это для вас.
Каждый, кто хоть раз разбирался в три часа ночи с упавшим продом, знает: большинство катастроф в базах данных это не сбой железа и не космические лучи. Это решения, принятые на этапе проектирования схемы. «Потом поправим», «в приложении проверим», «а зачем тут индекс?» каждая из этих фраз обходилась командам в часы даунтайма и миллионы потерянных строк.
Ниже 25 правил, которые я собрал из опыта работы с высоконагруженными системами. Это не теория из учебника — это грабли, на которые уже наступили до вас. Каждое правило сопровождается примером «как надо» и «как не надо», чтобы разница была наглядной.
Контейнеры давно стали стандартом современной разработки. Согласно отчету Docker State of Application Development 2025, они используются примерно в 92% IT-организаций и фактически стали универсальным способом упаковки и запуска приложений независимо от платформы и окружения. Это тот случай, когда инфраструктура перестает мешать и начинает экономить время.
Именно поэтому Digital Q.DataBase доступна, в том числе, в виде Docker-образа. Это позволяет за несколько минут попробовать Oracle- и MS SQL-совместимую СУБД на Windows, Linux и macOS, ограничившись несколькими командами, без сложной установки и длительного онбординга. Полноценная рабочая среда готова к использованию сразу после старта контейнера.
По сути, после того как вы скачали архив и подготовили директорию, для запуска Digital Q.DataBase достаточно четырех команд.
Здравствуйте, уважаемые читатели Хабра!
Это вторая часть (первая здесь) о создании основного функционала MVP (Minimum Value Product) системы по управлению цифровыми активами для базы данных PostGIS.
В этой публикации рассмотрим применение классического, полнотекстового и семантического поиска текста в PostgreSQL.
Разбираем на практике, как гарантировать доставку сообщений в Kafka/RabbitMQ без распределенных транзакций, используя паттерн Transactional Outbox.
В этой статье рассмотрим наиболее полную реализацию паттерна Transactional Outbox, которую можно будет легко расширять и применять в продакшне. Данная статья будет полезна как для разработчиков, которые еще не встречались с данным паттерном, так и тем, кто уже применял его в своей работе.
Традиционный подход к диагностике производительности PostgreSQL зачастую опирается на эвристики, «типовые чек‑листы» и интуицию администратора. Администратор видит всплеск ожиданий, находит самый массовый тип события и принимает решение: «увеличить shared_buffers» или «выключить параллельные запросы». Такой метод работает в очевидных случаях, но оказывается бессилен, когда система находится в состоянии сложного баланса между разными механизмами, а первопричина торможения скрыта за вторичными эффектами.
Статистический подход, реализованный в методике pg_expecto, принципиально меняет логику расследования. Вместо субъективного выбора «самого громкого» типа ожиданий во главу угла ставятся количественные критерии, основанные на реальном поведении системы во времени.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
