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

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

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

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

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

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

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

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

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

«Отличие enterprise [решения] от всего остального — он всегда идёт от запросов бизнеса и решает какую-то бизнес-задачу.» [src]

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

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

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

• Postgres: bloat, pg_repack и deferred constraints
  
• Ограничения (сonstraints) PostgreSQL: exclude, частичный unique, отложенные ограничения и др
  

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

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

Пролог

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

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

Совместно с Евгением Аристовым, экспертом по работе с различными СУБД, рассказываем об актуальности специализации и программе онлайн-курса «PostgreSQL».

Популярность этой бесплатной СУБД постоянно растет. Недавно мы проводили опрос, согласно которому преобладающая часть компаний сразу выбирают Postgres или планируют переход на нее с целью сокращения расходов.

На фоне этого на рынке ощущается постоянная нехватка специалистов. Речь идет о тех администраторах и разработчиках, которые умеют не просто работать с PostgreSQL, но и могут проектировать базы данных и развертывать высоконагруженные кластера в облаках, оптимизировать запросы, поддерживать и масштабировать.

Такие специалисты могут претендовать на зарплату 200-300 тыс. рублей.