PostgreSQL в высоконагруженных проектах

PostgreSQL в высоконагруженных проектах
Васильев Алексей Юрьевич
leopard.in.ua
Ноябрь 2010
Васильев О.Ю. PostgreSQL в высоконагруженных проектах

Что такое PostgreSQL?
Введение
PostgreSQL — свободная объектно-реляционная система
управления базами данных (СУБД).
Почему PostgreSQL?
Надежность;
Поддержка БД практически неограниченного размера;
Мощные и надёжные механизмы транзакций и репликации;
Наследование;
Легкая расширяемость;

Введение
Производительность в PostgreSQL
Не используйте настройки
по умолчанию
Используйте актуальную
версию сервера
Тесты производительности
служат для продвижения
конкретных продуктов

Настройка сервера
Используемая память:
shared_buffers, work_mem,
maintenance_work_mem
Журнал транзакций и
контрольные точки:
checkpoint_segments, fsync

Настройка сервера
Планировщик запросов:
default_statistics_target,
effective_cache_size,
random_page_cost
Сбор статистики:
track_counts,
track_functions,
track_activities

Выбор оптимальных настроек
Метод сравнительного
тестирования
pgtune — настройки по
«железу»

Диски и файловые системы
Диски: перенос журнала
транзакций, RAID
Файловые системы: Ext3,
Ext4, ReiserFS, XFS

Оптимизация БД и приложения
Граммотное
проектирование базы
Наличие быстрых путей
доступа к данным —
индексов
Обход известных проблем

Что такое масштабирование?
Масштабирование PostgreSQL
Масштабирование — это
процесс обеспечения роста
системы, т.е.
масштабируемости. В свою
очередь,
масштабируемость — это
свойство системы, сохраняя
пропускную способность,
справляться с увеличением
нагрузки при увеличении
определенных ресурсов
системы.

Проблемы
Ограничение пропускной
способности чтения
данных
Ограничение пропускной
способности записи данных

Подходы
Вертикальное
масштабирование
Горизонтальное
масштабирование

Методы
Партиционирование (секционирование) таблиц
Репликация
Шардинг

Партиционирование (секционирование) таблиц
Партиционирование (секционирование) — это разбиение
больших структур баз данных (таблицы, индексы) на меньшие
кусочки. PostgreSQL поддерживает два критерия для создания
партиций:
Партиционирование по диапазону значений (range)
Партиционирование по списку значений (list)

Методы деления данных на партиции

Партиционирование в PostgreSQL

Ошибка партиционирования
CHECK ( outletID BETWEEN 100 AND 200 )
CHECK ( outletID BETWEEN 200 AND 300 )
Какой партиции принадлежит число 200?

Репликация —механизм
синхронизации содержимого
нескольких копий объекта
(например, содержимого базы
данных). Утилиты для
создания репликации в
PostgreSQL:
Slony-I
pgpool-I/II
Bucardo
Londiste
RubyRep
Потоковая репликация

Slony-I
Особенности:
Мастер/слейв репликация
Работа через триггеры
Возможность потабличной
репликации
Поддержка каскадной
Поддержка
отказоустойчивости
Недостатки:
Сложная настройка
Добавление узла —
трудоемкая операция
Таблицы должны иметь
primary key

Londiste
Возможность
двухстороннего сравнения
таблиц
Простота установки и
настройки
Отсутствие каскадной
Отсутствие

Bucardo
Мастер/мастер или
Поддержка каскадной
Perl, требуется Pl/PgSQL и
Pl/PerlU

RubyRep
Мастер/мастер или
Простота установки и
настройки
Ruby, «поедает» память и
процессор при больших
объемах данных

Streaming Replication (Потоковая репликация)
Из коробки начиная с 9
версии PostgreSQL
Работа через WAL логи
Реплицируется инстанс
PostgreSQL, а не отдельная
база данных (создается
точная копия инстанса
СУБД)
Отдельно базу данных
реплицировать нельзя

PgPool-II
PgPool-II это прослойка,
работающая между серверами
PostgreSQL и клиентами СУБД
PostgreSQL. Она предоставляет
следующие функции:
Объединение соединений
Балансировка нагрузки
Ограничение лишних
соединений
Параллельные запросы
Кеширование запросов

PgPool-II репликация
Минус — падение производительности (синхронная репликация,
блокировка таблицы)

Пример решения проблемы чтения данных
Создание кластера PostgreSQL для решения проблемы чтения
данных:
PgPool-II 3 + PostgreSQL 9

Взаимодействие PgPool-II 3 с PostgreSQL 9
PgPool-II 3 и PostgreSQL 9
Недостатки потоковой репликации в PostgreSQL 9:
Отсутствие отказоустойчивости
Нет пулов соединений
Нет балансировки нагрузки
Нужно учитывать, какие запросы не принимают слейвы
(INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE и
т.д.)

Взаимодействие PgPool-II 3 с PostgreSQL 9

Плюсы и минусы
Плюсы:
Производительность записи падает незначительно
Отказоустойчивость
Пулы соединений
Балансировка нагрузки — увеличение производительности
на чтение
Минусы:
Асинхронная репликация — хоть и задержка репликации
относительно низкая, могут возникать проблемы при
балансировке

Новые возможности в pgpool-II 3
Новый параметр «sub_mode» для потоковой репликации
Отправка на мастер запросов на запись
Интеллектуальная балансировка нагрузки: проверка
задержки репликации между мастером и слейвом.
Добавление слейвов без остановки pgpool-II

Обнаружение задержки репликации
Обнаружение задержки репликации: как это работает?
(SELECT pg_current_xlog_location())
-
(SELECT pg_last_xlog_receive_location())
=
если результат превышает «delay_threshold» — запрос
отправляется на мастер.

Логирование задержки репликации
Параметр «log_standby_delay» может быть:
none: не логировать задержку
if_over_threshold: логировать, если результат превысил
delay_threshold
always: всегда логировать задержку

Итог
Простота в настройке и
обслуживании
Мы можем добавлять
слейв сервера без потери
производительности на
запись
Больше слейв серверов —
больше
производительность на
чтение
Низкая задержка
репликации между
мастером и слейвом

Шардинг
Шардинг — разделение
данных на уровне ресурсов.
Концепция шардинга
заключается в логическом
разделении данных по
различным ресурсам исходя из
требований к нагрузке.
Утилиты для создания
шардинга в PostgreSQL:
PL/Proxy
Sequoia
GridSQL for EnterpriseDB
Advanced Server
Greenplum Database
HadoopDB

Узкие места в PostgreSQL
Мультиплексоры соединений
(программы для создания
пула коннектов) — позволяют
уменьшить накладные расходы
на базу данных, в случае, когда
огромное количество
физических соединений ведет к
падению производительности
PostgreSQL.
PgBouncer
Pgpool

PgBouncer
Это мультиплексор соединений для PostgreSQL от компании
Skype. Существуют три режима управления:
Session Pooling. Наиболее «вежливый» режим. При
начале сессии клиенту выделяется соединение с сервером
и приписано ему в течение всей сессии.
Transaction Pooling. Клиент владеет соединением с
бакендом только в течение транзакции.
Statement Pooling. Наиболее агрессивный режим.
Соединение с бакендом возвращается назад в пул сразу
после завершения запроса.

Кэширование в PostgreSQL
Узкие места в PostgreSQL
Из коробки данный фукционал не доступен (теряем
транзакционную чистоту происходящего в базе). Но есть такие
средства как:
pgmemcache
pgpool-II (query cache)

Pgmemcache
Кэширование в PostgreSQL
Pgmemcache — это
PostgreSQL API библиотека на
основе libmemcached для
взаимодействия с memcached.

Анализирование SQL запросов
EXPLAIN [ANALYZE]
pgFouine — это анализатор
log-файлов для PostgreSQL
COPY vs INSERT на
больших объемах данных

EXPLAIN ME!
Использование полного просмотра таблицы (seq scan)
Использование наиболее примитивного способа
объединения таблиц (nested loop)
EXPLAIN ANALYZE: нет ли больших отличий в
предполагаемом количестве записей и реально выбранном?
Запрет оптимизатору использовать определённые планы
выполнения для более точного анализа (SET
enable_seqscan=false)

PgFouine
ТОП SQL
запросов по
времени
выполнения
ТОП SQL
запросов по
частоте
выполнения

B-деревья
Оптимизация структуры БД

Функциональные индексы
Индекс:
CREATE INDEX foo_name_first_idx ON foo
((lower(substr(foo_name, 1, 1))));
будет использоваться запросами вида:
SELECT * FROM foo WHERE lower(substr(foo_name, 1, 1)) =
’д’;

Частичные индексы (partial indexes)
Индекс:
CREATE INDEX access_log_client_ip_ix ON access_log
(client_ip) WHERE NOT (client_ip > inet ’192.168.100.0’ AND
client_ip < inet ’192.168.100.255’);
будет использоваться запросами вида:
SELECT * FROM access_log WHERE url = ’/index.html’ AND
client_ip = inet ’212.78.10.32’;

Медленный count
Оптимизация SQL запросов
Проблема
SELECT count(*) FROM <огромная таблица>

Проблема
SELECT count(*) FROM <огромная таблица>
Как решить проблему?
Простого решения проблемы, к сожалению, нет :(

Решение номер один: приблизительное количество
CREATE FUNCTION count_estimate ( query t e x t )
RETURNS integer AS $$
DECLARE
r e c r e c o r d ;
rows integer ;
BEGIN
FOR r e c IN EXECUTE ’EXPLAIN ’ | | query LOOP
rows := substring ( r e c . "QUERY PLAN" FROM ’
rows = ( [ [ : d i g i t : ] ] + ) ’ ) ;
EXIT WHEN rows IS NOT NULL;
END LOOP;
RETURN rows ;
END;
$$ LANGUAGE p l p g s q l VOLATILE STRICT ;

Простой count. Время выполнения - 6,29 сек
psql_platform=# Select count (∗) from s u b s c r i b e r _ e m a i l s ;
count
−−
−−−−−−−−
24449994
(1 row )
Приблизительный count. Время выполнения - 0,08 сек(!!!)
psql_platform=# SELECT count_estimate ( ’ S e l e c t ∗
from s u b s c r i b e r _ e m a i l s ’ ) ;
count_estimate
−−
−−−−−−−−−−−−−−
24450000
(1 row )

Вариант без создания функции
psql_platform=# SELECT ( r e l t u p l e s ) : : integer FROM pg_class r
WHERE r e l k i n d = ’ r ’ AND relname = ’ s u b s c r i b e r _ e m a i l s ’ ;
count_estimate
−−
−−−−−−−−−−−−−−
24450000
(1 row )

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

Вариант номер два
Завести вспомогательную таблицу, хранящую число записей в
огромной таблице. На огромную таблицу повесить триггер,
который будет уменьшать это число в случае удаления записи
и увеличивать в случае вставки.
Вариант номер три
Повторяем вариант номер два, но данные во вспомогательной
таблице обновляются через определённые промежутки времени
(cron), а не через триггер.

Медленный DISTINCT
Проблема. Время выполнения - 12,34 сек
psql_platform=# Select DISTINCT( campaign_id ) from s u b s c r i b e r s
ORDER BY campaign_id ;

Медленный DISTINCT
Проблема. Время выполнения - 12,34 сек
psql_platform=# Select DISTINCT( campaign_id ) from s u b s c r i b e r s
ORDER BY campaign_id ;
Решение. Время выполнения - 4,04 сек
psql_platform=# Select campaign_id from s u b s c r i b e r s
ORDER BY campaign_id GROUP BY campaign_id ;

Вопросы и Ответы
Спасибо за внимание!

PostgreSQL в высоконагруженных проектах

More Related Content

What's hot

Viewers also liked

Similar to PostgreSQL в высоконагруженных проектах

PostgreSQL в высоконагруженных проектах