🥇हामी PostgreSQL मा अनुक्रमणिकाका सबै सुविधाहरू प्रयोग गर्छौं

Postgres संसारमा, डाटाबेस भण्डारणको कुशल नेभिगेसनका लागि अनुक्रमणिकाहरू आवश्यक छन् (जसलाई "हिप" भनिन्छ)। Postgres ले यसको लागि क्लस्टरिङलाई समर्थन गर्दैन, र MVCC आर्किटेक्चरले तपाइँलाई एउटै टपलको धेरै संस्करणहरूको साथ समाप्त गराउँछ। तसर्थ, अनुप्रयोगहरूलाई समर्थन गर्न कुशल अनुक्रमणिकाहरू सिर्जना गर्न र कायम राख्न सक्षम हुनु धेरै महत्त्वपूर्ण छ।

यहाँ अनुक्रमणिकाहरूको प्रयोगलाई अनुकूलन र सुधार गर्नका लागि केही सुझावहरू छन्।

नोट: तल देखाइएको प्रश्नहरू एक अपरिवर्तित मा काम गर्दछ pagila नमूना डेटाबेस.

कभरिङ अनुक्रमणिकाहरू प्रयोग गर्दै

निष्क्रिय प्रयोगकर्ताहरूका लागि इमेल ठेगानाहरू निकाल्ने अनुरोधलाई हेरौं। तालिका customer त्यहाँ एउटा स्तम्भ छ active, र प्रश्न सरल छ:

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                        QUERY PLAN
-----------------------------------------------------------
 Seq Scan on customer  (cost=0.00..16.49 rows=15 width=32)
   Filter: (active = 0)
(2 rows)

क्वेरीले पूर्ण तालिका स्क्यान अनुक्रम आह्वान गर्दछ customer। स्तम्भमा अनुक्रमणिका सिर्जना गरौं active:

pagila=# CREATE INDEX idx_cust1 ON customer(active);
CREATE INDEX
pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Index Scan using idx_cust1 on customer  (cost=0.28..12.29 rows=15 width=32)
   Index Cond: (active = 0)
(2 rows)

यसले मद्दत गर्यो, त्यसपछिको स्क्यान "मा परिणत भयोindex scan"। यसको मतलब पोष्टग्रेसले अनुक्रमणिका स्क्यान गर्नेछ "idx_cust1", र त्यसपछि अन्य स्तम्भहरूको मानहरू पढ्नको लागि तालिकाको हिप खोजी जारी राख्नुहोस् (यस अवस्थामा, स्तम्भ email) जुन क्वेरी आवश्यक छ।

कभरिङ अनुक्रमणिकाहरू PostgreSQL 11 मा प्रस्तुत गरिएका छन्। तिनीहरूले तपाईंलाई अनुक्रमणिकामा एक वा बढी अतिरिक्त स्तम्भहरू समावेश गर्न अनुमति दिन्छ - तिनीहरूका मानहरू अनुक्रमणिका डेटा भण्डारमा भण्डारण गरिएका छन्।

यदि हामीले यस सुविधाको फाइदा उठायौं र अनुक्रमणिका भित्र इमेल मान थप्यौं भने, पोस्टग्रेसले मूल्यको लागि तालिकाको ढेर खोज्न आवश्यक पर्दैन। email। हेरौं यदि यसले काम गर्छ भने:

pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);
CREATE INDEX
pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;
                                    QUERY PLAN
----------------------------------------------------------------------------------
 Index Only Scan using idx_cust2 on customer  (cost=0.28..12.29 rows=15 width=32)
   Index Cond: (active = 0)
(2 rows)

«Index Only Scan' हामीलाई बताउँछ कि क्वेरीलाई अब केवल एक अनुक्रमणिका चाहिन्छ, जसले तालिकाको हिप पढ्नको लागि सबै डिस्क I/O बाट बच्न मद्दत गर्दछ।

कभरिङ अनुक्रमणिकाहरू हाल B-ट्रीहरूको लागि मात्र उपलब्ध छन्। यद्यपि, यस अवस्थामा, मर्मत प्रयास उच्च हुनेछ।

आंशिक अनुक्रमणिकाहरू प्रयोग गर्दै

आंशिक अनुक्रमणिकाहरू तालिकामा पङ्क्तिहरूको उपसमूह मात्र हुन्। यसले अनुक्रमणिकाको साइज बचत गर्छ र स्क्यानलाई छिटो बनाउँछ।

मानौं हामी क्यालिफोर्नियामा हाम्रा ग्राहकहरूको इमेल ठेगानाहरूको सूची प्राप्त गर्न चाहन्छौं। अनुरोध यस प्रकार हुनेछ:

SELECT c.email FROM customer c
JOIN address a ON c.address_id = a.address_id
WHERE a.district = 'California';
which has a query plan that involves scanning both the tables that are joined:
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                              QUERY PLAN
----------------------------------------------------------------------
 Hash Join  (cost=15.65..32.22 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=15.54..15.54 rows=9 width=4)
         ->  Seq Scan on address a  (cost=0.00..15.54 rows=9 width=4)
               Filter: (district = 'California'::text)
(6 rows)

के सामान्य अनुक्रमणिकाले हामीलाई दिनेछ:

pagila=# CREATE INDEX idx_address1 ON address(district);
CREATE INDEX
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                                      QUERY PLAN
---------------------------------------------------------------------------------------
 Hash Join  (cost=12.98..29.55 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=12.87..12.87 rows=9 width=4)
         ->  Bitmap Heap Scan on address a  (cost=4.34..12.87 rows=9 width=4)
               Recheck Cond: (district = 'California'::text)
               ->  Bitmap Index Scan on idx_address1  (cost=0.00..4.34 rows=9 width=0)
                     Index Cond: (district = 'California'::text)
(8 rows)

स्क्यान गर्नुहोस् address अनुक्रमणिका स्क्यान द्वारा प्रतिस्थापित गरिएको छ idx_address1र त्यसपछि हिप स्क्यान address.

यो एक बारम्बार क्वेरी भएकोले र अप्टिमाइज गर्न आवश्यक छ, हामी आंशिक अनुक्रमणिका प्रयोग गर्न सक्छौं, जसले ठेगानाहरू भएका ती पङ्क्तिहरू मात्र अनुक्रमणिका गर्दछ जुन जिल्लामा ‘California’:

pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';
CREATE INDEX
pagila=# EXPLAIN SELECT c.email FROM customer c
pagila-# JOIN address a ON c.address_id = a.address_id
pagila-# WHERE a.district = 'California';
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Hash Join  (cost=12.38..28.96 rows=9 width=32)
   Hash Cond: (c.address_id = a.address_id)
   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)
   ->  Hash  (cost=12.27..12.27 rows=9 width=4)
         ->  Index Only Scan using idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)
(5 rows)

अब प्रश्न मात्र पढ्छ idx_address2 र टेबल छुदैन address.

बहु-मान अनुक्रमणिकाहरू प्रयोग गर्दै

अनुक्रमणिका हुने केही स्तम्भहरूमा स्केलर डेटा प्रकार नहुन सक्छ। स्तम्भ प्रकारहरू जस्तै jsonb, arrays и tsvector कम्पोजिट वा धेरै मानहरू समावेश गर्दछ। यदि तपाईंलाई त्यस्ता स्तम्भहरू अनुक्रमणिका गर्न आवश्यक छ भने, तपाईंले सामान्यतया ती स्तम्भहरूमा सबै व्यक्तिगत मानहरू खोज्नुपर्छ।

असफल टेकहरूबाट कटहरू समावेश गरिएका सबै चलचित्रहरूको शीर्षकहरू फेला पार्न प्रयास गरौं। तालिका film त्यहाँ एउटा पाठ स्तम्भ भनिन्छ special_features। यदि चलचित्रमा यो "विशेष गुण" छ भने, तब स्तम्भले पाठ एरेको रूपमा तत्व समावेश गर्दछ Behind The Scenes। त्यस्ता सबै चलचित्रहरू खोज्नको लागि, हामीले "पर्दा पछाडि" जब सबै पङ्क्तिहरू चयन गर्नुपर्छ कुनै पनि एरे मानहरू special_features:

SELECT title FROM film WHERE special_features @> '{"Behind The Scenes"}';

नेस्टिङ अपरेटर @> दायाँ छेउ बायाँ छेउको सबसेट हो कि भनेर जाँच गर्दछ।

अनुरोध योजना:

pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)
   Filter: (special_features @> '{"Behind The Scenes"}'::text[])
(2 rows)

जसले 67 को लागतमा पूर्ण हिप स्क्यान अनुरोध गर्दछ।

हेरौं यदि नियमित बी-ट्री अनुक्रमणिकाले हामीलाई मद्दत गर्छ:

pagila=# CREATE INDEX idx_film1 ON film(special_features);
CREATE INDEX
pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)
   Filter: (special_features @> '{"Behind The Scenes"}'::text[])
(2 rows)

परिसूचकलाई पनि विचार गरिएन । बी-ट्री सूचकांक अनुक्रमित मानहरूमा व्यक्तिगत तत्वहरूको अस्तित्वको बारेमा सचेत छैन।

हामीलाई GIN सूचकांक चाहिन्छ।

pagila=# CREATE INDEX idx_film2 ON film USING GIN(special_features);
CREATE INDEX
pagila=# EXPLAIN SELECT title FROM film
pagila-# WHERE special_features @> '{"Behind The Scenes"}';
                                QUERY PLAN
---------------------------------------------------------------------------
 Bitmap Heap Scan on film  (cost=8.04..23.58 rows=5 width=15)
   Recheck Cond: (special_features @> '{"Behind The Scenes"}'::text[])
   ->  Bitmap Index Scan on idx_film2  (cost=0.00..8.04 rows=5 width=0)
         Index Cond: (special_features @> '{"Behind The Scenes"}'::text[])
(4 rows)

GIN अनुक्रमणिकाले अनुक्रमित कम्पोजिट मानहरूको विरुद्धमा एकल मानहरू म्याप गर्न समर्थन गर्दछ, परिणामस्वरूप क्वेरी योजना लागत आधाभन्दा बढी हुन्छ।

डुप्लिकेट अनुक्रमणिकाहरूबाट छुटकारा पाउँदै

अनुक्रमणिकाहरू समयको साथमा जम्मा हुन्छन्, र कहिलेकाहीँ नयाँ अनुक्रमणिकाले अघिल्लो मध्ये एक जस्तै परिभाषा समावेश गर्न सक्छ। अनुक्रमणिकाहरूको मानव-पढ्न योग्य SQL परिभाषाहरू प्राप्त गर्न तपाईँले क्याटलग दृश्य प्रयोग गर्न सक्नुहुन्छ। pg_indexes। तपाईं पनि सजिलै समान परिभाषाहरू फेला पार्न सक्नुहुन्छ:

 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn
    FROM pg_indexes
GROUP BY defn
  HAVING count(*) > 1;
And here’s the result when run on the stock pagila database:
pagila=#   SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn
pagila-#     FROM pg_indexes
pagila-# GROUP BY defn
pagila-#   HAVING count(*) > 1;
                                indexes                                 |                                defn
------------------------------------------------------------------------+------------------------------------------------------------------
 {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | CREATE INDEX  ON public.payment_p2017_01 USING btree (customer_id
 {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | CREATE INDEX  ON public.payment_p2017_02 USING btree (customer_id
 {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | CREATE INDEX  ON public.payment_p2017_03 USING btree (customer_id
 {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_04 USING btree (customer_id
 {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | CREATE INDEX  ON public.payment_p2017_05 USING btree (customer_id
 {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_06 USING btree (customer_id
(6 rows)

सुपरसेट अनुक्रमणिकाहरू

यो हुन सक्छ कि तपाइँ धेरै अनुक्रमणिकाहरू संग समाप्त हुन्छ, जसमध्ये एउटा अनुक्रमणिका स्तम्भहरूको सुपरसेट जसले अन्य अनुक्रमणिकाहरू अनुक्रमणिका गर्दछ। यो वांछनीय हुन सक्छ वा नहुन सक्छ — सुपरसेटले अनुक्रमणिका-मात्र स्क्यान गर्न सक्छ, जुन राम्रो छ, तर यसले धेरै ठाउँ लिन सक्छ, वा सुपरसेटलाई अप्टिमाइज गर्ने उद्देश्यले गरिएको क्वेरी अब प्रयोग गरिने छैन।

यदि तपाइँ त्यस्ता अनुक्रमणिकाहरूको परिभाषा स्वचालित गर्न आवश्यक छ भने, तपाइँ सुरु गर्न सक्नुहुन्छ pg_index टेबलबाट pg_catalog.

प्रयोग नगरिएका अनुक्रमणिकाहरू

डाटाबेसहरू प्रयोग गर्ने अनुप्रयोगहरू विकसित हुँदा, तिनीहरूले प्रयोग गर्ने प्रश्नहरू पनि विकसित हुन्छन्। पहिले थपिएका अनुक्रमणिकाहरू अब कुनै पनि क्वेरीद्वारा प्रयोग गर्न सकिँदैन। प्रत्येक पटक एक अनुक्रमणिका स्क्यान गरिन्छ, यसलाई तथ्याङ्क प्रबन्धक द्वारा चिन्ह लगाइन्छ, र प्रणाली क्याटलग दृश्यमा pg_stat_user_indexes तपाईं मूल्य देख्न सक्नुहुन्छ idx_scan, जुन एक संचयी काउन्टर हो। समय अवधि (एक महिना भन्नुहोस्) मा यो मान ट्र्याक गर्नाले कुन अनुक्रमणिकाहरू प्रयोग भइरहेको छैन र छोड्न सकिन्छ भन्ने राम्रो विचार दिन्छ।

स्किमामा सबै अनुक्रमणिकाहरूको हालको स्क्यान गणनाहरू प्राप्त गर्न यहाँ एउटा प्रश्न छ ‘public’:

SELECT relname, indexrelname, idx_scan
FROM   pg_catalog.pg_stat_user_indexes
WHERE  schemaname = 'public';
with output like this:
pagila=# SELECT relname, indexrelname, idx_scan
pagila-# FROM   pg_catalog.pg_stat_user_indexes
pagila-# WHERE  schemaname = 'public'
pagila-# LIMIT  10;
    relname    |    indexrelname    | idx_scan
---------------+--------------------+----------
 customer      | customer_pkey      |    32093
 actor         | actor_pkey         |     5462
 address       | address_pkey       |      660
 category      | category_pkey      |     1000
 city          | city_pkey          |      609
 country       | country_pkey       |      604
 film_actor    | film_actor_pkey    |        0
 film_category | film_category_pkey |        0
 film          | film_pkey          |    11043
 inventory     | inventory_pkey     |    16048
(10 rows)

कम लकहरूसँग अनुक्रमणिकाहरू पुन: निर्माण गर्दै

अनुक्रमणिकाहरू प्राय: पुन: निर्माण गर्न आवश्यक छ, उदाहरणका लागि जब तिनीहरू फूल्छन्, र पुनर्निर्माणले स्क्यानलाई गति दिन सक्छ। साथै अनुक्रमणिकाहरू भ्रष्ट हुन सक्छ। अनुक्रमणिका प्यारामिटरहरू परिवर्तन गर्न पनि यसलाई पुन: निर्माण गर्न आवश्यक हुन सक्छ।

समानान्तर अनुक्रमणिका सिर्जना सक्षम गर्नुहोस्

PostgreSQL 11 मा, एक B-Tree अनुक्रमणिका सिर्जना समवर्ती छ। निर्माण प्रक्रियालाई गति दिन, धेरै समानान्तर कार्यकर्ताहरू प्रयोग गर्न सकिन्छ। यद्यपि, यी कन्फिगरेसन विकल्पहरू सही रूपमा सेट गरिएको छ भनी सुनिश्चित गर्नुहोस्:

SET max_parallel_workers = 32;
SET max_parallel_maintenance_workers = 16;

पूर्वनिर्धारित मानहरू धेरै सानो छन्। आदर्श रूपमा, यी संख्याहरू प्रोसेसर कोरहरूको संख्यासँगै बढ्नुपर्छ। मा थप पढ्नुहोस् कागजात.

पृष्ठभूमि सूचकांक निर्माण

तपाईं विकल्प प्रयोग गरेर पृष्ठभूमिमा अनुक्रमणिका सिर्जना गर्न सक्नुहुन्छ CONCURRENTLY टोलीहरू CREATE INDEX:

pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);
CREATE INDEX

यो अनुक्रमणिका सिर्जना प्रक्रिया सामान्य भन्दा फरक छ कि यसलाई टेबलमा लक आवश्यक पर्दैन, र त्यसैले लेखन कार्यहरू रोक्दैन। अर्कोतर्फ, यसले बढी समय लिन्छ र थप स्रोतहरू खपत गर्दछ।

Postgres ले अनुक्रमणिकाहरू सिर्जना गर्न र कुनै विशेष केसहरू समाधान गर्ने तरिकाहरू, साथै तपाईंको अनुप्रयोग विस्फोटक रूपमा बढेको अवस्थामा डाटाबेस व्यवस्थापन गर्ने तरिकाहरू प्रदान गर्दछ। हामी आशा गर्दछौं कि यी सुझावहरूले तपाईंलाई तपाईंको प्रश्नहरू छिटो र तपाईंको डाटाबेस मापन गर्न तयार पार्न मद्दत गर्नेछ।

स्रोत: www.habr.com

PostgreSQL मा अनुक्रमणिकाका सबै सुविधाहरू प्रयोग गर्दै