Кстати, а вы уже перевернули календарь?
Буквально на днях нашел вот такую статью: PostgreSQL: the power of a single missing index от CyberTec. Сначала подумал, что у меня что-то с форматированием текста в браузере стало, или даже в источнике косяк какой — всё по левому краю располагалось.
А потом пригляделся — и не смог устоять от перевода, который получился достаточно вольным, кое-какие огрехи в нем есть.
—
Индекс отсутствует?
Когда у вас индекса в базе нет
Быстрая работа не передаст привет
Пользователю Постгресa, эффективности ждущего
Желающего получить её как наследство насущное.
Чтобы удовлетворить жажду и желания ДБА
Загрузим немного данных в БД сначала, да?
Pgbench — инструмент такой все знают,
Следующие строки точнее всё объясняют:
[hs@fedora ~]$ pgbench -s 100 -i test dropping old tables... NOTICE: table "pgbench_accounts" does not exist, skipping NOTICE: table "pgbench_branches" does not exist, skipping NOTICE: table "pgbench_history" does not exist, skipping NOTICE: table "pgbench_tellers" does not exist, skipping creating tables... generating data (client-side)... 10000000 of 10000000 tuples (100%) done (elapsed 9.96 s, remaining 0.00 s) vacuuming... creating primary keys... done in 14.58 s (drop tables 0.00 s, create tables 0.07 s, client-side generate 10.03 s, vacuum 1.68 s, primary keys 2.80 s).
Загрузить миллионы строк в Postgres не сложно
Это простая часть, это всё можно.
На данные, которые так просто создавать
Можно особого внимания и не обращать.
10 секунд для 10 миллионов строк,
Ответственный администратор лучше б не смог.
Производительность будет хорошей,
Как настрой у пользователей — такой же.
Чтобы отпраздновать успех
Запустим БД и посмотрим на текст.
На этот раз мы ищем быстрое чтение,
От чего на высоких скоростях имеем важное впечатление:
[hs@fedora ~]$ pgbench -S -c 10 -T 30 -j 10 test starting vacuum...end. transaction type: <builtin: select only> scaling factor: 100 query mode: simple number of clients: 10 number of threads: 10 duration: 30 s number of transactions actually processed: 3054408 latency average = 0.098 ms initial connection time = 13.872 ms tps = 101859.582811 (without initial connection time)
Pgbench — это название данной игры.
101 тысяча транзакций, это мечты!
30 секунд для выполнения текущего теста,
10 подключений без отдыха и потери коннекта.
Даже 10 потоков для клиентского кода,
Работают сверхбыстро, эффективно и скоро.
Однако это всё благодаря индексам было
Которые привносят производительность и силу.
Без индексации жизнь сурова и люди грустят
Так же, когда оптимально shared_buffers настроить хотят.
Наш святой начальник, Сбалансированный Господин
Без него плохая производительность — это путь номер один.
Единственный отсутствующий индекс для теста,
И вся наша БД будет в состоянии протеста.
Вы хотите знать причину?
Обратимся к Господину:
test=# \d+
List of relations
Schema | Name | Type | Owner | Persistence | Access method | Size | Description
--------+------------------+-------+-------+-------------+---------------+---------+-------------
public | pgbench_accounts | table | hs | permanent | heap | 1281 MB |
public | pgbench_branches | table | hs | permanent | heap | 40 kB |
public | pgbench_history | table | hs | permanent | heap | 0 bytes |
public | pgbench_tellers | table | hs | permanent | heap | 80 kB |
(4 rows)
test=# \d pgbench_accounts
Table "public.pgbench_accounts"
Column | Type | Collation | Nullable | Default
----------+---------------+-----------+----------+---------
aid | integer | | not null |
bid | integer | | |
abalance | integer | | |
filler | character(84) | | |
Indexes:
"pgbench_accounts_pkey" PRIMARY KEY, btree (aid)
И наш единственный индекс убивая…
Скорость помашет крылом улетая:
test=# ALTER TABLE pgbench_accounts DROP CONSTRAINT pgbench_accounts_pkey; ALTER TABLE test=# \d pgbench_accounts Table "public.pgbench_accounts" Column | Type | Collation | Nullable | Default ----------+---------------+-----------+----------+--------- aid | integer | | not null | bid | integer | | | abalance | integer | | | filler | character(84) | | |
Запустим наш тест еще один раз.
Хорошая производительность? Всё без прикрас!
О Боже? Что с моими текущими данными?
Вернется ли скорость, ой как желанная?
[hs@fedora ~]$ pgbench -S -c 10 -T 30 -j 10 test pgbench (14beta2) starting vacuum...end. transaction type: <builtin: select only> scaling factor: 100 query mode: simple number of clients: 10 number of threads: 10 duration: 30 s number of transactions actually processed: 259 latency average = 1189.653 ms initial connection time = 5.727 ms tps = 8.405815 (without initial connection time)
Восемь транзакций в секунду покажет,
Что плохая производительность нас и накажет.
Если у нас один индекс сломают
Все пользователи ходят пешком, не летают.
Начинаем звонить в техподдержку всё чаще и чаще
Администраторы — в бой, углубляйтесь в постгресовые чащи!
Заключение
Какой же итоговый вывод мы сделали?
Убедитесь что присутствуют нужные индексы!
Это очень важный момент
Индексировать нужное — вот и ответ.
Не забывайте о больших и маленьких мелочах —
И производительность будет во всех БД и делах!
Надеюсь, мой стих сделает людей счастливыми.
И убедитесь, что ваши БД стали более быстрыми 🙂
Ханс-Юрген Шёниг (Hans-Jürgen Schönig)
Ханс-Юрген Шениг имеет опыт работы с PostgreSQL с 90-х годов. Он является генеральным директором и техническим руководителем компании CYBERTEC, которая является одним из лидеров рынка в этой области и с 2000 года обслуживает бесчисленное количество клиентов по всему миру.
Еще раз ссылка на оригинал.
Leave a Reply