файла инициализации поверх основного файла (если таблица была большой и содержала несколькосегментов,ониудаляются).Вдокументациинетакмногоинформациипофайлу инициализации1.

Наболеенизкомуровнетаблицыииндексыимеютстраничнуюорганизациюисостоятизстраниц (блоков) по 8 КБ. Каждая такая страница имеет служебные поля и место, зарезервированное под пользовательские данные,—строки,или кортежи.Индексы также имеют страничную организацию,новзависимостиоттипаиндекса(btree,hash,ginипр.)могутпо-разномуструк- турировать место внутри страниц.

TOAST

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

тов TOAST (The Oversized-Attribute Storage Technique), которая заключается в сжатии и/или разбиениидлинных строк.Это происходитавтоматически и прозрачнодля конечного пользователя,хотяотмечу,что возможностидлятонкойнастройкиTOASTимеются.МетодикаTOAST поддерживается только для тех типов данных, которые могут быть представлены атрибутами переменной длины (varlena, variable-length attribute), так как она не имеет смысла для типов фиксированного размера.

Если таблица имеет столбцы с типами переменной длины, с таблицей также будет связана дополнительная TOAST-таблица, в которой и будут размещаться данные, не вмещающиеся в обычные страницы. Как и обычные таблицы, TOAST-таблицы также используют страничную организацию с фиксированным размером страницы, но за счет дополнительного сжатияиразбиениязначенийнафрагментыметодикапозволяетраспределятьбольшиезначения по нескольким страницам. Более подробное описание методики и то, как устроено размещение данных на диске и в памяти,можно прочитать в официальной документации2.

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

4.2. События в кластере баз данных

В главе 3 рабочая нагрузка рассматривалась с точки зрения выполняемых запросов. Запросы условно можно представить как внешнюю силу, направленную от приложений на СУБД, а рабочую нагрузку — как внутреннюю работу, совершаемую СУБД под действием этой силы. Это

1 postgrespro.ru/docs/postgresql/current/storage-init

2 postgrespro.ru/docs/postgresql/current/storage-toast

позволяет взглянуть на рабочую нагрузку совершенно с другой стороны — например, с точки зрения объектов БД (таблиц и индексов), задействованных в рабочей нагрузке при обработке команд от приложений.

Рабочая нагрузка в отношении таблиц и индексов

Еще одной статистикой, которая также характеризует рабочую нагрузку, является статистика по использованию таблиц и индексов. Эта статистика доступна в двух вариантах: на уровне строк и на уровне блоков. Первый вариант представляет собой информацию о том, сколько строк затронуто в результате выполнения запросов. Статистика по строкам является логическим отражением рабочей нагрузки, поскольку указывает на использование логических абстракций СУБД; статистика по блокам, выраженная в страницах или байтах, является более близкой к физическому слою хранения данных и хорошо подходитдля анализа ввода-вывода.

Для получения нужных данных потребуется несколько представлений. Получить общую картинуврамкахкластераилиотдельныхБДможновпредставленииpg_stat_database,вкотором содержится набор необходимых полей:

•tup_returned и tup_fetched—показывают общее количество строк,затронутых при доступе к таблицам и индексам (не количество строк,отданных клиенту!).

—Дляиндексовtup_returnedпоказываетколичествострок,возвращенныхиндексными методами доступа (Index Scan,Bitmap Index Scan,Index Only Scan),а tup_fetched пока-

зывает количество строк, прочитанных при этом из таблицы (но только для простого индексного доступа без битовой карты).

—Для таблиц tup_returned показывает количество прочитанных из таблицы строк при последовательном сканировании (Seq Scan), а tup_fetched показывает количество строк,прочитанных изтаблицы в случаедоступа по битовой карте (Bitmap Heap Scan). Дело втом,что при объединении битовых карт(Bitmap And) статистикудоступа нельзя отнести к какому-то конкретному индексу, поэтому она всегда учитывается в статистике по таблице.

Из приведенного описания видно, что некоторые операции могут увеличивать оба счетчика одновременно, поэтому не стоит суммировать их значения. Также счетчики могут увеличиваться и при операциях обновления и удаления строк (ведь целевую строку тоже нужно найти и прочитать). В представлении pg_stat_database можно получить общую картину по затронутым строкам, а более детальную информацию можно получить, анализируя статистику отдельных таблиц и индексов.

•tup_inserted, tup_updated и tup_deleted — с этими полями все гораздо проще: они содержат количество строк, затронутых операциями INSERT, UPDATE и DELETE, без всяких тонкостей и нюансов.

Эта статистика также подходит для поверхностной оценки колебаний рабочей нагрузки. Из мониторинга ее можно получить с помощью следующих метрик:

108Глава 4. Базы данных

•postgres_database_tuples_returned_total;

•postgres_database_tuples_fetched_total;

•postgres_database_tuples_inserted_total;

•postgres_database_tuples_updated_total;

•postgres_database_tuples_deleted_total.

Каждая метрика возвращает соответствующее значение затронутых строк для отдельной БД. Для наблюдения в динамике следует ориентироваться на частоту изменения величины, и для оценки общей картины метрики отдельных баз следует просуммировать.

Для графика (рис. 4.1) потребуется два запроса: каждая из метрик описывает отдельное действие,связанное со строкой.

#sum(rate(postgres_database_tuples_fetched_total{service_id="primary"}[1m]))

#sum(rate(postgres_database_tuples_returned_total{service_id="primary"}[1m]))

Рис. 4.1.Динамика затронутых (fetched,returned) строк

Аналогичную картину можно получить для строк,затронутых при операциях изменения.Для построения графика (рис. 4.2) потребуются три запроса:

#sum(rate(postgres_database_tuples_inserted_total{service_id="primary"}[1m]))

#sum(rate(postgres_database_tuples_updated_total{service_id="primary"}[1m]))

#sum(rate(postgres_database_tuples_deleted_total{service_id="primary"}[1m]))

Оба графика показываютровную рабочую нагрузкубез сильных колебаний.Это говоритотом, что со стороны приложений количество клиентов и объем запросов более или менее постоянны,и со стороны СУБД количество затрагиваемых строк при выполнении рабочей нагрузки также постоянно.Причиной сильных колебаний можетбытькак изменение количества экземпляров приложений и объема отправляемых запросов, так и внутренние причины, такие как

Рис. 4.2.Динамика вставленных,обновленных и удаленных строк

использованиенеоптимальныхпланов,которыемогутприводитькизменениюколичествазатрагиваемых строк и долгому выполнению запросов.

Для более детального анализа и понимания того, какие именно таблицы затронуты в нагрузке, следует использовать представления pg_stat_user_tables и pg_stat_user_indexes. В этих представлениях содержится больше информации об использовании именно таблиц и индексов.В pg_stat_user_tables интерес представляют следующие поля:

•seq_scan—количество операций последовательного доступа (sequential scan);

•seq_tup_read—количество строк,затронутых в результате выполнения всех операций последовательного доступа;

•idx_scan—количество операций индексного доступа (index scan);

•idx_tup_fetch—количество строк,затронутых индексным доступом;

•n_tup_ins — количество вставленных строк (обычно в результате выполнения INSERTзапросов);

•n_tup_upd — количество обновленных строк, включая и так называемые HOT-обновления (в результате выполнения UPDATE-запросов);

•n_tup_del—количество удаленных строк (в результате выполнения DELETE-запросов);

•n_tup_hot_upd—количество строк,обновленных с использованием механизма HOT (HeapOnly Tuples update) — оптимизации, направленной на уменьшение накладных расходов при обновлении строк. Ее суть состоит в том, что если в результате обновления значения атрибутов не изменились ни в одном индексе, то и вставку индексных указателей можно исключить. За счет этого обновление выполняется быстрее и с меньшими затратами

ресурсов. Количество HOT-обновлений также включено в поле n_tup_upd. Более подробно о механизме HOT можно почитать в некоторых публикациях1,2.

Похожая статистика есть и по индексам в представлении pg_stat_user_indexes:

•idx_scan — количество обращений к данному индексу. Это поле позволяет обнаруживать неиспользуемые индексы,что важно,поскольку их существование не обходится даром;

•idx_tup_read — количество элементов индекса, прочитанных при сканированиях по индексу (без обращения к таблице);

•idx_tup_fetch — количество живых строк таблицы, отобранных при простых сканированиях по индексу.

Стоит разобраться, как работают счетчики idx_tup_read и idx_tup_fetch в случае использования битовых карт индексов. При использовании нескольких индексов результаты сканирования могут объединяться логическим умножением или сложением, и, как следствие, становится невозможно связать выборки отдельных строк с конкретными индексами. В таких случаях увеличиваются значения pg_stat_user_indexes.idx_tup_read для задействованных индексов и счетчики pg_stat_user_tables.idx_tup_fetch для каждой таблицы,а значения pg_stat_user_indexes.idx_tup_fetch не меняются.

В представлениях pg_stat_user_tables и pg_stat_user_indexes собрана статистика по пользовательским таблицам и индексам. По системным объектам статистика собрана в аналогичных представлениях pg_stat_sys_tables и pg_stat_sys_indexes.Эти представления обращаются к двум другим,в которых собрана статистика по всем объектам вместе (pg_stat_all_tables и pg_stat_all_indexes), а они, в свою очередь, основаны на большом наборе функций, которые обращаются к отдельным счетчикам статистики. Перечисленные представления индивидуальны для каждой БД (в отличие от pg_stat_database, которое является общим для всего кластера баз данных).

Давайте рассмотрим возможные сценарии использования этой статистики:

•избыточный последовательный доступ;

•таблицы с наибольшим количеством вставок,обновлений и удалений.

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

1 www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance 2 www.interdb.jp/pg/pgsql07.html

привестикизбыточномуиспользованиюресурсовввода-выводаипроцессора(чтениеифиль- трация строк).

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

Для получения списка таблиц, которые читаются последовательно, можно использовать следующий запрос (подключение должно быть выполнено к БД pgbench):

#SELECT relname, seq_scan, seq_tup_read, idx_scan, idx_tup_fetch FROM pg_stat_user_tables

WHERE seq_scan > 0

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

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

•среднее количество строк за одно сканирование — seq_tup_read / seq_scan. Чем больше строк в среднем, тем больше и ресурсов требуется при сканировании. Но это не значит, что все запросы читают именно среднее количество строк;

•доля последовательных обращений от общего числа обращений — seq_scan /( seq_scan +

+idx_scan ).Чем большедоля,тем больше ресурсов используется при сканировании,однакостоитпомнитьпронебольшиетаблицы,которыемогутполностьюпомещатьсявобщем кеше;

•размер таблицы в байтах позволяет сравнивать таблицы друг с другом. Например, устранениеслучаевпоследовательногодоступакбольшимтаблицамможетбытьприоритетнее, чем к небольшимтаблицам.Определение размеровтаблиц и других объектов БД рассматривается в этой главе чуть дальше.

112Глава 4. Базы данных

Получение этой и подобной статистики с помощью запросов удобно для построения отчетов за периоды, однако для оперативного анализа и поиска проблем важно видеть динамику изменений. Следующим запросом можно получить первые K таблиц по количеству строк, прочитанных при последовательном доступе:

# topk_avg(5, rate(postgres_table_seq_tup_read_total{service_id="primary"}[1m]), "other"

)

Еслинаосновеэтогозапросапостроитьграфик,нанембудетпоказанавсегооднатаблица,что полностью соответствует результату SQL-запроса.

В качестве небольшого эксперимента можно выполнить разовый запрос с чтением всех строк другой таблицы:

# SELECT count(*) FROM pgbench_history; count

--------

486693

Спустя некоторое время на графике появится характерный выброс (рис. 4.3).

Рис. 4.3.Последовательный доступ

Таким образом, с помощью подобного графика можно оперативно отслеживать изменение в динамике последовательного доступа и реагировать должным образом (анализировать запросы к таблице,строить индексы и т. п.).

Таблицыснаибольшимколичествомвставок,обновленийиудалений. Статистикаиспользования таблиц является логическим развитием статистики строк из представления pg_stat_database. Если там мы видели общую статистику уровня баз данных,то с помощью pg_stat_user_tables

можно заглянуть внутрь отдельных БД и более подробно проанализировать таблицы, задействованные в рабочей нагрузке,и оценить объемы затронутых строк.

Представление pg_stat_user_tables является индивидуальным для каждой БД, поэтому, чтобы получить статистику по таблицам в БД pgbench, нужно подключиться именно к этой базе. Следующим запросом можно получить статистику затронутых строк:

В этом примере выведены все пользовательские таблицы в БД pgbench и общее количество строк, затронутое различными операциями; указывая интересующее поле в предложении ORDERBY,можно получитьтаблицы с наибольшим количеством затронутых строк.Однако в выводе снова появляются большие цифры,и на практике удобно отслеживатьэти величины вдинамике. Для этого можно воспользоваться следующими метриками (имена метрик аналогичны названиям полей):

•postgres_table_seq_tup_read_total;

•postgres_table_idx_tup_fetch_total;

•postgres_table_tuples_inserted_total;

•postgres_table_tuples_updated_total;

•postgres_table_tuples_deleted_total;

•postgres_table_tuples_hot_updated_total.

Следующим запросом можно получитьтаблицы с наибольшим количеством обновлений:

# topk_avg(5, rate(postgres_table_tuples_updated_total{service_id="primary"}[1m]), "other"

)

График (рис. 4.4) более наглядно выводит информацию о том, на какие именно таблицы приходится больше всего обновлений.