TL; DR
Ввод / вывод хранилища - это ваше основное узкое место + недостаточно ОЗУ для индексов, поскольку вы можете просто рассчитать сами:
Для сканирования кучи растрового изображенияВы можете рассчитать среднюю задержку чтения блока ~ 2,5 миллисекунды (чтение 17020 блоков за 41971,798 мс), что слишком медленно.
Единственный способ избежать чтения с диска - это много оперативной памяти.Более быстрое хранение сделает систему гораздо более масштабируемой, поскольку, скорее всего, это не единственный тип запросов и не единственная таблица в базе данных.
Длинная версия :
Считывание идеального результата EXPLAIN указывает на то, что оценка затрат, выполненная планировщиком, далека, и падение производительности происходит из-за операций чтения с диска.
Как вы писали, данные не изменяются со временем (и, следовательно, вы заранее знаете диапазоны значений) вы также можете разбить таблицу по этим двум столбцам, чтобы затем сканировать только определенный раздел (используя меньшие индексы и читая меньшую кучу таблиц).Но если приложение, получающее доступ к этим данным, в конечном итоге получает доступ ко всему диапазону данных в большей или меньшей степени, это тоже не очень поможет.
В результате вам следует подумать о замене подсистемы хранения, чтобы иметь возможность обрабатывать ваши данные.запросы в рамках требований к производительности, которые есть у вашего приложения.
У меня есть подозрение, что сервер PostgreSQL по-прежнему работает на жестком диске, а не на твердотельном накопителе.Небольшой тест с только 120M строками показывает следующие характеристики для обоих индексов:
create table nums (uid integer primary key, id_1 integer, id_2 integer, d1 integer, d2 integer, d3 integer, d4 integer, d5 integer, d6 integer, d7 integer, d8 integer, d9 integer, d10 integer, d11 integer, d12 integer, d13 integer, d14 integer, d15 integer, d16 integer, d17 integer);
INSERT INTO nums select generate_series(80000001, 200000000) AS uid, (random() * 23000)::integer + 5600000 AS id_1, (random() * 25000)::integer + 5600000 AS id_2, (random() * 1000)::integer AS d1, (random() * 1000)::integer AS d2, (random() * 1000)::integer AS d3, (random() * 1000)::integer AS d4, (random() * 1000)::integer AS d5, (random() * 1000)::integer AS d6, (random() * 1000)::integer AS d7, (random() * 1000)::integer AS d8, (random() * 1000)::integer AS d9, (random() * 1000)::integer AS d10, (random() * 1000)::integer AS d11, (random() * 100)::integer AS d12, (random() * 100)::integer AS d13, (random() * 100)::integer AS d14, (random() * 100)::integer AS d15, (random() * 100)::integer AS d16, (random() * 100)::integer AS d17;
create index id_1_idx on nums (id_1);
create index id_2_idx on nums (id_2);
cluster nums using id_1_idx;
..., что приводит к следующему (оба холодных чтения):
explain (analyze, buffers) select * from nums where id_1 = 5606001;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Index Scan using id_1_idx on nums (cost=0.57..5816.92 rows=5198 width=80) (actual time=1.680..6.394 rows=5185 loops=1)
Index Cond: (id_1 = 5606001)
Buffers: shared read=88
I/O Timings: read=4.397
Planning Time: 4.002 ms
Execution Time: 7.475 ms
(6 rows)
Time: 15.924 ms
... идля id_2:
explain (analyze, buffers) select * from nums where id_2 = 5606001;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Index Scan using id_2_idx on nums (cost=0.57..5346.53 rows=4777 width=80) (actual time=0.376..985.689 rows=4748 loops=1)
Index Cond: (id_2 = 5606001)
Buffers: shared hit=1 read=4755
I/O Timings: read=972.555
Planning Time: 0.203 ms
Execution Time: 986.590 ms
(6 rows)
Time: 987.296 ms
Так что, хотя моя таблица "просто", 12 ГиБ + 3x 2,5 ГиБ (PK + 2 индекса) все еще достаточно быстр.
В случае, если серверуже работает на SSD, убедитесь, что (физически) разделите хранилище данных для WAL / журнала, табличных данных (табличное пространство), индексов (табличное пространство), чтобы максимально использовать параллелизм и уменьшить помехи ввода-вывода, вызванные другими службами/ Приложения в той же системе.
Также подумайте о серверной системе с гораздо большим объемом памяти для таблицы и данных индекса (для этой таблицы ~ 48 ГиБ + ~ 10 ГБ на индекс, при условии, что все integer столбцы)а затем выполните прогрев, чтобы перенести данные с диска в память.По крайней мере, индексы должны полностью оставаться в памяти.
EDIT : причина, по которой мой сервер не использует растровое сканирование (индекс + куча), заключается в том, что яЯ работаю на SSD, и я изменил стоимость случайной страницы со значения по умолчанию 4 до 1.1.Для системы с жесткими дисками это, конечно, не имеет смысла.
EDIT # 2 : повторное тестирование ситуации выявило интересное поведение:
В моем тестеЯ предположил, что первый столбец uid является столбцом первичного ключа и является serial (последовательным целым числом), по которому записи первоначально сортируются на диске.При генерации данных значения для обоих интересных индексированных столбцов id_1 и id_2 генерируются случайным образом, что обычно заканчивается худшим случаем для больших таблиц.
Однако в данном случае это не так.После создания тестовых данных и индексов и после анализа таблицы , но до переупорядочивание данных с использованием индекса по столбцу id_1 Теперь я получаю следующие результаты:
explain (analyze, buffers) select * from nums where id_1 = 5606001;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on nums (cost=63.32..7761.68 rows=5194 width=80) (actual time=1.978..41.007 rows=5210 loops=1)
Recheck Cond: (id_1 = 5606001)
Heap Blocks: exact=5198
Buffers: shared read=5217
I/O Timings: read=28.732
-> Bitmap Index Scan on id_1_idx (cost=0.00..62.02 rows=5194 width=0) (actual time=1.176..1.176 rows=5210 loops=1)
Index Cond: (id_1 = 5606001)
Buffers: shared read=19
I/O Timings: read=0.124
Planning Time: 7.214 ms
Execution Time: 41.419 ms
(11 rows)
...and:
explain (analyze, buffers) select * from nums where id_2 = 5606001;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on nums (cost=58.52..7133.04 rows=4768 width=80) (actual time=7.305..43.830 rows=4813 loops=1)
Recheck Cond: (id_2 = 5606001)
Heap Blocks: exact=4805
Buffers: shared hit=12 read=4810
I/O Timings: read=28.181
-> Bitmap Index Scan on id_2_idx (cost=0.00..57.33 rows=4768 width=0) (actual time=5.102..5.102 rows=4813 loops=1)
Index Cond: (id_2 = 5606001)
Buffers: shared read=17
I/O Timings: read=2.414
Planning Time: 0.227 ms
Execution Time: 44.197 ms
(11 rows)
Все планы и оптимизации доступны здесь:
Я также следовал своим собственным рекомендациям и выделил индексы для другого табличного пространства на другом физическом твердотельном накопителе.
Как мы можем видеть, чтобы получить ~ 5000 результирующих строк, которые у него естьчтобы прочитать более или менее одинаковое количество блоков здесь, в обоих случаях используется сканирование кучи растрового изображения.
Корреляция для двух столбцов в этом случае:
attname | correlation | n_distinct
---------+-------------+------------
id_1 | -0.0047043 | 23003
id_2 | 0.00157998 | 25004
Теперь, повторный тест запросов после , CLUSTER ... USING id_1_idx и после повторного анализа, что приводит к следующей корреляции:
attname | correlation | n_distinct
---------+--------------+------------
id_1 | 1 | 22801
id_2 | -0.000898521 | 24997
... показал следующие выступления:
explain (analyze, buffers) select * from nums where id_1 = 5606001;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Index Scan using id_1_idx on nums (cost=0.57..179.02 rows=5083 width=80) (actual time=2.604..5.256 rows=5210 loops=1)
Index Cond: (id_1 = 5606001)
Buffers: shared read=90
I/O Timings: read=4.107
Planning Time: 4.039 ms
Execution Time: 5.563 ms
(6 rows)
... что намного лучше - как и ожидалось - но:
explain (analyze, buffers) select * from nums where id_2 = 5606001;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on nums (cost=58.57..7140.12 rows=4775 width=80) (actual time=5.866..99.707 rows=4813 loops=1)
Recheck Cond: (id_2 = 5606001)
Heap Blocks: exact=4806
Buffers: shared read=4823
I/O Timings: read=31.389
-> Bitmap Index Scan on id_2_idx (cost=0.00..57.38 rows=4775 width=0) (actual time=2.992..2.992 rows=4813 loops=1)
Index Cond: (id_2 = 5606001)
Buffers: shared read=17
I/O Timings: read=0.338
Planning Time: 0.210 ms
Execution Time: 100.155 ms
(11 rows)
... более чем в в два раза медленнее , несмотря на то, что нужно было прочитать почти такое же количество блоков, как в первом случайном прогоне.
Почему он так сильно тормозит?
Физическое переупорядочение данных таблицы с использованием индекса id_1_idx также повлияло на физический порядок столбца. Теперь цель сканирования кучи растрового изображения - получить список блоков для чтения в физическом (на диске) порядке из сканирования растрового индекса. В первом случае (случайном) была довольно высокая вероятность того, что несколько строк, соответствующих критериям, были расположены в последовательных блоках на диске, что привело к уменьшению случайного доступа к диску.
Интересно (но это может быть только потому, что я работаю на SSD), отключение растрового сканирования показало приемлемые цифры:
explain (analyze, buffers) select * from nums where id_2 = 5606001;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Index Scan using id_2_idx on nums (cost=0.57..7257.12 rows=4775 width=80) (actual time=0.151..35.453 rows=4813 loops=1)
Index Cond: (id_2 = 5606001)
Buffers: shared read=4823
I/O Timings: read=30.051
Planning Time: 1.927 ms
Execution Time: 35.810 ms
(6 rows)
Все эти числа являются почти полными операциями холодного запуска (как вы можете видеть без или с очень низкими Buffers: shared hit числами.
Интересно также то, что временные интервалы ввода-вывода очень похожи между сканированием растрового изображения и сканированием индекса для id_2, но сканирование растрового изображения, кажется, вносит огромные издержки.