Производительность

Начнём с того, что сегодня (на данный момент стабильная ветка — 8.2, актуальная версия — 8.2.5) PostgreSQL успешно тягается в плане производительности не только с OpenSource-альтернативами, но и с ведущими коммерческими СУБД. Такими как Oracle. Это уже не пустой звук — взгляните на результаты тестирования, проведённого в компании Sun. Медленных слонов больше нет! Богатейший набор типов индексов, широчайшие возможности тюнинга системы, работа с очень большими объёмами и нагрузками, хороший выбор систем репликации и масштабирования — всё это «по зубам» современным слонам. Даже скорость разработки выгодно отличает Постгрес по сравнению с другими СУБД: каждый год мы неизменно получаем существенный шаг вперёд.

Что же нового в PostgreSQL версии 8.3 в плане производительности? Многие изменения нетривиальны. По словам координатора разработки PostgreSQL Брюса Момджана (Bruce Momjian), нанёсшего не так давно по приглашению компании «Постгресмен» визит в Москву, та работа по оптимизации производительности системы, которой заняты разработчики Постгреса в последние годы, является чрезвычайно сложной. Каждый шаг требует всё более и более существенных трудозатрат, занимает всё больше времени и сил разработчиков.

Одним из таких действительно нетривиальных изменений можно смело считать «фишку» под названием HOT (Heap Only Tuples). Это, пожалуй, одно из самых существенных изменений в плане производительности. Чтобы понять, в чём заключается данное изменение, необходимо вспомнить, что PostgreSQL реализует так называемую мультиверсионную модель разграничения доступа (MVCC, Multi-Version Concurrency Control).

Суть HOT в следующем. Ранее, до реализации данного подхода, при обновлении строки в таблице каждая новая её версия приводила к появлению новых версий всех индексов, независимо от того, затрагивали ли данные изменения проиндексированные столбцы или нет (см. рис. «Обновление без HOT»). Теперь же, если новая версия строки попадает в ту же страницу памяти, что и предыдущая, и столбцы, по которым был создан индекс, не изменялись, индекс остаётся прежним. Но это ещё не всё. Если есть такая возможность, происходит «моментальное» повторное использование места в странице Heap. Что, естественно, сокращает объём работы, производимой при операции VACUUM. На рис. «HOT-обновление» схематически отображено, каким образом происходит теперь обновление строки.

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

Это означает, что при выполнении операции фиксации транзакции (COMMIT) сервер PostgreSQL не будет ждать завершения дорогостоящей операции синхронизации журнала транзакций (WAL fsync). Другими словами, транзакция будет считаться успешно завершённой сразу же, как только все логические условия будут выполнены (проверены все необходимые ограничения целостности). Физически запись в журнал транзакций произойдёт через очень малый промежуток времени (как правило, для нормально функционирующих систем это максимум 200-1000 мс).За состояние транзакции (синхронная/асинхронная) отвечает переменная окружения synchronous_commit. Перейти в асинхронный режим просто:

SET synchronous_commit TO OFF;

Стоит отметить, что асинхронные транзакции не являются альтернативой режиму работы сервера с отключенной операций fsync. Дело в том, что режим fsync=off может привести к получению несогласованного состояния базы (к примеру, в случае непредвиденного отказа оборудования или потери питания) и рекомендуется только в тех случаях, когда используется оборудование высокой надёжности (например, контроллер дисков с батарейкой). Использование же новой возможности никак не может привести к рассогласованию данных. Максимум, что возможно, это потеря небольшой порции данных (опять-таки, в случае жёсткого сбоя сервера — ошибки ОС, оборудования, сбой питания). Типичным примером для асинхронных транзакций может служить задача сохранения большого количества информации в таблицу-журнал (например, лог действий пользователя), когда потеря нескольких строк не является критичной. При этом все важные транзакции могут по-прежнему быть синхронными.

Ещё одно улучшение в области производительности относится к ситуациям, когда при выполнении запросов PostgreSQL последовательно просматривает таблицы (операция SeqScan). Если до версии 8.3 в таких случаях нередко возникали ситуации, когда разные процесса Постгреса одновременно делали одну и ту же работу — просматривали одну и ту же таблицу — то теперь, благодаря реализации Synchronized Scans («синронизованные просмотры»), в один и тот же момент времени для одной таблицы может проводиться не более одной операции просмотра. Достигается это следующим образом. Если в рамках какой-либо сессии требуется проведение SeqScan-а для некоторой таблицы, для которой уже выполняется SeqScan (для другой сессии), то произойдёт «прыжок на ходу» к результатам уже выполняющегося SeqScan-а. По завершении данного процесса, если это необходимо, будет осуществлён «добор» результатов с помощью ещё одного неполного SeqScan-а (см. рис).

Работа над уменьшением стресс-эффекта, производимого выполнением системой процессов checkpoint («контрольная точка») продолжается: теперь checkpoint-ы выполняются не сразу, а постепенно: процесс как бы «размазан» во времени. Отсюда и название данного изменения — checkpoint smoothing. Стоит отметить, что при штатном выключении сервера и проведениия «явной» операции checkpoint (команда CHECKPOINT) запись данных на диск по-прежнему будет производиться с максимально возможной скоростью.

В завершение разговора о производительности, приведём краткий перечень других изменений, призванных улучшить быстродействие систем, использующих PostgreSQL:

• теперь autovacuum включён по умолчанию;
• в некоторых ситуациях теперь возможнен запуск сразу нескольких процессов autovacuum (например, при продолжительном процессе чистки большой таблицы, небольшие таблицы теперь не вынуждены ждать завершения данного процесса);
• заметное уменьшение дискового пространства, занимаемого базами данных: 1) за счёт заголовков varlena-типов (типы данных переменной длины: текст, массивы и т. п.), которые ранее занимали строго 4 байта, а теперь в некоторых ситуациях всего 1 байт; 2) за счёт экономии заголовков строк таблицы (ранее 27 байт, теперь — 24);
• выполнение транзакций, не модифицирующих данные, не приводит к увеличению значения счётчика транзакций (xid), что существенно снижает вероятность ситуации «перекрытия» счётчика транзакций (xid wraparound); кроме того, данное изменение является значительным шагом вперёд к реализации встроенной Master-Slave репликации на основе трансфера журнала транзакций — теперь не возникнет рассинхронизации счётчика xid между Master- и Slave-узлами;
• реализован механизм автонастройки параметров процесса bgwriter (background writer — специальный процесс, занимающийся записью «грязных» разделяемых буферов на диск);
• оптимизирован механизм получения результата для запросов с использованием «…ORDER BY … LIMIT…» (т. н., Top-N sorting): в некоторых случаях система удерживает необходимые страницы данных в оперативной памяти, что обеспечивает очень высокую скорость выдачи результата;
• теперь можно задавать (пока только в виде двух констант) оценочную стоимость выполнения фунции и оценку количества рядов, которые она возвращает, что позволяет планнеру PostgreSQL выбирать лучший план запроса (пример: ALTER FUNCTION log_data(text) COST 100000 ROWS 1).

Разработчикам баз данных

Самое заметное и существенное изменение, которое следует здесь отметить, — это миграция модуля для полнотекстового поиска (contrib/tsearch2) в ядро системы. Разрабатываемый российскими разработчиками Олегом Бартуновым и Фёдором Сигаевым, tsearch2 долгое время являлся самым популярным contrib-модулем Постгреса. Патч для миграции полнотекстового поиска в ядро, который был принят этим летом в результате кропотливой и продолжительной работы (принятая версия патча — 58!) сразу нескольких ключевых разработчиков команды PostgreSQL, является самым большим за всю историю проекта.

Кроме того, что все возможности модуля tsearch2 теперь будут доступны по умолчанию и процессы миграции на новую версию PostgreSQL заметно упростятся, конфигурировать словари и правила обработки текстов теперь станет проще: все основные операции по конфигурированию осуществляются с помощью SQL-команд. Вот так, например, можно создать простой словарь-тезаурус:

СREATE TEXT SEARCH DICTIONARY thesaurus_astro ( 
    TEMPLATE = thesaurus, 
    DictFile = thesaurus_astro, 
    Dictionary = english_stem 
); 
ALTER TEXT SEARCH CONFIGURATION russian 
    ADD MAPPING FOR lword, lhword, lpart_hword 
        WITH thesaurus_astro, english_stem;

Упростились и процессы создания индекса. Пример создания GIN-индекса над обычным текстовым столбцом (без создания дополнительных столбцов и триггеров):

CREATE INDEX pgweb_idx ON pgweb 
    USING gin(to_tsvector('russian', title || body));

А вот пример запроса с ранжированием по релевантности, использующий к тому же специальную функцию plainto_tsquery для получения tsquery (позволяет забыть об экранировании символов и быстро и просто преобразовать обычный текст в tsquery):

SELECT 
    ts_rank_cd(textsearch_index, q) AS rank, title 
FROM 
    pgweb, plainto_tsquery('supernova star') q 
WHERE 
    q @@ textsearch_index 
ORDER BY 
    rank DESC LIMIT 10;

Другое заметное изменение — поддержка XML, в работе над которой принимал участие автор данной статьи. Данный функционал реализован в соответствии со стандартом SQL:2003 (14-я часть стандарта, SQL/XML).

Прежде всего, появился специальный тип данных xml, встроенный в ядро. При использовании данного типа, сервер проверяет, правильно ли сформированы данные (проверка на well-formedness). Причём возможны варианты использования, при которых разрешена работа с частями документа (это позволяет обеспечить свойство «замкнутости» функций для работы с XML на тип данных xml).

В соответствии со стандартом SQL:2003 реализован набор функций для преобразования реляционных данных в XML (т. н., функции публикации SQL/XML). Вот простой пример запроса на формирование XML-данных:

SELECT XMLROOT ( 
   XMLELEMENT ( 
      NAME 'some', 
      XMLATTRIBUTES ( 
         'val' AS 'name', 
         1 + 1 AS 'num' 
      ), 
      XMLELEMENT ( 
         NAME 'more', 
         'foo' 
      ) 
   ), 
   VERSION '1.0', 
   STANDALONE YES 
);

Кроме того, реализована поддержка DTD-валидации (функция xmlvalidatedtd()), поддержка оценки XPath-выражений (функция xpath(), возвращающая массив из данных типа xml ), и альтернативные функции для упрощённой публикации реляционных данных в виде XML (функции tabletoxml(), querytoxml() и другие).

Для ускорения выполнения запроса к XML-данным возможно использование функциональных btree-индексов и GIN-индексов, а также использования полнотекстового поиска для XML-данных. Приведём пример создания btree-индекса по результатам оценки XPath-выражения:

CREATE INDEX i_table1_xdata ON table1 USING btree( 
   ((xpath(’//person/@name’, xdata))[1]) 
);

Что касается типов данных, PostgreSQL 8.3 представляет целый ряд нововведений: помимо встроенных в ядро системы типов tsquery/tsvector и xml, появились следующие:

• enum (перечислимые типы данных, определяемые пользователем) для удобства некоторых пользователей, в том числе мигрирующих с TheirSQL;
• типы данных GUID/UUID (в виде contrib-модуля);
• массивы составных типов (например, определённых пользователем типов).

И наконец, краткий список остальных изменений:

• автоматическая инвалидация кэша плана запросов для PL/pgSQL-функций;
• конструкции «CREATE FUNCTION … RETURNS TABLE» и «RETURN TABLE…» для создания функций, результатом которых является таблица;
• поддержка операции обновления для курсоров;
• стандартная (ISO/ANSI SQL) конструкция «ORDER BY … NULLS FIRST/LAST» для упрощения установки порядка следования NULL-значений (также помогает при миграции с других СУБД);
• индексация NULL-значений в GiST-индексах.

Администраторам баз данных

Данный раздел получился куцым, ибо многое из того, что призвано улучшить жизнь DBA, описано выше :-) Тем не менее, расскажем кратко о том, что осталось.

В планах запросов (команда EXPLAIN ANALYZE) теперь видно, какой именно алгоритм сортировки был выбран и сколько памяти было израсходовано:

                       QUERY PLAN 
------------------------------------------------------- 
 Sort (cost=34.38..34.42 rows=13 width=176) (actual time=0.946..0.948 rows=6 loops=1) 
   Sort Key: obj2tag.o2t_tag_name 
   Sort Method: quicksort Memory: 18kB           <-- см. сюда! 
   -> Hash Join (cost=19.19..34.14 rows=13 width=176) (actual time=0.812..0.835 rows=6 loops=1) 
[...]

Специальный contrib-модуль pg_standby, написанный Саймоном Ригсом (Simon Riggs) упростит работу администраторам, настраивающим сервер «тёплого бэкапа» (Warm Standby) на основе трансфера журнала логов (WAL transfer). Модуль написан на чистом C, поэтому является легко расширяемым и портируемым на новые платформы (работоспособность проверена уже, по крайней мере, на Linux и Win32).

При определении функции теперь можно переопределять переменные окружения, которые будут действовать только в рамках выполнения данной функции (привязка значений переменных функциям). Например, вот так можно указать, что выполнение функции log _data() переключает транзакцию в режим асинхронности:

    ALTER FUNCTION log_data(text) 
        SET synchronous_commit TO OFF;

Ну и, по традиции, краткий список других новинок данного раздела:

• поддержка интерфейса GSSAPI;
• улучшенная сборка на платформе Win32 (теперь не требуется MinGW, сборка ведётся в MS VC++, что помимо прочего приводит к улучшению производительности в Windows);
• создание таблиц по подобию с учётом индексов (пример: CREATE TABLE dict2 (LIKE dictionary INCLUDING INDEXES)).

Дополнительные проекты

Компания EnterpriseDB (сотрудники которой являются активным разработчиками PostgreSQL, многие изменения версии 8.3 в области производительности являются именно их заслугой) выпустила отладчик pldebugger, который представляет собой contrib-модуль, позволяющий отлаживать PL/pgSQL-функции в стандартном инструменте для администрирования pgAdminIII и осуществлять профайлинг.

Проект в данный момент существует в виде независимого contrib-модуля (представлен на PgFoundry) и работает на большом количестве платформ (включая Linux и Win32). Стоит отметить, что данный модуль работает и с версией 8.2 Постгреса.

Как мы рассказывали не так давно, компания Skype (которая использует в широко известном одноимённом проекте именно PostgreSQL) выпустила в Open Source сразу несколько продуктов, которые могут быть полезны большому кругу разработчиков. Среди них прежде всего стоит отметить псевдо-язык PL/Proxy, позволяющий организовывать горизонтальное масштабирование практически без ограничений (при условии, если вся бизнес-логика приложения реализована в виде хранимых процедур), чрезвычайно лёгкий менеджер соединений PgBouncer. Загляните на страничку Skype Developers Zone, вы найдёте много интересного!

На рубеже весны и лета 2007-го года вышла версия 1.0 простого и удобного инструмента для анализа логов pgFouine. Данная программа поможет вам узнать, чем же занимался ваш процессор (процессоры) сервера баз данных. pgFoiune анализирует логи запросов Постгреса (при включении журнализации запросов рекомендуется вводить ограничение по времени снизу, см. описание параметра log_min_duration_statement), предоставляя отчёты по самым медленным запросам, ошибкам и общую статистику (см. примеры). Тем самым данный инструмент позволяет разработчику баз данных понять, какие запросы можно улучшить, чтобы ускорить работу приложения, использующего PostgreSQL.

И наконец, кратко об остальных продуктах:

• проект pgSNMP является реализацией SNMP-агента для PostgreSQL (мониторинг состояния сервера);
• SEPostgres – расширение, основанное на модели обеспечения усиленной безопасности SELinux;
• создан инструмент, создающий рекомендации администратору баз данных по созданию индексов и показывающий возможный план выполнения запроса при условии наличия таких индексов (Index Advisor);
• в известном инструменте для web-администрирования phppgadmin появились (или вот-вот появятся) возможности настройки Slony-кластера, полнотекстового поиска, параметров автовакуума.

Заключение

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

При написании данного обзора автор использовал следующие источники:

• pgwiki/WhatsNew83
• pgwiki/Feature_Matrix
• pgwiki/8.3_Changelog
• pgwiki/Todo:PatchStatus
• Доклад Брюса Момджана на конференции Highload-2007, Москва (pdf).
• Официальная документация PostgreSQL 8.3.
• Архив рассылки pgsql-hackers.