Нужно предложение о том, как обрабатывать большие таблицы в PostgresSQL - PullRequest
0 голосов
/ 09 января 2019

У меня есть таблица размером 32 ГБ, а размер индекса в Postgres составляет около 38 ГБ.

У меня есть столбец x, который не проиндексирован. Размер таблицы растет на 1 ГБ в неделю. В столбце x.

выполняется много запросов.

Каждый запрос в этой таблице для столбца x потребляет 17% моего процессора и занимает прибл. 5 ~ 6 секунд для возврата данных с большой нагрузкой на базу данных.

Каков наилучший способ справиться с этим? что такое отраслевой стандарт?

Я проиндексировал столбец x, а размер индекса увеличился на 2 ГБ & mdash; Время запроса уменьшено до ~ 100 мс.

Я смотрю в DynamoDB для репликации данных таблицы, но я не уверен, что это правильный путь, отсюда и этот вопрос.

Я хочу, чтобы доступ к данным был более быстрым, учитывая также, что это должно стать узким местом в функции.

В соответствии с запросом здесь выполняется запрос:

database_backup1=> EXPLAIN ANALYZE SELECT * FROM "table_name" WHERE "table_name"."x" IN ('ID001', 'ID002', 'ID003', 'ID004', 'ID005') LIMIT 1;

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
 Limit  (cost=0.00..56442.83 rows=100 width=1992) (actual time=0.010..155288.649 rows=7 loops=1)
   ->  Seq Scan on "table_name"  (cost=0.00..691424.62 rows=1225 width=1992) (actual time=0.009..155288.643 rows=7 loops=1)
         Filter: ((x)::text = ANY ('{ID001,ID002,ID003,ID004,ID005}'::text[]))
         Rows Removed by Filter: 9050574
 Planning time: 0.196 ms
 Execution time: 155288.691 ms
(6 rows)

1 Ответ

0 голосов
/ 11 января 2019

План выполнения указывает на то, что ваш индекс - это верный путь.

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

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

...