Выступление на Krasnodar Dev Days о Postgres

Dec 26, 2016 10:40 · 1173 words · 6 minute read доклады

слайды

Всем привет!

Postgres

Да, тема большая, так что я уточнил словом «Начало». Цель моего доклада — заинтересовать вас, рассказать о преимуществах и обсудить недостатки. В конце слайдов будут ссылочки на интересный материал на мой взгляд.

В основу баз данных была положена так называемая CAP-теорема. Она гласит, что для распределённых систем вы можете выбрать только 2 свойства из 3х: согласованность, доступность, партицирование. Ну это как создание сайта — выберите 2 из 3х: быстро, дёшево или качественно. РСУБД традиционно CA — они всегда доступны и хранят согласованные данные, но плохо реплицируются по инстансам. MongoDB и Redis — CP — они хранят согласованные данные и хорошо масштабируются горизонтально, но временами имеют потерю доступности. Та же монга блокирует чтение всех пользователей, пока кто-то пишет. Третий класс AP — те БД, которые имеют eventually consistent. То есть когда нибудь данные придут в консистентное состояние. Но вот когда именно почему-то никто не уточняет. Отдельно мне бы хотелось упомянуть Riak — в ней вы можете сами настраивать все 3 параметра.

Ладно, хватит теории — вернёмся к Postgres. Её используют многие компании: Yandes, Instagram, Reddit, Ростелеком. А недавно она получила сертификацию ФСТЭК, то есть всем, кто работает с Госзаказчиками — велком. Поддержка есть во всех языках программирования из TIOBE top 20. Также не смог найти фреймворк, в котором бы не было поддержки. А вот с CMS всё несколько хуже — WordPress, MODx, Bitrix почему-то работают только с MySQL. Хотя я проглядел исходники WordPress — у них там свой класс для работы с БД, в котором прям зашиты вызовы функций MySQL. Вроде 2016 год на дворе, почему до сих пор не переписали на PDO — не знаю.

Инструментарий

А что с инструментами? Их полно. Поддержка есть как в продуктах JetBrains, так и в текстовых редакторах типа Sublime, Atom, vim… Из отдельных графических — PgAdmin3. Сейчас вышел PgAdmin4 — phpmyadmin, но для Postgres. С понятным анализатором запросов, мониторингом, дебаггером хранимок. Красивенько, да? В общем, мне понравился — рекомендую. Написан на python и ставится как обычный пакет.

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

Особенности

Репликация

Это больная тема для всех реляционных БД. Так или иначе эта задача решена везде, но я бы не сказал, что идеально. Бывший разработчик Percona написал пару статей, где хорошо описывает проблемы репликации и их решения в MySQL и PostgreSQL. Если в кратце, то в Postgres репликация делается на физическом уровне (на уровне страниц), что позволяет закрыть сразу кучу проблем. К тому же из-за отказа от разных типов хранилища, есть только один WAL, что опять же упрощает синхронизацию и восстановление. Однако в стандартной поставке 9.6 репликации пока нет, вместо это предлагают использовать stolon — master-master autofailover, который интегрируется с konsul/etcd/kubernetes.

Оптимизатор запросов

Postgres славится своей оптимизацией запросов. Это одна из причин почему в нём нет хинтов как в Оракле. Также в postgres помимо b-tree индекса существуют ещё куча индексов. Ну и наконец в нём достаточно легко посмотреть сам план выполнения запроса, в котором расписывается какие шаги выполняются и за примерно какое время. Оень удобная штука для анализа работы приложения с базой данных.

Типы данных

Их в postgres ну очень много. Обычные, специальные, геометрические, составные, ну и, конечно, вы можете написать свои собственные. Более того, для каждого типа существуют и ряд функций для работы с ним. Например, для получения json из строк таблицы. Большинство функций объединены в расширения. Самое известное PostGIS — работа с геокоординатами. Средствами самой СУБД можно определить входит ли точка в полигон, ну и многое другое. Ещё одно интересное расширение — PostgREST, которое предоставляет REST интерфейс непосредственно к таблицам базы данных. Естественно, вы можете написать и свой пакет расширений на C, это гораздо проще чем кажется. А можете обойтись хранимкой на python, php, js… К тому же в pgAdmin4 есть удобный отладчик.

Foreign data wrapper

Ещё одна интересная особенность Postgres — он умеет общаться с внешними сущностями. То есть на pl/v8 можно написать хранимку, которая будет смотреть токен авторизации в redis, брать данные из Oracle, картинку тянуть с S3 и постить всё это в твиттер. В общем, весь бэкенд в базе данных.

Транзакционный DDL

DDL в Postgres транзакционный, то есть пока вы меняете схему базы данных в отдельной транзакции, все пользователи видят предыдущую. Очень удобно, особенно спасает при накате миграций — если что-то пошло не так, то rollback всё аккуратненько откатит (на самом деле просто не применит). Ещё раз насчёт индексов — их довольно много, и что самое главное — их построение не блокируют работу всей базы данных. Можно даже json внутри поля индексировать. Получается вот такая вот гетерогенная БД — вроде как реляционная, но умеет также и с json полноценно работать.

Autovacuum

Рассказ не был бы полон без упомниания такой специфики Postgres как autovacuum. Это служебный демон, который прибирается за БД. Когда вы редактируете запись, то postgres вместо прямого редактирования строки добавляет ещё одну с изменёнными значениями, которую, кстати, надо проиндексировать. Старая же строка помечается как неактуальная. Со временем она станет невидимой для всех транзакций и будет физически удалена autovacuum. Помимо очистки таблиц, этот демон также собирает статистику и перестраивает индексы, если необходимо.

Сообщество

Postgres хоть и Open Source продукт, но у него отличная платная поддержка, если кому надо. Кстати, не такая дорогая, как для Oracle. В нашей стране поддержкой и развитием занимается компания Postgres Professional. Они уже очень много сделали для сообщества, в частности gist/gin индексы и jsonb-поля — это их работа. На своём сайте они выложили полностью переведённую документацию к последней версии. Регулярно проводят курсы по администрированию, материалы можно скачать здесь. Приглашают всех поучаствовать в разработке СУБД. Ну и рассказывают как она устроена изнутри. Кстати, очень интересный курс. Также у них на сайте можно посмотреть над чем ведётся работа.

Недостатки

Ладно, теперь о недостатках. Во-первых, из коробки там нет пула соединений. Приходится ставить PgBouncer или pgpool. Хотя в некоторых ORM это уже реализовано. Во-вторых, скорость записи. Postgres создавался с расчётом на то, что читать из него будут гораздо чаще, чем писать. Т.е. если в том же MySQL первичный ключ обязателен и служит указателем на строку данных и не обновляется при апдейте данных, то в Postgres при каждом изменении создаётся новая строка, и для неё перерассчитываются индексы. Старые записи потом удаляются autovacuum. Да, это медленнее, но я бы не сказал, что как-то заметно. Ну и наконец, Postgres не так широко поддерживается, как MySQL — у некоторых хостеров его может просто не быть.

Так что где не надо использовать. Ну, во-первых, в качестве кеша, лучше взять какой-нибудь Memcache или Redis. Аналогично с брокером сообщений. Хоть в Postgres и есть своя система pub/sub, но не думаю, что это хорошая идея. Сбор логов опять же лучше предоставить какому-нибудь ElasticSearch. Если вам не нужна целостность данных, транзакции, внешние ключи — возьмите лучше что-нибудь из NoSQL. Ну и если ваши инструменты не поддерживают Postgres. Вряд ли заказчик оценит ваше допиливание поддержки.