• 1.1 Не используйте настройки по умолчанию
• 1.2 Используйте актуальную версию сервера
• 1.3 Стоит ли доверять тестам производительности

1 Введение

Скорость работы, вообще говоря, не является основной причиной использования реляционных СУБД. Более того, первые реляционные базы работали медленнее своих предшественников. Выбор этой технологии был вызван скорее

• возможностью возложить поддержку целостности данных на СУБД;
• независимостью логической структуры данных от физической.

Таким образом, прежде, чем искать ответ на вопрос «как заставить РСУБД работать быстрее в моей задаче?» следует ответить на вопрос «нет ли более подходящего средства для решения моей задачи, чем РСУБД?» Иногда использование другого средства потребует меньше усилий, чем настройка производительности.

Данная статья посвящена возможностям повышения производительности свободной РСУБД PostgreSQL. Статья не претендует на исчерпывающее изложение вопроса, наиболее полным и точным руководством по использованию PostgreSQL является, конечно, официальная документация [1] и официальный FAQ [2]. Также существует англоязычный список рассылки postgresql-performance, посвящённый именно этим вопросам.

Статья состоит из двух разделов, первый из которых ориентирован скорее на администратора, второй -- на разработчика приложений. Рекомендуется прочесть оба раздела: отнесение многих вопросов к какому-то одному из них весьма условно. Большая часть раздела, посвящённого настройке сервера, является переводом материалов [3], [4], [5]. В разделе, посвящённом оптимизации БД и приложения, использовались [6], [7], [8] и личный опыт.

1.1 Не используйте настройки по умолчанию

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

Настройки по умолчанию подходят только для следующего использования: с ними вы сможете проверить, работает ли установка PostgreSQL, создать тестовую базу уровня записной книжки и потренироваться писать к ней запросы. Если вы собираетесь разрабатывать (а тем более запускать в работу) реальные приложения, то настройки придётся радикально изменить.

В дистрибутиве PostgreSQL, к сожалению, не поставляется файлов с «рекомендуемыми» настройками. Вообще говоря, такие файлы создать весьма сложно, т.к. оптимальные настройки конкретной установки PostgreSQL будут определяться:

• конфигурацией компьютера;
• объёмом и типом данных, хранящихся в базе;
• отношением числа запросов на чтение и на запись;
• тем, запущены ли другие требовательные к ресурсам процессы (например, вебсервер).

1.2 Используйте актуальную версию сервера

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

• В версии 7.1 появился журнал транзакций, до того данные в таблицу сбрасывались каждый раз при успешном завершении транзакции.
• В версии 7.2 появились:
  • новая версия команды VACUUM, не требующая блокировки;
  • команда ANALYZE, строящая гистограмму распределения данных в столбцах, что позволяет выбирать более быстрые планы выполнения запросов;
  • подсистема сбора статистики.
• В версии 7.4 была ускорена работа многих сложных запросов (включая печально известные подзапросы IN/NOT IN).

1.3 Стоит ли доверять тестам производительности

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

При изучении опубликованных тестов в первую очередь обратите внимание, соответствует ли величина и тип нагрузки, объём данных и сложность запросов в тесте тому, что вы собираетесь делать с базой? Пусть, например, обычное использование вашего приложения подразумевает несколько одновременно работающих запросов на обновление к таблице в миллионы записей. В этом случае СУБД, которая в несколько раз быстрее всех остальных ищет запись в таблице в тысячу записей, может оказаться не лучшим выбором.

Ну и наконец, вещи, которые должны сразу насторожить:

• Тестирование устаревшей версии СУБД.
• Использование настроек по умолчанию (или отсутствие информации о настройках).
• Тестирование в однопользовательском режиме (если, конечно, вы не предполагаете использовать СУБД именно так).
• Использование расширенных возможностей одной СУБД при игнорировании расширенных возможностей другой.
• Использование заведомо медленно работающих запросов (см. пункт 3.4).