Недавно мне понадобилось сходить в PostgreSQL из скрипта на Python. Была предпринята попытка воспользоваться для этого библиотекой py-postgresql, поскольку я успешно использовал ее в прошлом. Но оказалось, что py-postgresql не работает с последними версиями постгреса. В моем случае использовался PostgreSQL 11. Ну что же, тогда не будем выпендриваться, и возьмем используемый всеми psycopg2. Поскольку интерфейс psycopg2 заметно отличается от интерфейса py-postgresql, было решено написать небольшую памятку по использованию данной библиотеки.
Типичные веб-проекты, разрабатываемые на чем-то вроде Python или PHP, характерны тем, что создают большое количество соединений к СУБД — по одному, а иногда и по несколько, на каждый HTTP-запрос. Имея классическую архитектуру «один процесс на соединение», PostgreSQL не очень хорошо справляется с большим (условно, больше 100) количеством соединений. Решить проблему позволяет пулер соединений под названием PgBouncer. Благодаря использованию библиотеки libevent, PgBouncer может поддерживать большое количество (тысячи) соединений, которые проксируются на несколько (пара десятков) соединений непосредственно к PostgreSQL.
Сегодня я хотел бы вкратце рассказать о возможности PostgreSQL под названием logical decoding. Данный механизм позволяет подписаться на изменения, происходящие в базе данных, и получать эти изменения в удобном для вас формате, например, в JSON. Logical decoding ни в коем случае нельзя путать с логической репликацией. Logical decoding появился в PostgreSQL намного раньше, в версии 9.4, и является механизмом, на основе которого работает логическая репликация, появившаяся в версии 10.
PostGIS — это географическая информационная система, или ГИС (geographic information system, GIS), реализованная в виде расширения к PostgreSQL. ГИС позволяет хранить пространственные или географические данные, такие, как точки, ломаные линии и полигоны, производить по ним эффективный поиск, а также выполнять с ними другие операции. В общем, можно написать убийцу Google Maps и Яндекс.Карт :) Давайте же попробуем разобраться, как пользоваться этой штукой.
PL/pgSQL — язык программирования, используемый для написания хранимых процедур и триггеров для PostgreSQL. Сказать по правде, впервые увидев код на PL/pgSQL, я испытал ужас. Хотя в коде и угадывались типичные конструкции процедурных языков программирования, выглядел он больно уж загадочно и вообще напоминал код на COBOL. Само собой разумеется, со временем это ощущение у меня прошло. Цель заметки — показать, что кода на PL/pgSQL не нужно бояться, и в целом язык довольно простой.
Потоковая репликация в PostgreSQL имеет ряд ограничений. Наиболее существенное среди них, пожалуй, заключается в том, что вы не можете перейти на следующую версию PostgreSQL без полной остановки кластера хотя бы на несколько минут. Поэтому в PostgreSQL 10 была представлена логическая репликация, решающую как эту, так и ряд других проблем.
В продолжение темы о полнотекстовом поиске в PostgreSQL хотелось бы также рассказать о расширении под названием pg_trgm. Данное расширение предназначено для поиска текстовых документов по триграммам, то есть, всем подпоследовательностям из трех букв, входящих в индексируемый текст. На практике такой поиск интересен, помимо прочего, тем, что позволяет находить документы по запросам, содержащим опечатки.
Полнотекстовый поиск (Full-Text Search, FTS) это когда вы ищите какие-то документы, скажем, товары в интернет-магазине или статьи в блоге, по текстовому запросу, как в Google. Немногие знают, что в PostgreSQL из коробки есть полнотекстовый поиск, притом, в отличие от некоторых других РСУБД, очень даже неплохой. Далее в этой заметке будет рассказано, как им пользоваться.
Нет причин не продолжить наше с вами изучение библиотек для языка C. Ранее в этом блоге рассматривались библиотеки libcurl, libpcap, а также некоторые сильно менее распространенные. Сегодня же мы узнаем, как программы на C могут работать с реляционными базами данных.
Для PostgreSQL существует множество так называемых high availability решений, наиболее известными из которых, пожалуй, являются repmgr и patroni. Согласно некоторым отзывам, они не слишком удобны в использовании и иногда могут терять данные. Поэтому сегодня мне хотелось бы рассказать о более новом решении под названием Stolon. Разработка Stolon ведется с сентября 2015-го года. Он написан на языке Go, активно паразитирует на Consul или etcd (на выбор пользователя) и из коробки имеет интеграцию с Kubernetes. Но самое главное — он сравнительно прост в использовании и выглядит очень правильно с точки зрения дизайна системы. При правильном использовании Stolon переживает нетсплиты и не теряет данные.