Início / dba / Perguntas / 317137
Accepted
Gismat Husein
Asked: 2022-09-21 03:50:15 +0800 CST

Como otimizar a cláusula Where com um bilhão de linhas no PostgreSQL?

  • 772

Portanto, esta é a minha primeira experiência com big data. Eu tenho uma ticketing_systemtabela e inseri um bilhão (um bilhão) de dados falsos na tabela.

CREATE TABLE ticketing_system (
    id BIGSERIAL,
    ticket_id UUID not null default uuid_generate_v4(),
    count int,
    created_at timestamptz NOT NULL
);

Eu preciso de uma resposta do Postgresql de cerca de 10-30 ms ao pesquisar a ticket_idcláusula wherewith.Eu criei o índice BRIN CREATE INDEX in_ticketing_system_brin ON ticketing_system USING brin(ticket_id);. Mas isso não está me ajudando.

explain analyze select * from ticketing_system where ticket_id = '09830cb7-37f2-4951-8910-1661b1358b99';
                                                                        QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1217.39..1854198.38 rows=1 width=36) (actual time=997.056..84730.718 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Bitmap Heap Scan on ticketing_system  (cost=217.39..1853198.28 rows=1 width=36) (actual time=56707.851..84601.029 rows=0 loops=3)
         Recheck Cond: (ticket_id = '09830cb7-37f2-4951-8910-1661b1358b99'::uuid)
         Rows Removed by Index Recheck: 46103039
         Heap Blocks: lossy=366097
         ->  Bitmap Index Scan on in_ticketing_system_brin  (cost=0.00..217.39 rows=3544816 width=0) (actual time=153.203..153.209 rows=11525760 loops=1)
               Index Cond: (ticket_id = '09830cb7-37f2-4951-8910-1661b1358b99'::uuid)
 Planning Time: 3.167 ms
 JIT:
   Functions: 6
   Options: Inlining true, Optimization true, Expressions true, Deforming true
   Timing: Generation 12.892 ms, Inlining 491.333 ms, Optimization 92.106 ms, Emission 91.551 ms, Total 687.882 ms
 Execution Time: 84833.538 ms
(15 rows)
postgresql postgresql-performance

2 respostas

  1. Um BRINíndice funciona registrando o mínimo e o máximo de intervalos de bloco. Portanto, não ajuda a menos que os dados tenham algum tipo de tendência, como serem agrupados. No seu caso, ambos HASHou BTREEfunciona. Acredito que um HASHíndice tenha uma pegada de memória menor quando o número de dados for grande, mas esteja ciente de suas limitações (por exemplo, o PostgreSQL não suporta HASHíndices de várias colunas).

    Outra maneira é usar IDs inteiros em vez de UUIDs e criá-los em ordem. Seu SERIALjá funciona como chave primária, mas dependendo do significado de suas colunas, pode ou não fazer sentido selecionar idapenas os dados filtrados.

    • 4
  2. Best Answer

    Um índice BRIN não se encaixa no seu caso e você precisa de um índice de árvore B:

    CREATE INDEX ON ticketing_system (ticket_id);

    Esse índice será muito maior que um índice BRIN, mas não sobrecarregará sua RAM. Independentemente do tamanho do índice, uma verificação de índice usará apenas quantidades insignificantes de memória. Todas as tabelas e índices são armazenados e armazenados em cache em unidades de 8kB, e uma varredura de índice não precisará tocar em muitos deles.

    • 3

relate perguntas