PostgreSQL

Отказоустойчивый кластер PostgreSQL + Patroni. Опыт внедрения

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

У нас высоконагруженный сервис: 2,5 млн пользователей по всему миру, 50К+ активных пользователей каждый день. Сервера находятся в Amazone в одном регионе Ирландии: в работе постоянно 100+ различных серверов, из них почти 50 — с базами данных.

Весь backend — большое монолитное stateful-приложение на Java, которое держит постоянное websocket соединение с клиентом. При одновременной работе нескольких пользователей на одной доске все они видят изменения в режиме реального времени, потому что каждое изменение мы записываем в базу. У нас примерно 10К запросов в секунду к нашим базам. В пиковой нагрузке в Redis мы пишем по 80-100К запросов в секунду.



Источник

Понимание джойнов сломано. Продолжение. Попытка альтернативной визуализации

Многие из вас читали
предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.

При подготовке к записи шестого выпуска подкаста «Цинковый прод» (где мы договорились обсудить статью) кажется удалось нащупать один интересный вариант визуализации. Кроме того, в комментариях к изначальной статье тоже предлагали похожий вариант.

Все желающие приглашаются под кат

Источник

Профессиональный Postgres

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции
PGConf.Russia 2019. Доклад Олега Бартунова на тему «Профессиональный Postgres» открывал пленарную часть конференции. В нем раскрыта история СУБД Postgres, российский вклад в разработку, особенности архитектуры.

Предыдущие материалы этой серии: «Типичные ошибки при работе с PostgreSQL» Ивана Фролкова, части
1 и
2.



Я буду рассказывать про профессиональный Postgres. Прошу не путать с компанией, которую я представляю сейчас — Postgres Professional.



Я действительно буду говорить о том, как Postgres, начинавшийся как любительская академическая разработка, стал профессиональным — таким, как мы его видим сейчас. Выскажу исключительно свое персональное мнение, оно не отражает мнение ни нашей компании, ни каких-либо групп.

Источник

Используем все возможности индексов в PostgreSQL

В мире Postgres индексы крайне важны для эффективной навигации по хранилищу базы данных (его называют «куча», heap). Postgres не поддерживает для него кластеризацию, и архитектура MVCC приводит к тому, что у вас накапливается много версий одного и того же кортежа. Поэтому очень важно уметь создавать и сопровождать эффективные индексы для поддержки приложений.

Предлагаю вашему вниманию несколько советов по оптимизации и улучшению использования индексов.

Примечание: показанные ниже запросы работают на не модифицированном образце базы данных pagila.

Источник

SQL: задача о рабочем времени

Здравствуйте, в эфире снова Радио SQL! Разминайте ганглии, расправляйте псевдоподии (или наоборот?) и настраивайтесь на нашу гравитационную волну!



Источник

Блокировки в Postgres: 7 советов по работе с блокировками

И снова здравствуйте! Уже в следующий вторник стартует новый поток по курсу
«Реляционные СУБД», поэтому мы продолжаем публиковать полезный материал по теме. Поехали.



На прошлой неделе я писал о
конкурентном доступе в Postgres, какие команды блокируют друг друга, и как вы можете диагностировать заблокированные команды. Конечно, после постановки диагноза вам может потребоваться и лечение. С Postgres можно выстрелить себе в ногу, но Postgres также предлагает вам способы не сбить наводку. Вот некоторые из важных советов о том, как стоит и как не стоит делать, которые мы сочли полезными при работе с пользователями по переходу с их единой базы данных Postgres на
Citus или при создании новых приложений
аналитики в реальном времени.

Источник

Ты помнишь, как все начиналось. Все было впервые и вновь

О том, как пришлось заняться оптимизацией запроса PostgreSQL и что из всего этого получилось.

Почему пришлось? Да потому, что предыдущие 4 года все работало тихо, спокойно, как часики тикали.

В качестве эпиграфа.



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

При достижении некоторого результата всегда интересно вспомнить, что-же послужило толчком к началу, с чего все началось.

Итак, что в результате получилось, кратко описано в статье «
Синтез как один из методов улучшения производительности PostgreSQL».

Наверное, занятно будет воссоздать цепочку предшествующих событий.

История сохранила точную дату начала — 2018-09-10 18:02:48.

Также в истории есть запрос, с которого всё началось:

Проблемный запросSELECT

p.«PARAMETER_ID» as parameter_id,

pd.«PD_NAME» AS pd_name,

pd.«CUSTOMER_PARTNUMBER» AS customer_partnumber,

w.«LRM» AS LRM,

w.«LOTID» AS lotid,

w.«RTD_VALUE» AS RTD_value,

w.«LOWER_SPEC_LIMIT» AS lower_spec_limit,

w.«UPPER_SPEC_LIMIT» AS upper_spec_limit,

p.«TYPE_CALCUL» AS type_calcul,

s.«SPENT_NAME» AS spent_name,

s.«SPENT_DATE» AS spent_date,

extract(year from «SPENT_DATE») AS year,

extract(month from «SPENT_DATE») as month,

s.«REPORT_NAME» AS report_name,

p.«STPM_NAME» AS stpm_name,

p.«CUSTOMERPARAM_NAME» AS customerparam_name

FROM wdata w,

spent s,

pmtr p,

spent_pd sp,

pd pd

WHERE s.«SPENT_ID» = w.«SPENT_ID»

AND p.«PARAMETER_ID» = w.«PARAMETER_ID»

AND s.«SPENT_ID» = sp.«SPENT_ID»

AND pd.«PD_ID» = sp.«PD_ID»

AND s.«SPENT_DATE» >= '2018-07-01' AND s.«SPENT_DATE» <= '2018-09-30'

and s.«SPENT_DATE» = (SELECT MAX(s2.«SPENT_DATE»)

FROM spent s2,

wdata w2

WHERE s2.«SPENT_ID» = w2.«SPENT_ID»

AND w2.«LRM» = w.«LRM»);

Источник

DataGrip 2019.1: поддержка новых баз, инициализационные скрипты, новые инспекции и другое

Привет! Посмотрим на новые штуки в —
DataGrip 2019.1. Напомним, что функциональность DataGrip включена и в другие наши платные IDE, кроме WebStorm.



Источник

MVCC-1. Изоляция

Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL.

Материал будет основан на
учебных курсах по администрированию, которые делаем мы с Павлом
pluzanov. Смотреть видео не все любят (я точно не люблю), а читать слайды, пусть даже с комментариями, — совсем «не то».

Конечно, статьи не будут повторять содержание курсов один в один. Я буду говорить только о том, как все устроено, опуская собственно администрирование, зато постараюсь делать это более подробно и обстоятельно. И я верю в то, что такие знания полезны прикладному разработчику не меньше, чем администратору.

Ориентироваться я буду на тех, кто уже имеет определенный опыт использования PostgreSQL и хотя бы в общих чертах представляет себе, что к чему. Для совсем новичков текст будет тяжеловат. Например, я ни слова не скажу о том, как установить PostgreSQL и запустить psql.

Вещи, о которых пойдет речь, не сильно меняются от версии к версии, но использовать я буду текущий, 11-й «ванильный» PostgreSQL.

Первый цикл посвящен вопросам, связанным с изоляцией и многоверсионностью, и план его таков:

1. Изоляция, как ее понимают стандарт и PostgreSQL (эта статья);


2. Слои, файлы, страницы — что творится на физическом уровне;


3. Версии строк, виртуальные и вложенные транзакции;


4. Снимки данных и видимость версий строк, горизонт событий;


5. Внутристраничная очистка и HOT-обновления;


6. Обычная очистка (vacuum);


7. Автоматическая очистка (autovacuum);


8. Переполнение счетчика транзакций и заморозка.

Ну, поехали.

Источник

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

Здравствуйте, хабровчане! Предлагаю вашему вниманию перевод статьи
«How a single PostgreSQL config change improved slow query performance by 50x» автора Pavan Patibandla. Она очень сильно мне помогла улучшить производительность PostgreSQL.

В Amplitude наша цель — предоставить простую в использовании интерактивную аналитику продуктов, чтобы каждый мог найти ответы на свои вопросы о продукте. Чтобы обеспечить удобство работы, Amplitude должен быстро предоставить эти ответы. Поэтому, когда один из наших клиентов пожаловался на то, сколько времени потребовалось для загрузки раскрывающегося списка свойств события в пользовательском интерфейсе Amplitude, мы приступили к детальному изучению проблемы.

Отслеживая задержку на разных уровнях, мы поняли, что одному конкретному запросу PostgreSQL потребовалось 20 секунд для завершения. Для нас это стало неожиданностью, так как обе таблицы имеют индексы в соединяемом столбце.

Медленный запрос



Источник

Типичные ошибки при работе с PostgreSQL. Часть 2

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции
PGConf.Russia 2019.
В первой части доклада
Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии
idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние
idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.



Источник

Статья про то, как CommVault делает бэкап PostgreSQL

В данной статье мы рассмотрим наш опыт использования CommVault для резервного копирования PostgreSQL. Для этого разберем небольшую часть одного из наших прошлых проектов, где мы настраивали резервное копирование БД PostgreSQL у клиента.



Источник

Rails + Postgres + bindings

Привет друзья. Ни для кого не секрет, что работая на крупных проектах со сложной логикой, Active Record становится не помощником, а обузой. Представьте, что вам необходимо сделать очень сложный запрос для PostgreSQL нативным образом (на чистом SQL), где должно присутствовать некоторое количество переменных. Но в Rails есть одна неприятная мелочь, функционал выполнения нативных запросов не позволяет использовать именованные биндинги. Но решение есть Опробовано и успешно внедрено на проекте с Rails API 5.2 + Ruby 2.6.0 + Postgres 11.

Источник

Как мы мигрировали базу данных из Redis и Riak KV в PostgreSQL. Часть 1: процесс

Это первая часть статьи, в которой я расскажу о том, как мы построили процесс работы над большим проектом по миграции БД: про безопасные эксперименты, командное планирование и кросс-командное взаимодействие. В следующих статьях подробней расскажу про технические проблемы, которые мы решали: про масштабирование и отказоустойчивость PostgreSQL и нагрузочное тестирование.



Долгое время основной базой данных в RealtimeBoard был Redis. Мы хранили в нём всю основную информацию: данные о пользователях, аккаунтах, досках и т.д. Всё работало быстро, но мы столкнулись с рядом проблем.

Проблемы с Redis

1. Зависимость от сетевой задержки. Сейчас в нашем облаке она составляет порядка 20 мск, но при её увеличении приложение начнёт работать очень медленно.


2. Отсутствие индексов, которые нужны нам на уровне бизнес-логики. Их самостоятельная реализация может усложнить бизнес-логику и привести к неконсистентности данных.


3. Сложность кода также усложняет обеспечение консистентности данных.


4. Ресурсоёмкость запросов с выборками.

Эти проблемы вместе с ростом количества данных на серверах послужили причиной для миграции БД.

Источник

Скоро PGConf.Russia 2019

PGConf.Russia 2019 не за горами — 4 февраля мастер-классы, 5-6го — доклады. В этом году, как и в прошлом, конференция проводится на экономическом факультете МГУ. Активность докладчиков в период сбора докладов была заметно выше, чем в прошлые годы, так что программа будет интересной. Даже молчаливые 1С-ники подтянулись: первый раз (вместе с Инфостартом) удалось собрать целую секцию на тему «Postgres для 1С». Итак, что нас ждёт?

Источник