Как стать автором
Обновить
178.86

PostgreSQL *

Свободная объектно-реляционная СУБД

Сначала показывать
Порог рейтинга
Уровень сложности

PostgreSQL Antipatterns: скованные одной цепью EXISTS

Время на прочтение2 мин
Количество просмотров8K
Я уже как-то рассказывал про особенности вычисления условий в SQL вообще и в PostgreSQL, в частности. Сегодня продолжим тему и попробуем написать и пооптимизировать простой запрос — у кого из сотрудников есть на выполнении «суперприоритетные» задачи.

CREATE TABLE task AS
SELECT
  id
, (random() * 100)::integer person -- всего 100 сотрудников
, least(trunc(-ln(random()) / ln(2)), 10)::integer priority -- каждый следующий приоритет в 2 раза менее вероятен
FROM
  generate_series(1, 1e5) id; -- 100K задач
CREATE INDEX ON task(person, priority);

Слово «есть» в SQL превращается в EXISTS — вот с самого простого варианта и начнем:

SELECT
  *
FROM
  generate_series(0, 99) pid
WHERE
  EXISTS(
    SELECT
      NULL
    FROM
      task
    WHERE
      person = pid AND
      priority = 10
  );


все картинки планов кликабельны

Пока все выглядит неплохо, но…
Читать дальше →

varchar2 и Unicode для тех, кто ничего не понимает в базах данных Oracle или ORA-12899: value too large for column

Время на прочтение3 мин
Количество просмотров17K

Так случилось, что продукт, который мы разрабатываем работает с несколькими реляционными базами данных. Сейчас это MS SQL, Postgres и Oracle. Были запуски под много чем от MySQL до покойного, наверное, Firebird и экзотических Sybase с DB2, но сказ не об этом.

Если с MS SQL и Postgres все более мене понятное-привычное, то с Oracle каждый раз нас ждут какие-то сюрпризы. Проницательный читатель сразу заметит, что "руки у нас кривые" и мы "попросту не умеем его готовить", но если, уважаемому читателю захочется узнать чем varchar (а точнее varchar2) в Богоподобном Oracle отличается от его собратьев, то прошу под кат.

Читать далее

One Tool to Analyze Them All

Время на прочтение1 мин
Количество просмотров3.3K
Мы рады сообщить о реализации на explain.tensor.ru базовой поддержки анализа и визуализации планов, специфичных для PostgreSQL-совместимых решений: Timescale, Citus, Greenplum и Redshift.


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

EXPLAIN <-> SQL


В развитие темы сопоставления узлов плана и запроса добавлена возможность быстрого просмотра и переключения между ними:


Читать дальше →

Настройка пользователей только для чтения в PostgreSQL

Время на прочтение4 мин
Количество просмотров23K

В этой инструкции показывается как настроить пользователей только для чтения в PostgreSQL для Redash.

Читать дальше →

Patroni и stolon инсталляция и отработка падений. Максим Милютин

Время на прочтение32 мин
Количество просмотров20K


Patroni и Stolon — два наиболее известных и продвинутых решения для оркестрации PostgreSQL и обеспечения высокой доступности (автофейловера) кластеров Leader-Followers конфигурации. Однако инженеры, переходящие со старых проверенных решений (Corosync&Pacemaker) и встроенных из других СУБД, сталкиваются со сложностями в инсталляции этих инструментов и непониманием ролей каждого из компонентов. В данном мастер-классе будет рассмотрен типичный процесс инсталляции кластеров Patroni и Stolon на виртуальных машинах (не в контейнерах), а также разобрано поведение этих кластеров при различных фейлах в инфраструктуре. Весь процесс будет демонстрироваться на трёх виртуальных машинах под управлением vagrant с использованием предварительно подготовленных образов. При желании слушатель может следовать за процессом, предварительно подготовив своё окружение.

Читать дальше →

PostgreSQL в «Тензоре» — публикации за год

Время на прочтение16 мин
Количество просмотров6.4K
Ровно год назад с рассказа о нашем сервисе визуализации планов запросов мы начали публикацию на Хабре серии статей, посвященных работе с PostgreSQL и его особенностям. Это уже пройденные нами «грабли», интересные наработки, накопившиеся рекомендации, применяемые в разработке «Тензора» — те вещи, которые помогают нам делать СБИС более эффективным.


СБИС — это система полного цикла управления бизнесом — от кадрового учета, бухгалтерии, делопроизводства и налоговой отчетности, до таск-менеджмента, корпоративного портала и видеокоммуникаций. Поэтому каждый из 1 500 000 клиентов-организаций находит что-то полезное для себя и использует наши сервисы на постоянной основе — что дает ежемесячно более миллиона активных клиентов.


И все их данные надо где-то хранить и эффективно извлекать. Поэтому еще в далеком 2012 году мы сделали ставку на PostgreSQL, и теперь это основное хранилище данных наших сервисов:

  • почти 9000 баз общим объемом 1PB
  • свыше 200TB данных клиентов
  • 1500 разработчиков работают с БД

Чтобы упорядочить накопившиеся знания, за минувший год мы опубликовали более 60 статей, в которых делимся своим реальным опытом, проверенным практикой «сурового энтерпрайза». Возможно, какие-то из них вы пропустили, поэтому под катом мы собрали дайджест, где каждый разработчик и DBA найдет что-то интересное для себя.

Для удобства все статьи разбиты на несколько циклов:

  • Анализ запросов
    Наглядно демонстрируем все тайны EXPLAIN [ANALYZE].
  • SQL Antipatterns и оптимизация SQL
    Понимаем как [не] надо решать те или иные задачи в PostgreSQL и почему.
  • SQL HowTo
    Пробуем подходы к реализации сложных алгоритмов на SQL для развлечения и с пользой.
  • DBA
    Присматриваем за базой, чтобы ей легко дышалось.
  • Прикладные решения
    Решаем с помощью PostgreSQL конкретные бизнес-задачи.
Читать дальше →

DataGrip 2020.3: SQL для Монги, новые форматы экспорта, интроспекция прав доступа и другое

Время на прочтение6 мин
Количество просмотров5K
Привет! Очередной длинный пост о том, что мы сделали за последние четыре месяца. Как всегда, мы говорим DataGrip, а подразумеваем все остальные наши IDE. В том числе и WebStorm, SQL-плагин к которому теперь можно докупить.


Читать дальше →

PostgreSQL Antipatterns: DBA-детектив, или Три дела о потерянной производительности

Время на прочтение30 мин
Количество просмотров5.5K
Сегодня вместо решения абстрактных алгоритмических задач мы выступим в роли детектива, по крупицам доставшейся информации исследующего неэффективные запросы, и рассмотрим три реальных дела, встречавшихся в разное время на просторах нашего приложения СБИС, когда простота и наивность при написании SQL превращалась в дополнительную нагрузку для PostgreSQL-сервера.


Дедукция и индукция помогут нам вычислить, что же все-таки хотел получить от СУБД разработчик, и почему это получилось не слишком оптимально. Итак, сегодня нас ждут:

  • Дело о непростом пути вверх
    Разберем в live-видео на реальном примере некоторые из способов улучшения производительности иерархического запроса.
  • Дело о худеющем запросе
    Увидим, как можно запрос упростить и ускорить в несколько раз, пошагово применяя стандартные методики.
  • Дело о развесистой клюкве
    Восстановим структуру БД на основании единственного запроса с 11 JOIN и предложим альтернативный вариант решения на ней той же задачи.
Расследовать

Низкоуровневое обнаружение (LLD) в Zabbix через SQL-запросы

Время на прочтение3 мин
Количество просмотров8.8K


Привет, Хабр! В этой статье поделюсь полезным подходом мониторинга в Zabbix — через обнаружение элементов данных в ответе на SQL-запрос. Этот тип мониторинга обычно используется в бизнес-мониторинге, когда собираются показатели производительности бизнес-процесса: количество пользователей, транзакций или выполняется контроль статуса операций. В целом, это универсальный подход, про который администраторы Zabbix иногда забывают. А он есть. Добро пожаловать под кат.
Читать дальше →

Postgresso 26

Время на прочтение12 мин
Количество просмотров4.1K


Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.


Пополнение в Core Team

Напоминаем о неписанном правиле сообщества: в Core Team не должно быть большинство из одной компании. После слияния-поглощения EDB 2ndQuadrant 3 из 5 участников Основной Команды оказались коллегами по EDB. К счастью, никого не сократили, а добавили двух достойных: Андреса Фройнда (Andres Freund, Microsoft, Citus) и Джонатана Каца (Jonathan Katz, Crunchy Data).

Любимые области Андреса Фройнда: репликация, производительность и масштабируемость (смотрите три недавние статьи на эту тему, ссылки в нашем разделе Статьи. Производительность), хранение.

Джонатан Кац (Jonathan Katz, Crunchy Data) занимался патчами и ревью, но больше концентрировался на разработке и поддержке сайта, выпуске релизов и прочей сопутствующей, но необходимой деятельности. Он вообще важный человек: председатель совета директоров Ассоциации PostgreSQL в США (United States PostgreSQL Association) и директор Ассоциации PostgreSQL-сообщества Канады (PostgreSQL Community Association of Canada), которая выступает как юридическое лицо сообщества.

Прекрасное, взвешенное решение. Впрочем, не все с этим согласны: Альваро Эрнандес (Álvaro Hernández Tortosa — если полностью) поздравил новоизбранных (непонятно кем и непонятно как — по его мнению) и предложил задуматься над следующими 10 проблемами управления сообществом:

Влияние компаний:

  • 40% из Core Team были из одной компании, теперь — 43%, 71% из двух;
  • 100% из всего лишь 4 компаний.

Многообразие (diversity):

  • 100% это белые мужчины;
  • 100% из США или Европы;
  • все кроме одного работают в американских компаниях.

Демократия:

  • членов Core Team назначают члены Core Team;
  • срок неограничен, четверо являются членами уже больше 15 лет.

Прозрачность:
  • процессы выбора членов и кандидатов, критерии выбора и пр. — суть большой секрет;
  • заседания секретны;
  • стратегии (policies) объявляются, а не обсуждаются в сообществе.
Читать дальше →

Обзор операторов PostgreSQL для Kubernetes. Часть 2: дополнения и итоговое сравнение

Время на прочтение8 мин
Количество просмотров12K


На прошлую статью, где мы рассмотрели три оператора PostgreSQL для Kubernetes (Stolon, Crunchy Data и Zalando), поделились своим выбором и опытом эксплуатации, — поступила отличная обратная связь от сообщества*.

Продолжая эту тему, мы добавили в обзор два других решения, на которые нам указали в комментариях: StackGres и KubeDB, — и сделали сводную таблицу сравнения. Также за время эксплуатации оператора от Zalando у нас появились новые интересные кейсы — спешим поделиться и ими.
Читать дальше →

PostgreSQL Antipatterns: работаем с отрезками в «кровавом энтерпрайзе»

Время на прочтение6 мин
Количество просмотров11K
В различных бизнес-приложениях регулярно возникает необходимость решить какую-либо задачу с отрезками/интервалами. Самое сложное в них — понять, что это именно одна из таких задач.


Как правило, они отчаянно маскируются, и даже у нас в СБИС их найти можно в абсолютно разных сферах управления предприятием: контроле рабочего времени, оценке загрузки линий АТС или даже в бухгалтерском учете.
«Отличие enterprise [решения] от всего остального — он всегда идёт от запросов бизнеса и решает какую-то бизнес-задачу.» [src]
Вот и давайте посмотрим, какие именно прикладные задачи и как можно решить с помощью PostgreSQL и сократить время анализа данных с нескольких секунд на бизнес-логике до десятков миллисекунд, умея эффективно применять следующие алгоритмы непосредственно внутри SQL-запроса:

  • поиск отрезков, пересекающих точку/интервал
  • слияние отрезков по максимальному перекрытию
  • подсчет количества отрезков в каждой точке
Читать дальше →

PostgreSQL на K8s в Zalando: два года в бою. Александр Кукушкин (Zalando)

Время на прочтение16 мин
Количество просмотров9.7K


Мы все знаем, что большинство DBA очень консервативны и предпочитают, чтобы их базы жили исключительно на выделенных серверах. В современном мире с микросервисами, Kafka и Kubernetes количество баз начинает расти прямо пропорционально размеру организации и очень быстро выходит за пределы комфортного ручного или полуавтоматического управления.

Ближайшие события

Как не проспать проблемы в базах данных Postgres. Николай Самохвалов (Postgres.ai)

Время на прочтение21 мин
Количество просмотров7.9K


Чтобы поддерживать базы данных в здоровом состоянии, необходимо периодически заглядывать «под капот», «прощупывать» её на наличие ранних симптомов — другими словами, делать профилактическое исследование, оно же технический аудит БД, оно же healthcheck.

PostgreSQL отложенные SQL ограничения

Время на прочтение10 мин
Количество просмотров24K
На Хабре уже было несколько статей упоминающих deferred constraints.


Но хочется рассказать о них подробнее.

PostgreSQL deferred constraint
Читать дальше →

Оптимизация работы с PostgreSQL в Go: от 50 до 5000 RPS

Время на прочтение14 мин
Количество просмотров33K

Привет, меня зовут Иван, и я делаю Авито Доставку. Когда пользователь покупает товар с доставкой, мы показываем ему список отделений служб доставки с ценами. Цена доставки может меняться от отделения к отделению. Мы смотрим на область карты, где покупатель ищет товар и информацию по объявлению, например, координаты продавца, вес и размеры товара. И на выходе показываем человеку список отделений с адресами и ценой доставки в каждое из них.


В ходе разработки калькулятора цены доставки возникла такая задача: есть структура базы данных PostgreSQL и запрос к ней от сервиса на Go. Нужно заставить всё это работать достаточно быстро. В итоге нам удалось поднять пропускную способность сервиса с 50 до 5000 RPS и выявить пару нюансов при общении сервиса с базой. Об этом и пойдёт рассказ.


Читать дальше →

Перечислимый тип и PostgreSQL

Время на прочтение20 мин
Количество просмотров16K


Пролог


Под перечислимым типом обычно понимают тип данных, который может принимать ограниченное и, как правило, небольшое число значений. Его выделяет то, что эти значения часто хардкодятся программистами в исходный код. И, как следствие, пользователи и операторы приложения не могут менять множество значений перечислимого типа. Их меняют только разработчики, зачастую с соответствующими исправлениями в коде и бизнес-логике приложения. Примерами перечислимых типов могут быть: времена года, месяцы, направление типа въезда/выезд или in/out, какие-нибудь типы или категории чего-нибудь, и так далее. В PostgreSQL подобную функциональность могут и реализуют различными способами. Этому посвящена статья.

Читать дальше →

Анализируем «слона» по частям

Время на прочтение3 мин
Количество просмотров4.1K
Если вы регулярно отлаживаете производительность запросов к PostgreSQL, а EXPLAIN (ANALYZE, BUFFERS) ... — любимый инструмент познания особенностей работы этой СУБД, то новые полезные «фишки» нашего сервиса визуализации и анализа планов explain.tensor.ru наверняка пригодятся вам в этом нелегком деле.

Но сразу напомню, что без полноценного всестороннего мониторинга базы PostgreSQL использовать только анализ плана — это выступать с позиции мудреца #5!


[источник КДПВ, «Слепые и слон»]
Немного про мудреца #5

Неожиданное влияние текстов среднего размера на производительность PostgreSQL

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

  1. Маленькие тексты. Имена и фамилии людей, заголовки страниц, имена пользователей, адреса электронной почты и прочее подобное. Обычно на размер таких полей накладываются определённые ограничения, довольно сильные. Возможно, это даже не поля типа text, а поля типа varchar(n).
  2. Большие тексты. Это, например, содержимое публикаций в блогах, тексты статей, HTML-код. Такие данные представляют собой большие фрагменты текста неограниченной длины, хранящиеся в базе данных.
  3. Тексты среднего размера. Это — описания, комментарии, отзывы о товарах, данные о трассировке стека и так далее. В сущности это — любые текстовые поля, размер которых находится между размерами «маленьких» и «больших» текстов. Обычно размер таких полей не ограничен, но их содержимое, по естественным причинам, меньше, чем содержимое полей категории «большие тексты».



В этом материале я хочу рассказать о неожиданном влиянии текстов среднего размера на производительность запросов в PostgreSQL. В частности, мы поговорим о TOAST (The Oversized-Attribute Storage Technique, Техника хранения больших атрибутов) 
Читать дальше →

Этюд по PITR штатными средствами PostgreSQL

Время на прочтение3 мин
Количество просмотров11K
В короткой заметке описан cценарий Point In Time Recovery с использованием средств из стандартной поставки PostgreSQL версии 11.

Для создания базовой резервной копии используется штатная утилита — pg_basebackeup.
Для потоковой архивации файлов WAL используется штатная утилита — pg_receivewal

Общий сценарий довольно подробно описан в документации Непрерывное архивирование и восстановление на момент времени (Point-in-Time Recovery, PITR), однако довольно общими фразами. Поэтому при попытке реализовать на практике возникли некоторые, хотя и вполне преодолимые шероховатости.

Посмотрел по поиску на Хабре, вроде не нашел статей о PITR штатными средствами. Так, что может быть кому то пригодится, в качестве шаблона-рыбы. Или студентам, как лабораторка ;-)
Читать дальше →