¿Por qué un índice gin en una columna jsonb ralentiza mi consulta y qué puedo hacer al respecto?

10

Inicializar datos de prueba:

CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE TABLE docs (data JSONB NOT NULL DEFAULT '{}');
-- generate 200k documents, ~half with type: "type1" and another half with type: "type2", unique incremented index and random uuid per each row
INSERT INTO docs (data)
SELECT json_build_object('id', gen_random_uuid(), 'type', (CASE WHEN random() > 0.5 THEN 'type1' ELSE 'type2' END) ,'index', n)::JSONB
FROM generate_series(1, 200000) n;
-- inset one more row with explicit uuid to query by it later
INSERT INTO docs (data) VALUES (json_build_object('id', '30e84646-c5c5-492d-b7f7-c884d77d1e0a', 'type', 'type1' ,'index', 200001)::JSONB);

Primera consulta - filtrar por datos-> tipo y límite:

-- FAST ~19ms
EXPLAIN ANALYZE
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
LIMIT 25;
/* "Limit  (cost=0.00..697.12 rows=25 width=90) (actual time=0.029..0.070 rows=25 loops=1)"
   "  ->  Seq Scan on docs  (cost=0.00..5577.00 rows=200 width=90) (actual time=0.028..0.061 rows=25 loops=1)"
   "        Filter: (data @> '{"type": "type1"}'::jsonb)"
   "        Rows Removed by Filter: 17"
   "Planning time: 0.069 ms"
   "Execution time: 0.098 ms" 
*/

Segunda consulta: filtrar por datos-> tipo, ordenar por datos-> índice y límite

-- SLOW ~250ms
EXPLAIN ANALYZE
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
ORDER BY data->'index' -- added ORDER BY
LIMIT 25;

/* "Limit  (cost=5583.14..5583.21 rows=25 width=90) (actual time=236.750..236.754 rows=25 loops=1)"
   "  ->  Sort  (cost=5583.14..5583.64 rows=200 width=90) (actual time=236.750..236.750 rows=25 loops=1)"
   "        Sort Key: ((data -> 'index'::text))"
   "        Sort Method: top-N heapsort  Memory: 28kB"
   "        ->  Seq Scan on docs  (cost=0.00..5577.50 rows=200 width=90) (actual time=0.020..170.797 rows=100158 loops=1)"
   "              Filter: (data @> '{"type": "type1"}'::jsonb)"
   "              Rows Removed by Filter: 99842"
   "Planning time: 0.075 ms"
   "Execution time: 236.785 ms"
*/

Tercera consulta: igual que la segunda (anterior) pero con índice btree en datos-> índice:

CREATE INDEX docs_data_index_idx ON docs ((data->'index'));

-- FAST ~19ms
EXPLAIN ANALYZE
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
ORDER BY data->'index' -- added BTREE index on this field
LIMIT 25;
/* "Limit  (cost=0.42..2473.98 rows=25 width=90) (actual time=0.040..0.125 rows=25 loops=1)"
   "  ->  Index Scan using docs_data_index_idx on docs  (cost=0.42..19788.92 rows=200 width=90) (actual time=0.038..0.119 rows=25 loops=1)"
   "        Filter: (data @> '{"type": "type1"}'::jsonb)"
   "        Rows Removed by Filter: 17"
   "Planning time: 0.127 ms"
   "Execution time: 0.159 ms"
*/

Cuarta consulta: ahora filtre por datos-> id y límite = 1:

-- SLOW ~116ms
EXPLAIN ANALYZE
SELECT * FROM docs
WHERE data @> ('{"id": "30e84646-c5c5-492d-b7f7-c884d77d1e0a"}')::JSONB -- querying by "id" field now
LIMIT 1;
/* "Limit  (cost=0.00..27.89 rows=1 width=90) (actual time=97.990..97.990 rows=1 loops=1)"
   "  ->  Seq Scan on docs  (cost=0.00..5577.00 rows=200 width=90) (actual time=97.989..97.989 rows=1 loops=1)"
   "        Filter: (data @> '{"id": "30e84646-c5c5-492d-b7f7-c884d77d1e0a"}'::jsonb)"
   "        Rows Removed by Filter: 189999"
   "Planning time: 0.064 ms"
   "Execution time: 98.012 ms"
*/

Quinta consulta: igual que la Cuarta pero con índice gin (json_path_ops) en los datos:

CREATE INDEX docs_data_idx ON docs USING GIN (data jsonb_path_ops);

-- FAST ~17ms
EXPLAIN ANALYZE
SELECT * FROM docs
WHERE data @> '{"id": "30e84646-c5c5-492d-b7f7-c884d77d1e0a"}'::JSONB -- added gin index with json_path_ops
LIMIT 1;
/* "Limit  (cost=17.55..20.71 rows=1 width=90) (actual time=0.027..0.027 rows=1 loops=1)"
   "  ->  Bitmap Heap Scan on docs  (cost=17.55..649.91 rows=200 width=90) (actual time=0.026..0.026 rows=1 loops=1)"
   "        Recheck Cond: (data @> '{"id": "30e84646-c5c5-492d-b7f7-c884d77d1e0a"}'::jsonb)"
   "        Heap Blocks: exact=1"
   "        ->  Bitmap Index Scan on docs_data_idx  (cost=0.00..17.50 rows=200 width=0) (actual time=0.016..0.016 rows=1 loops=1)"
   "              Index Cond: (data @> '{"id": "30e84646-c5c5-492d-b7f7-c884d77d1e0a"}'::jsonb)"
   "Planning time: 0.095 ms"
   "Execution time: 0.055 ms"
*/

Sexta (y última) consulta: igual que la Tercera consulta (consulta por datos-> tipo, ordenar por datos-> índice, límite):

-- SLOW AGAIN! ~224ms
EXPLAIN ANALYZE
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
ORDER BY data->'index'
LIMIT 25;
/* "Limit  (cost=656.06..656.12 rows=25 width=90) (actual time=215.927..215.932 rows=25 loops=1)"
   "  ->  Sort  (cost=656.06..656.56 rows=200 width=90) (actual time=215.925..215.925 rows=25 loops=1)"
   "        Sort Key: ((data -> 'index'::text))"
   "        Sort Method: top-N heapsort  Memory: 28kB"
   "        ->  Bitmap Heap Scan on docs  (cost=17.55..650.41 rows=200 width=90) (actual time=33.134..152.618 rows=100158 loops=1)"
   "              Recheck Cond: (data @> '{"type": "type1"}'::jsonb)"
   "              Heap Blocks: exact=3077"
   "              ->  Bitmap Index Scan on docs_data_idx  (cost=0.00..17.50 rows=200 width=0) (actual time=32.468..32.468 rows=100158 loops=1)"
   "                    Index Cond: (data @> '{"type": "type1"}'::jsonb)"
   "Planning time: 0.157 ms"
   "Execution time: 215.992 ms"
*/

Entonces parece que la sexta (igual que la tercera) consulta es mucho más lenta cuando hay un índice de ginebra en la columna de datos. ¿Probablemente se deba a que no hay muchos valores distintos para el campo de tipo datos-> (solo "tipo1" o "tipo2")? ¿Qué puedo hacer al respecto? Necesito gin index para hacer otras consultas que lo beneficien ...

postgresql postgresql-9.4 usuario606521
fuente

Respuestas:

5

Parece que te has encontrado con el problema de que las jsonbcolumnas tienen una tasa de estadísticas plana del 1%, como se informó aquí. ¿ Estás solucionando la falta de estadísticas de jsonb? . Mirando sus planes de consulta, las diferencias entre las estimaciones y las ejecuciones reales son enormes. Las estimaciones dicen que probablemente haya 200 filas, y el retorno real de 100158 filas, lo que hace que el planificador favorezca ciertas estrategias sobre otras.

Dado que la elección en la sexta consulta parece reducirse a favorecer una exploración de índice de mapa de bits sobre una exploración de índice, puede empujar el planificador junto con SET enable_bitmapscan=off para intentar que vuelva al comportamiento que tuvo en su tercer ejemplo.

Así es como funcionó para mí:

postgres@[local]:5432:postgres:=# EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
ORDER BY data->'index'
LIMIT 25;
                                                                QUERY PLAN                                                                 
-------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=656.06..656.12 rows=25 width=90) (actual time=117.338..117.343 rows=25 loops=1)
   Buffers: shared hit=3096
   ->  Sort  (cost=656.06..656.56 rows=200 width=90) (actual time=117.336..117.338 rows=25 loops=1)
         Sort Key: ((data -> 'index'::text))
         Sort Method: top-N heapsort  Memory: 28kB
         Buffers: shared hit=3096
         ->  Bitmap Heap Scan on docs  (cost=17.55..650.41 rows=200 width=90) (actual time=12.838..80.584 rows=99973 loops=1)
               Recheck Cond: (data @> '{"type": "type1"}'::jsonb)
               Heap Blocks: exact=3077
               Buffers: shared hit=3096
               ->  Bitmap Index Scan on docs_data_idx  (cost=0.00..17.50 rows=200 width=0) (actual time=12.469..12.469 rows=99973 loops=1)
                     Index Cond: (data @> '{"type": "type1"}'::jsonb)
                     Buffers: shared hit=19
 Planning time: 0.088 ms
 Execution time: 117.405 ms
(15 rows)

Time: 117.813 ms
postgres@[local]:5432:postgres:=# SET enable_bitmapscan = off;
SET
Time: 0.130 ms
postgres@[local]:5432:postgres:=# EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
ORDER BY data->'index'
LIMIT 25;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..1320.48 rows=25 width=90) (actual time=0.017..0.050 rows=25 loops=1)
   Buffers: shared hit=4
   ->  Index Scan using docs_data_index_idx on docs  (cost=0.42..10560.94 rows=200 width=90) (actual time=0.015..0.045 rows=25 loops=1)
         Filter: (data @> '{"type": "type1"}'::jsonb)
         Rows Removed by Filter: 27
         Buffers: shared hit=4
 Planning time: 0.083 ms
 Execution time: 0.071 ms
(8 rows)

Time: 0.402 ms
postgres@[local]:5432:postgres:=#

Si está buscando seguir esta ruta, asegúrese de deshabilitar esa exploración solo para consultas que muestren un comportamiento como este, de lo contrario, también obtendrá un mal comportamiento en otros planes de consulta. Hacer algo como esto debería funcionar bien:

BEGIN;
SET enable_bitmapscan=off;
SELECT * FROM docs
WHERE data @> '{"type": "type1"}'::JSONB
ORDER BY data->'index'
LIMIT 25;
SET enable_bitmapscan=on;
COMMIT;

Espero que ayude =)

Kassandry
fuente
No estoy seguro si lo entiendo correctamente (no estoy familiarizado con los componentes internos de PG): este comportamiento es causado por una baja cardinalidad en el campo "tipo" en la columna jsonb (y es internamente causado por una tasa de estadística plana), ¿verdad? Y también significa que, si quiero que mi consulta se optimice, tengo que saber la cardinalidad aproximada de los campos jsonb por los que estoy consultando para decidir si debo habilitar o no bitmapscan, ¿verdad?
user606521
1
Sí, parece entender esto en ambos aspectos. La selectividad básica del 1% favorece mirar el campo en la WHEREcláusula en el índice de ginebra porque cree que devolverá menos filas, lo que no es cierto. Como puede estimar mejor el número de filas, puede ver que, ya que lo está haciendo ORDER BY data->'index' LIMIT 25, que escanear las primeras entradas del otro índice (más o menos 50, con las filas desechadas) dará como resultado incluso menos filas, por lo que contar el planificador realmente no debería intentar usar un bitmapscan resulta en un plan de consulta más rápido. Espero que eso aclare las cosas. =)
Kassandry
1
Aquí encontrará información aclaratoria adicional: bases de datosoup.com/2015/01/tag-all-things-part-3.html y en esta presentación thebuild.com/presentations/json2015-pgconfus.pdf para ayudar también.
Kassandry
1
El único trabajo que conozco es de Oleg Bartunov, Tedor Sigaev y Alexander Kotorov sobre la extensión JsQuery y sus mejoras de selectividad. Con suerte, llega al núcleo de PostgreSQL en 9.6 o posterior.
Kassandry
1
Cité la cifra del 1% del correo electrónico en mi respuesta de Josh Berkus, miembro del equipo central de PostgreSQL. De dónde viene eso requiere una comprensión mucho más profunda de lo interno que poseo actualmente, lo siento. = (Puede intentar responder al [email protected]IRC de freenode o verificar #postgresqlde dónde proviene exactamente esa cifra.
Kassandry