PGConfRu2019 Павел Молявин — «Готовим PostgreSQL в эпоху DevOps. Опыт 2ГИС»**

Всем привет! Меня зовут Павел! Я работаю в компании 2ГИС. Наша компания – это городской информационный справочник, навигационный сервис. Это очень хорошая штука, которая помогает жить в городе.

Для тех кто работает с данными в Excel зачастую встает проблема управления подключениями внешних таблиц к реляционным источникам. Да, Excel предоставляет здесь полный инструментарий, но не обеспечивает уровень комфорта и завышает планку требований к знаниям пользователей.

Кейс компании Appbooster

Полагаю, практически каждый проект, использующий Ruby on Rails и Postgres в качестве основного вооружения на бэкенде находится в перманентной борьбе между скоростью разработки, читаемостью/поддерживаемостью кода и скоростью работы проекта в продакшене. Я расскажу о своем опыте балансирования между этими тремя китами в кейсе, где на входе страдали читаемость и скорость работы, а на выходе получилось сделать то, что до меня безуспешно пытались сделать несколько талантливых инженеров.

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

Сегодня разберем пару примеров, как неудачная организация БД и кода могут превратить наше приложение в клубок проблем:

• накрутка serial при ON CONFLICT
• накрутка счетчика транзакций

Привет, Хабр!

Эта статья — продолжение первой статьи Telegram как NAS/FTP.

Речь всё о том же боте — TeleFS, он приобрёл важную составляющую — публичность. Точнее, пользователи бота теперь могут делиться своими файлами и папками с любыми другими пользователями Telegram.

И в этот раз расскажем о том как и с помощью чего создавался бот.

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

Типизация данных в PostgreSQL, при всей своей логичности, действительно преподносит порой очень странные сюрпризы. В этой статье мы постараемся прояснить некоторые их причуды, разобраться в причине их странного поведения и понять, как не столкнуться с проблемами в повседневной практике. Сказать по правде, я составил эту статью в том числе и в качестве некоего справочника для самого себя, справочника, к которому можно было бы легко обратиться в спорных случаях. Поэтому он будет пополняться по мере обнаружения новых сюрпризов от подозрительных типов. Итак, в путь, о неутомимые следопыты баз данных!

Тестирование горизонтального масштабирования SELECT запросов на реплику

Цель данного поста протестировать горизонтальное масштабирование SELECT запросов на реплику.

Схема горизонтального масштабирования примерно такая.

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

Релизы

Есть ощущение, что поток релизов в промежутке длиной в месяц между этим и предыдущим выпуском Postgresso заметно истончился.

Здравствуйте, меня зовут Виктор и я разработчик в компании Gems Development. Я хочу рассказать, как мы реализовывали создание и заполнение производственного календаря в Postgresql.

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

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

Наш СБИС, как и другие системы управления бизнесом, не обходится без формирования отчетов — каждый руководитель любит сводные цифры, особенно всякие суммы по разделам и красивые "Итого".

А чтобы эти итоги собрать, необходимо по исходным данным вычислить значение некоторой агрегатной функции: количество, сумма, среднее, минимум, максимум,… — и, как правило, не одной.


Сегодня мы рассмотрим некоторые способы, с помощью которых можно вычислить агрегаты в PostgreSQL или ускорить выполнение SQL-запроса.

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

Managing PostgreSQL at Gitlab.com. Jose Cores Finotto.

Большое спасибо! Добро пожаловать на наш разговор о PostgreSQL в Gitlab. Мы поговорим только об основных моментах. И более подробно вы можете узнать на сайте Gitlab.com.

Уже давно известно, что делать бэкапы в SQL-дампы (используя pg_dump или pg_dumpall) – не самая хорошая идея. Для резервного копирования СУБД PostgreSQL лучше использовать команду pg_basebackup, которая делает бинарную копию WAL-журналов. Но когда вы начнёте изучать весь процесс создания копии и восстановления, то поймёте что нужно написать как минимум пару трёхколёсных велосипедов, чтобы всё это работало и не вызывало у вас боль как сверху, так и снизу. Дабы облегчить страдания был разработан WAL-G.

WAL-G – это инструмент, написанный на Go для резервного копирования и восстановления PostgreSQL баз данных (а с недавнего времени и MySQL/MariaDB, MongoDB и FoundationDB). Он поддерживает работу с хранилищами Amazon S3 (и аналогами, например, Yandex Object Storage), а также Google Cloud Storage, Azure Storage, Swift Object Storage и просто с файловой системой. Вся настройка сводится к простым шагам, но из-за того что статьи о нём разрозненны по интернету – нет полного how-to мануала, который бы включал все шаги от и до (на Хабре есть несколько постов, но многие моменты там упущены).

Расшифровка доклада 2020 года Алексея Лесовского "PostgreSQL Scaling Usecases".

На сегодня уже никого не удивить тем что инфраструктура живет в "облаке", однако не все компоненты заезжают в "облако" легко и просто. Одним из таких компонентов является "база данных", которая всегда требовательна в плане ресурсов и производительности. Особенно остро стоит вопрос масштабируемости и устойчивости к сбоям, именно поэтому в последние годы можно наблюдать бурное развитие альтернативных СУБД.

Однако классические РСУБД за счет накопленных фич нередко остаются выбором №1 при том что они также не стоят на месте и предоставляют богатый набор инструментов в плане масштабирования.

В этом докладе я буду рассматривать преимущественно PostgreSQL, варианты его масштабирования и то когда это стоит делать и как это делать правильно и как делать неправильно. В докладе будут рассмотрены следующие темы:

• Потоковая репликация и разделение read/write рабочей нагрузки
• Логическая репликация и шардирование данных
• Обеспечение высокой доступности и устойчивости к сбоям

Посвящается всем любителям анализировать логи.

В логах работающих систем рано или поздно появляются тексты каких-то ошибок. Чем таких систем больше в обозримом пространстве, тем больше вероятность ошибку увидеть. Серверы PostgreSQL, которые находятся под нашим мониторингом ежедневно генерируют от 300K до, в неудачный день, 12M записей об ошибках.

И такие ошибки — это не какой-то там «о, ужас!», а вполне нормальное поведение сложных алгоритмов с высокой степенью конкурентности вроде тех, о которых я рассказывал в статье про расчет себестоимости в СБИС — все эти deadlock, could not obtain lock on row in relation …, canceling statement due to lock timeout как следствие выставленных разработчиком statement/lock timeout.

Но есть ведь и другие виды ошибок — например, you don't own a lock of type ..., которая возникает при неправильном использовании рекомендательных блокировок и может очень быстро «закопать» ваш сервер, или, мало ли, кто-то периодически пытается «подобрать ключик» к нему, вызывая возникновение password authentication failed for user …

^{[источник КДПВ]}

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

Расшифровка доклада 2015 года Алексея Лесовского "Deep dive into PostgreSQL internal statistics"

Disclaimer от автора доклада: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов в которых появилась масса новшеств, улучшений и изменений относительно статистики и часть материала устарела и не актуальна. По мере ревью я постарался отметить эти места чтобы не вводить тебя читатель в заблуждения. Переписывать же эти места я не стал, их очень много и получится в итоге совсем другой доклад.

СУБД PostgreSQL — это огромный механизм, при этом состоит этот механизм из множества подсистем, от слаженной работы которых напрямую зависит производительность СУБД. В процессе эксплуатации обеспечивается сбор статистики и информации о работе компонентов, что позволяет оценить эффективность PostgreSQL и принять меры для повышения производительности. Однако, этой информации очень много и представлена она в достаточно упрощенном виде. Обработка этой информации и ее интерпретация порой совсем нетривиальная задача, а "зоопарк" инструментов и утилит запросто поставит в тупик даже продвинутого DBA.

Полгода назад мы представили explain.tensor.ru — публичный сервис для разбора и визуализации планов запросов к PostgreSQL.



За прошедшие месяцы мы сделали про него доклад на PGConf.Russia 2020, подготовили обобщающую статью по ускорению SQL-запросов на основе рекомендаций, которые он выдает… но самое главное — собирали ваши отзывы и смотрели за реальными use case.

И теперь готовы рассказать о новых возможностях, которыми вы можете пользоваться.

В самом сердце проекта Actual, который предназначен для управления персональными финансами, лежит система синхронизации данных собственной разработки. Недавно я реализовал в проекте полное сквозное шифрование (оно, правда, пока не вышло в продакшн). Эта работа вдохновила меня на исследование производительности внутренних механизмов системы. Сегодня я хочу рассказать об одной возможности PostgreSQL, которая позволила добиться 9-10 кратного увеличения производительности проекта.

Несколько лет назад при переходе от разработки десктоп-приложения с локальной базой у каждого клиента к SaaS-модели с сотнями тысяч клиентов онлайн, нам пришлось сильно пересмотреть некоторые алгоритмы работы с БД при реализации функционала складского учета в СБИС. Этот внутренний доклад посвящен алгоритмическим причинам возникших сложностей и способам их решения.

Очередной семинар про работу с СУБД PostgreSQL. Сегодня расскажу, как суровую прагматику требований бизнеса перенести на разработку высоконагруженных сервисов, как бороться с конкурентным доступом к данным, как это все аккуратно обходить и при этом не «отстрелить себе ногу».

Сегодня мы поговорим про расчет себестоимости в СБИС:

• наша методика расчета
  что такое «себестоимость» вообще, зачем она нужна, и как ее считаем именно мы
• алгоритмические задачи
  концептуальные приемы при построении архитектуры решения «под алгоритм»
• технические приемы
  зачем и как применять упорядочение операций, делать транзакции короткими и быстрыми, организовать высококонкурентную очередь в БД и другие подходы к оптимизации нагрузки

Расшифровка доклада 2015 года Ильи Космодемьянского "Linux tuning to improve PostgreSQL performance"

Disclaimer: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов PostgreSQL вышло и 15 версий ядра Linux. Если переписывать эти места, то получится в итоге другой доклад. Но здесь рассмотрен фундаментальный тюнинг Linux для PostgreSQL, который актуален и сейчас.