«Как ускорить выполнение запросов к базам данных?» — извечный вопрос админов и пользователей. Казалось бы, раньше всё работало неплохо, но стоило клиентской базе вырасти в пять раз, как всё замедлилось. Знакомая ситуация? В этой статье расскажем, как найти запросы, которые можно ускорить, и оптимизировать их.
Статья подготовлена по материалам выступления на конференции PGCONF.СПБ 2024.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В этой части рассмотрим некоторые "грабли", на которые можно наступить, реализуя рекурсивные алгоритмы на SQL... Которые иногда можно сделать вовсе нерекурсивными, ускоряя запрос в десятки раз!
Как сравнить? - измерить execution-time конечно! - скажет опытный читатель. И будет совершенно прав: с практической точки зрения эффективнее та СУБД, которая выдаёт больший TPS. Однако иногда нам требуется спроектировать систему, которой ещё нет или сделать прогноз поведения на нагрузках, которые ещё не пришли. В таком случае нам нужна некоторая характеристика, позволяющая выполнить качественный анализ плана или выполнить сравнение пары планов. Обсуждению одной такой характеристики - количество прочитанных страниц данных - и посвящён данный пост.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В этой части воспользуемся возможностями линейной генерации и подсчета уникальных значений.
Безумные штуки иногда можно найти в интернете. Листая 2024 JavaScript rising stars (https://risingstars.js.org/2024/en#section-all) обнаружил там удивительного зверя - Postgres скомпилированный через emcc в WASM версию, и допиленный до состояния, когда его можно запустить внутри JS-процесса (браузер/Node.js/Bun/etc).
Как он устроен, как им пользоваться, и, самое главное, зачем? Добро пожаловать под кат :)
Хочу поделиться решением проблемы «duplicate key value violates unique constraint "pg_class_relname_nsp_index"» в PostgreSQL, с которой я столкнулся при добавлении новых секций в секционированные таблицы, с использованием распараллеливания.
У вас есть Postgres, где хранится множество текстовых данных. Вы хотите использовать векторные представления (embeddings), к примеру, от OpenAI/Anthropic, чтобы построить систему рекомендаций, улучшенный поиск или реализовать RAG для работы с LLM. Но при этом ставить расширения (extensions) не хочется, а может, и вовсе нельзя — например, в облачных Managed PostgreSQL зачастую нет нужных прав.
Под катом описание open-source решения pg_auto_embeddings, которое вам поможет.
Переезд с Microsoft на Linux - это то, с чем сталкивается последнее время практически каждый инженер, и меня сия чаша тоже не миновала. Но за годы работы с MS я привык раздавать права на все что угодно через группы в AD и отказываться от этого совершенно не хотелось.
Запросы к вендеру, поиск инструкций в интернете не принес желаемого результата и как обычно в опенсорсе пришлось разбираться самому как реализовать свою хотелку.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В сегодняшней статье посмотрим, как можно использовать рекурсию для перебора комбинаций.
Казалось бы если ФИАС содержит эти данные, то просто выгрузи их ? Но не тут то было, дело в том что почтовые индексы есть у домов, но почтовых индексов нет у населённых пунктов, при этом населённые пункты через произвольное количество своёв "абстракции" связаны с домами. Эта связь записана в таблицу ADM_HIERARCHY - группировка по административному делению.
Собственно задача состоит в том что бы сгруппировать почтовые индексы всех домов и взять минимальный индекс как индекс собственно населённого пункта (индекс населённого пункта обычно заканчивается нолями, у "подчинённых" почтовых отделений индексы заканчиваются цифрами от 1 до 9).
Но прежде чем начать работать с данными, надо к этим данным получить доступ, разместить эти данные там где к ним можно будет выполнять запросы.
О том как это сделать и решить проблему с выборкой будет эта статья-инструкция.
Рив Гош – это одна из крупнейших розничных сетей косметики и парфюмерии. Мы представлены в нескольких каналах продаж: офлайн-магазины, собственный интернет-магазин и все ведущие маркетплейсы.
Каждый канал продаж индивидуален, но все они требуют онлайн информацию об остатках: В офлайн-магазине на кассе мы предлагаем клиенту товар по акции. Причем предлагаем только товар, аналогичный выбранному клиентом, который есть в остатках этой локации. В собственном интернет-магазине есть опция получения товара в магазине сети Ривгош или заказать экспресс-доставку из магазина. Маркетплейсам вообще нужна максимально актуальная информация об остатках – любой отказ от заказа клиента влечет штрафы и снижение рейтинга.
Откуда же эту информацию мы можем выдать? Достоверная оперативная информация о товарных остатках в Рив Гош распределена по разным OLTP системам: часть магазинов в современной централизованной 1С ERP управление холдингом, остальные магазины – в специализированных базах Oracle, распределительные центры – в 1С УПП. Единого оперативного хранилища нет.
Чтобы централизованно выдать остатки, шине данных приходилось последовательно пробегаться по базам данных всех магазинов, агрегировать их и консолидировано выдавать их внешним потребителям этих данных. Магазинов много, и на их последовательно-параллельную обработку уходило порядка 3х часов. Такая задержка с обновлением остатков вызывала много ложных заказов: клиент заказывает товар, товаровед идет его собирать с полок магазина и не находит. Клиент получает отказ, а значит мы теряем рейтинг на маркетплейсах и клиентскую удовлетворенность. Надо было что-то делать.
В рамках данной темы будут рассмотрены способы оптимизации запросов в DjangoORM. Основное внимание будет уделено использованию сырых SQL запросов, существующих для этого инструментов, преимуществам и недостаткам.
С 2019 года я занимаюсь разработкой open source инструмента под названием pg-index-health, который позволяет анализировать структуру БД и находить потенциальные проблемы.
Все эти годы pg-index-health эволюционировал и развивался. За 2024 год мне при поддержке нескольких контрибьюторов удалось решить большинство остававшихся «детских болячек» и довести проект до состояния, когда он готов к масштабной экспансии.
В этой статье я хочу подробно рассказать об идеях, которые стоят за этим инструментом, и как его использовать в ваших проектах.
На основе статьи Arpendu Kumar Garai "Demystifying Transactions and Exceptions with Spring", от 31 января 2023 года.
Spring Framework обеспечивает обширную поддержку транзакций. Но прежде чем мы углубимся в концепции управления транзакциями, давайте разберемся с основной концепцией транзакции.
Транзакция базы данных (СУБД) — это серия из одной или нескольких операций, выполняемых как единая атомарная единица работы. Это означает, что либо все операции в транзакции завершаются успешно, либо ни одна из них не применяется к базе данных. Транзакция может состоять из одной команды, группы команд или любых других действий с базой данных. Любая СУБД, поддерживающая транзакции, должна гарантировать качество ACID для сохранения целостности данных.
ACID (от англ. atomicity, consistency, isolation, durability) — набор требований к транзакционной системе, обеспечивающий наиболее надёжную и предсказуемую её работу.
Основные требования:
Выбор SQL-запроса в реляционной СУБД в основном определяется пространством поиска возможных планов и техниками поиска плана в этом пространстве. У каждой СУБД оба этих фактора имеют свои особенности, что объясняет, почему иногда при миграции с одной СУБД на другую можно наблюдать как ускорения, так и провалы во времени выполнения отдельных запросов.
Здесь я привожу четыре случая, когда SQL Server позволяет строить планы запросов значительно более оптимальные, нежели это доступно PostgreSQL используя как более широкое пространство возможных планов, так и более совершенные методы оценок эффективности планов. Эти примеры: использование тредов, расширенная статистика, кэширование промежуточных результатов запроса и внутренняя параметризация. Примеры независимы и все кроме первого содержат скрипт воспроизведения - можно сразу листать на ту часть, которая выглядит интереснее.
Полагаю, знание о таких кейсах может быть полезным. Как минимум уменьшит количество стресса при миграции на PostgreSQL и возможно заинтересует кого-то настолько, чтобы начать свой проект в open-source сообществе разработчиков СУБД.
NestJS — это прогрессивный фреймворк для построения эффективных и масштабируемых серверных приложений на Node.js. Он использует современные возможности JavaScript и TypeScript, вдохновлен архитектурными паттернами Angular и поддерживает модульность, инъекцию зависимостей и другие современные подходы.
TypeORM — это ORM (Object-Relational Mapping) инструмент, который позволяет взаимодействовать с базами данных, используя объекты и классы, что упрощает разработку и поддерживает различные СУБД, такие как PostgreSQL, MySQL, SQLite и другие.
Сочетание NestJS и TypeORM предоставляет мощный инструментарий для разработки REST API, обеспечивая высокую производительность, модульность и удобство поддержки кода.
Badass Elephant
Из январского номера мы узнаём, что Тембо - имя лихого слоника из игры Tembo the Badass Elephant. Основатель и гендир Рай Уокер (Ry Walker) объявил о доступности Tembo Cloud, а в начале января взяли на работу Дэвида Уилера (David E. Wheeler) - основателя PGXN (PostgreSQL Extension Network). Компания | кампания настолько активная и шумная (в маркетинговом смысле), что кажется: они существуют уже ... годы во всяком случае, не год с небольшим.
PG-футурология
Thoughts on PostgreSQL in 2024
В своём блоге Джонатан Кац говорит, что хотел совсем чуть-чуть попредсказывать, но увлёкся - получилась немаленькая статья. Год назад это было интересно потому, что это было тогда. А сейчас это интересно потому, что это было ... тогда, то есть год назад. Начинал он с логической репликации - ну да, здесь всё успешно развивается. А вот тема HA (High Availability) актуальна в не меньшей степени, но напомним статейку из декабрьского, свежайшего Postgresso: PG Phriday: Kubernetes Killed the High Availability Star.
Под занавес уходящего года предлагаю традиционно вспомнить, про какие интересные возможности и особенности работы с PostgreSQL мы рассказали в нашем блоге.
Если не видели дайджест за прошлый год — время наверстать упущенное!
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В этой части научимся применять разные условия в зависимости от состояния рекурсивного "цикла" и отлавливать его "зацикливание".
Утро, аромат свежесваренного кофе, и телефон тихонько напоминает вам о приеме важного лекарства. «Привет! Не забудь принять лекарство!» Такую систему можно реализовать самостоятельно с помощью Golang и Exolve API.
В этой статье я покажу, как клиники и медцентры могут построить надежную систему SMS-напоминаний.
