एक jsonb कॉलम पर gin इंडेक्स मेरी क्वेरी को धीमा क्यों कर रहा है और मैं इसके बारे में क्या कर सकता हूं?

10

प्रारंभिक परीक्षण डेटा:

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);

पहली क्वेरी - डेटा द्वारा फ़िल्टर-> प्रकार और सीमा:

-- 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" 
*/

दूसरी क्वेरी - डेटा द्वारा फ़िल्टर-> प्रकार, डेटा द्वारा आदेश-> सूचकांक और सीमा

-- 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"
*/

तीसरी क्वेरी - दूसरी (पिछली) की तरह लेकिन डेटा पर btree इंडेक्स के साथ-> इंडेक्स:

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"
*/

चौथी क्वेरी - अब डेटा द्वारा फ़िल्टर करें - आईडी और सीमा = 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"
*/

पांचवी क्वेरी - डेटा पर जिन (json_path_ops) इंडेक्स के साथ चौथा लेकिन समान:

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"
*/

छठी (और अंतिम) क्वेरी - तीसरी क्वेरी (डेटा द्वारा क्वेरी-> प्रकार, डेटा द्वारा क्रम-> इंडेक्स, लिमिट):

-- 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"
*/

तो ऐसा लगता है कि डेटा कॉलम पर जिन इंडेक्स है, वहां सिक्स्थ (थर्ड के समान) क्वेरी बहुत धीमी है। यह शायद इसलिए है क्योंकि डेटा के लिए कई अलग-अलग मान नहीं हैं-> टाइप फ़ील्ड (केवल "टाइप 1" या "टाइप 2")? मैं इसके बारे में क्या कर सकता हूं? मुझे उन अन्य प्रश्नों को बनाने के लिए जिन इंडेक्स की जरूरत है जो इसके बारे में सोचते हैं ...

postgresql  postgresql-9.4 
— user606521
स्रोत

जवाबों:

5

ऐसा लगता है कि आप इस समस्या में भाग ले रहे हैं कि jsonbकॉलम में फ्लैट 1% आँकड़े दर है, जैसा कि रिपोर्ट किया गया है यहाँ jsonb की कमी आँकड़ों के आसपास काम कर रही है? । आपकी क्वेरी योजनाओं को देखते हुए, अनुमानों और वास्तविक निष्पादन के बीच अंतर बहुत बड़ा है। अनुमान कहते हैं कि संभवतः 200 पंक्तियां हैं, और वास्तविक वापसी 100158 पंक्तियां हैं, जो योजनाकार को दूसरों पर कुछ रणनीतियों का पक्ष लेने का कारण बनता है।

चूंकि छठी क्वेरी में विकल्प एक इंडेक्स स्कैन पर बिटमैप इंडेक्स स्कैन के पक्ष में आता है, इसलिए आप SET enable_bitmapscan=offअपने तीसरे उदाहरण में आपके द्वारा किए गए व्यवहार पर वापस लौटने के लिए प्लानर के साथ-साथ प्लानर को बता सकते हैं ।

यहाँ बताया गया है कि यह मेरे लिए कैसे काम करता है:

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:=#

यदि आप इस मार्ग पर जाना चाहते हैं, तो केवल इस तरह के व्यवहार को दिखाने वाले प्रश्नों के लिए उस स्कैन को अक्षम करना सुनिश्चित करें, अन्यथा, आपको अन्य क्वेरी योजनाओं पर भी बुरा व्यवहार मिलेगा। इस तरह से कुछ करना ठीक काम करना चाहिए:

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

आशा है कि मदद करता है =)

— Kassandry
स्रोत
मुझे यकीन नहीं है कि अगर मैं आपको सही तरीके से समझता हूं (मैं पीजी इंटर्नल से परिचित नहीं हूं) - यह व्यवहार जोंसब कॉलम में "टाइप" फ़ील्ड पर कम कार्डिनैलिटी (और आंतरिक रूप से फ्लैट सांख्यिकी दर के कारण होता है) के कारण होता है, है ना? और इसका मतलब यह भी है कि, अगर मैं चाहता हूं कि मेरी क्वेरी को अनुकूलित किया जाए, तो मुझे jsonb फ़ील्ड की अनुमानित कार्डिनैलिटी को जानना होगा (s) मैं यह तय करने के लिए क्वेरी कर रहा हूं कि मुझे enable_bitmapscan चाहिए या नहीं, है ना?
— user606521
1
हां, आप इसे दोनों मामलों में समझते हैं। बेस 1% चयनात्मकता WHEREजिन इंडेक्स में क्लॉज के क्षेत्र को देख रही है, क्योंकि यह मानता है कि यह कम पंक्तियों को लौटाएगा, जो कि सच नहीं है। चूँकि आप पंक्तियों की संख्या का बेहतर अनुमान लगा सकते हैं, आप देख सकते हैं, जब से आप कर रहे हैं ORDER BY data->'index' LIMIT 25, कि दूसरे सूचकांक की पहली कुछ प्रविष्टियों को स्कैन करना (50 या तो, फेंकी गई पंक्तियों के साथ) और भी कम पंक्तियों में परिणाम होगा, इसलिए बताना यह वास्तव में उपयोग नहीं किया जा रहा है एक तेजी से क्वेरी योजना में एक बिटमैप परिणाम का उपयोग करने की कोशिश करनी चाहिए योजनाकार। उम्मीद है कि चीजें सुलझ गई हैं। =)
— कैसंड्री
1
यहाँ अतिरिक्त स्पष्ट जानकारी है: databaseoup.com/2015/01/tag-all-things-part-3.html और इस प्रस्तुति में thebuild.com/pretations/json2015-pgconfus.pdf के रूप में अच्छी तरह से मदद करने के लिए।
— कैसेंड्री
1
एकमात्र काम जो मुझे पता है वह जेएसवाईके विस्तार पर ओलेग बार्टुनोव, टेडोर सिगाव, और अलेक्जेंडर कोटरोव से है और इसकी चयनात्मकता में सुधार है। किसी भी भाग्य के साथ, यह 9.6 या इसके बाद के पोस्टग्रेसीक्यूएल कोर में बनाता है।
— कसांड्री
1
मैंने ईमेल से 1% आंकड़ा जोश बर्कस, एक पोस्टग्रेक्यूएल कोर टीम के सदस्य से अपने जवाब में उद्धृत किया। जहाँ से यह आता है कि मुझे वर्तमान में जितना माफ़ करना है, उससे कहीं अधिक गहन समझ की आवश्यकता है। = (आप pgsql-performance@postgresql.orgfreenode IRC पर रिप्लाई करने या चेक करने की कोशिश कर सकते #postgresqlहैं कि वास्तव में यह आंकड़ा कहाँ से आया है।
— कासन्ड्री
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.