आपको याद दिला दूं कि हमने अलगाव से संबंधित मुद्दों की जांच की, निम्न स्तर पर डेटा को व्यवस्थित करने के बारे में एक विषयांतर किया, और फिर पंक्ति संस्करणों और स्नैपशॉट से संस्करणों के बारे में विस्तार से बात की।

आज हम दो निकटता से संबंधित मुद्दों से निपटेंगे: इंट्रा-पेज सफाई और हॉट-अपडेट । दोनों तंत्रों को अनुकूलन के रूप में वर्गीकृत किया जा सकता है; वे महत्वपूर्ण हैं, लेकिन उपयोगकर्ता प्रलेखन में लगभग शामिल नहीं हैं।

नियमित अपडेट के साथ इन-पेज सफाई

जब एक पृष्ठ तक पहुँच - अद्यतन करने के दौरान और पढ़ते समय - त्वरित इंट्रा-पृष्ठ सफाई हो सकती है यदि पोस्टग्रेक्यूएल समझता है कि पृष्ठ अंतरिक्ष से बाहर चल रहा है। यह दो मामलों में होता है।

1. इस पृष्ठ (UPDATE) पर पहले किए गए अपडेट में एक ही पृष्ठ पर पंक्ति का नया संस्करण रखने के लिए पर्याप्त स्थान नहीं मिला। इस स्थिति को पृष्ठ शीर्षक में याद किया जाता है, और अगली बार पृष्ठ को साफ़ कर दिया जाता है।
2. पेज फिलफैक्टर की तुलना में अधिक भरा है। इस मामले में, अगली बार देरी किए बिना, सफाई तुरंत होती है।

फिलफैक्टोर एक स्टोरेज पैरामीटर है जिसे टेबल (और इंडेक्स के लिए) के लिए परिभाषित किया जा सकता है। PostgreSQL एक पृष्ठ पर एक नई पंक्ति (INSERT) सम्मिलित करता है, यदि यह पृष्ठ पूर्णांक भरने से कम हो। शेष स्थान अपडेट (UPDATE) से उत्पन्न होने वाले स्ट्रिंग्स के नए संस्करणों के लिए आरक्षित है। तालिकाओं के लिए डिफ़ॉल्ट मान 100 है, अर्थात, स्थान आरक्षित नहीं है (और अनुक्रमित का मान 90 है)।

इन-पेज सफाई उन पंक्तियों के संस्करणों को हटा देती है जो किसी भी छवि में दिखाई नहीं देती हैं (डेटाबेस के "घटना क्षितिज से परे स्थित है, हमने पिछली बार इस बारे में बात की थी), लेकिन यह समान सारणी पृष्ठ के भीतर सख्ती से काम करता है। स्ट्रिंग के स्क्रब किए गए संस्करणों को इंगित नहीं किया जाता है, क्योंकि उन्हें अनुक्रमित से संदर्भित किया जा सकता है, और सूचकांक एक और पृष्ठ है। इन-पेज सफाई कभी एक सारणीबद्ध पृष्ठ से आगे नहीं जाती है, लेकिन यह बहुत तेज़ है।

उन्हीं कारणों से, मुक्त स्थान का नक्शा अपडेट नहीं किया गया है; यह आवेषण के लिए नहीं, अपडेट के लिए स्थान भी बचाता है। दृश्यता मानचित्र भी अद्यतन नहीं है।

तथ्य यह है कि एक पृष्ठ को पढ़ने के दौरान साफ ​​किया जा सकता है इसका मतलब है कि एक पढ़ने का अनुरोध (SELECT) पृष्ठों को बदलने का कारण बन सकता है। यह इस तरह का एक और मामला है, संकेत बिट्स के पहले आस्थगित परिवर्तन के अलावा।

आइए देखें कि यह कैसे काम करता है, उदाहरण के लिए। दोनों कॉलम पर एक टेबल और इंडेक्स बनाएं।

=> CREATE TABLE hot(id integer, s char(2000)) WITH (fillfactor = 75); => CREATE INDEX hot_id ON hot(id); => CREATE INDEX hot_s ON hot(s); 

यदि केवल लैटिन अक्षरों को कॉलम एस में संग्रहीत किया जाता है, तो पंक्ति के प्रत्येक संस्करण में 2004 बाइट्स और हेडर के 24 बाइट्स होंगे। हमने फिलफैक्टोर स्टोरेज पैरामीटर को 75% पर सेट किया है - तीन लाइनों के लिए पर्याप्त जगह होगी।

सुविधा के लिए, हम पहले से ही परिचित फ़ंक्शन को फिर से बनाते हैं, आउटपुट को दो क्षेत्रों के साथ पूरक करते हैं:

 => CREATE FUNCTION heap_page(relname text, pageno integer) RETURNS TABLE(ctid tid, state text, xmin text, xmax text, hhu text, hot text, t_ctid tid) AS $$ SELECT (pageno,lp)::text::tid AS ctid, CASE lp_flags WHEN 0 THEN 'unused' WHEN 1 THEN 'normal' WHEN 2 THEN 'redirect to '||lp_off WHEN 3 THEN 'dead' END AS state, t_xmin || CASE WHEN (t_infomask & 256) > 0 THEN ' (c)' WHEN (t_infomask & 512) > 0 THEN ' (a)' ELSE '' END AS xmin, t_xmax || CASE WHEN (t_infomask & 1024) > 0 THEN ' (c)' WHEN (t_infomask & 2048) > 0 THEN ' (a)' ELSE '' END AS xmax, CASE WHEN (t_infomask2 & 16384) > 0 THEN 't' END AS hhu, CASE WHEN (t_infomask2 & 32768) > 0 THEN 't' END AS hot, t_ctid FROM heap_page_items(get_raw_page(relname,pageno)) ORDER BY lp; $$ LANGUAGE SQL; 

और इंडेक्स पेज के अंदर देखने के लिए एक फंक्शन बनाएं:

 => CREATE FUNCTION index_page(relname text, pageno integer) RETURNS TABLE(itemoffset smallint, ctid tid) AS $$ SELECT itemoffset, ctid FROM bt_page_items(relname,pageno); $$ LANGUAGE SQL; 

हम यह जांचेंगे कि इंट्रा-पृष्ठ सफाई कैसे काम करती है। ऐसा करने के लिए, एक पंक्ति डालें और इसे कई बार बदलें:

 => INSERT INTO hot VALUES (1, 'A'); => UPDATE hot SET s = 'B'; => UPDATE hot SET s = 'C'; => UPDATE hot SET s = 'D'; 

पृष्ठ में पंक्ति के चार संस्करण हैं:

 => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+----------+-----+-----+-------- (0,1) | normal | 3979 (c) | 3980 (c) | | | (0,2) (0,2) | normal | 3980 (c) | 3981 (c) | | | (0,3) (0,3) | normal | 3981 (c) | 3982 | | | (0,4) (0,4) | normal | 3982 | 0 (a) | | | (0,4) (4 rows) 

जैसी कि उम्मीद थी, हम फिलफैक्टर सीमा से अधिक हो गए। यह पृष्ठ आकार और ऊपरी मूल्यों के बीच अंतर द्वारा इंगित किया गया है: यह पृष्ठ आकार के 75% की सीमा से अधिक है, जो 6144 बाइट्स है।

 => SELECT lower, upper, pagesize FROM page_header(get_raw_page('hot',0)); 

  lower | upper | pagesize -------+-------+---------- 40 | 64 | 8192 (1 row) 

तो, अगली बार जब आप पृष्ठ तक पहुँचते हैं, तो इन-पेज सफाई होनी चाहिए। इसे देखें।

 => UPDATE hot SET s = 'E'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+-------+-----+-----+-------- (0,1) | dead | | | | | (0,2) | dead | | | | | (0,3) | dead | | | | | (0,4) | normal | 3982 (c) | 3983 | | | (0,5) (0,5) | normal | 3983 | 0 (a) | | | (0,5) (5 rows) 

लाइनों के सभी अप्रासंगिक संस्करण (0,1), (0,2) और (0,3) साफ़ हो जाते हैं; उसके बाद, लाइन का एक नया संस्करण (0.5) रिक्त स्थान में जोड़ा जाता है।

सफाई के बाद बची हुई लाइनों के संस्करणों को शारीरिक रूप से वरिष्ठ पेज के पते के किनारे पर स्थानांतरित कर दिया जाता है ताकि सभी मुक्त स्थान एक निरंतर टुकड़े द्वारा दर्शाए जाएं। संकेत के मान तदनुसार बदलते रहते हैं। इसके लिए धन्यवाद, पृष्ठ में खाली स्थान के विखंडन के साथ कोई समस्या नहीं है।

स्ट्रिंग के हटाए गए संस्करणों के पॉइंटर्स को मुक्त नहीं किया जा सकता है क्योंकि वे एक इंडेक्स पेज से संदर्भित हैं। आइए हॉट_एस इंडेक्स के पहले पृष्ठ को देखें (क्योंकि शून्य मेटा-सूचना के साथ व्यस्त है):

 => SELECT * FROM index_page('hot_s',1); 

  itemoffset | ctid ------------+------- 1 | (0,1) 2 | (0,2) 3 | (0,3) 4 | (0,4) 5 | (0,5) (5 rows) 

हम उसी चित्र को दूसरे सूचकांक में देखेंगे:

 => SELECT * FROM index_page('hot_id',1); 

  itemoffset | ctid ------------+------- 1 | (0,5) 2 | (0,4) 3 | (0,3) 4 | (0,2) 5 | (0,1) (5 rows) 

आप देख सकते हैं कि तालिका पंक्तियों के संकेत यहाँ "पीछे की ओर" जाते हैं, लेकिन इससे कोई फर्क नहीं पड़ता, क्योंकि पंक्तियों के सभी संस्करणों में समान मान id = 1. है, लेकिन पिछले सूचकांक में, बिंदुओं को s मान द्वारा आदेशित किया जाता है, और यह काफी।

इंडेक्स एक्सेस के साथ, PostgreSQL को पंक्ति संस्करण पहचानकर्ता के रूप में (0,1), (0,2) या (0,3) प्राप्त कर सकते हैं। फिर वह तालिका पृष्ठ से संबंधित पंक्ति प्राप्त करने का प्रयास करेगा, लेकिन सूचक की मृत स्थिति के लिए धन्यवाद, वह पाएगा कि ऐसा संस्करण अब मौजूद नहीं है और इसे अनदेखा करेगा। (वास्तव में, पहली बार यह एक तालिका पंक्ति के संस्करण की कमी का पता लगाता है, PostgreSQL इंडेक्स पेज में पॉइंटर की स्थिति को भी बदल देगा ताकि वह टेबल पेज पर फिर से न पहुंच सके।)

यह महत्वपूर्ण है कि इंट्रा-पेज सफाई केवल एक सारणीबद्ध पृष्ठ के भीतर काम करती है और सूचकांक पृष्ठों को साफ नहीं करती है।

गर्म अपडेट

सूचकांक में एक स्ट्रिंग के सभी संस्करणों के लिंक रखना बुरा क्यों है?

सबसे पहले, किसी भी पंक्ति परिवर्तन के साथ, आपको तालिका के लिए बनाए गए सभी अनुक्रमित को अपडेट करना होगा: चूंकि एक नया संस्करण दिखाई दिया है, आपके पास इसके लिंक होने चाहिए। और आपको इसे किसी भी मामले में करने की आवश्यकता है, भले ही वे क्षेत्र जो सूचकांक परिवर्तन में शामिल नहीं हैं। जाहिर है, यह बहुत प्रभावी नहीं है।

दूसरे, इंडेक्स स्ट्रिंग के ऐतिहासिक संस्करणों के लिंक को जमा करते हैं, जिसे तब स्वयं संस्करणों के साथ साफ करना होगा (हम इसे थोड़ा बाद में देखेंगे)।

इसके अलावा, PostgreSQL में बी-पेड़ के कार्यान्वयन की एक विशेषता है। यदि नई पंक्ति सम्मिलित करने के लिए अनुक्रमणिका पृष्ठ पर पर्याप्त स्थान नहीं है, तो पृष्ठ को दो में विभाजित किया गया है और सभी डेटा को उनके बीच पुनर्वितरित किया गया है। इसे स्प्लिट पेज कहा जाता है। हालाँकि, पंक्तियों को हटाते समय, दो अनुक्रमणिका पृष्ठ अब "एक साथ" चिपकते नहीं हैं। इसके कारण, यदि डेटा का पर्याप्त भाग हटा दिया जाता है, तो भी सूचकांक का आकार कम नहीं हो सकता है।

स्वाभाविक रूप से, मेज पर जितने अधिक सूचकांक बनाए जाते हैं, उतनी ही बड़ी कठिनाइयों का सामना करना पड़ता है।

हालांकि, यदि किसी स्तंभ का मान किसी भी अनुक्रमणिका परिवर्तन से संबंधित नहीं है, तो B- ट्री में एक ही कुंजी मान वाले अतिरिक्त रिकॉर्ड बनाने का कोई मतलब नहीं है। यह अनुकूलन कैसे काम करता है, जिसे HOT अपडेट कहा जाता है - हीप-ओनली टपल अपडेट।

इस अद्यतन के साथ, सूचकांक पृष्ठ में केवल एक प्रविष्टि है जो तालिका पृष्ठ में पंक्ति के पहले संस्करण को संदर्भित करती है। और पहले से ही इस सारणीबद्ध पृष्ठ के अंदर संस्करणों की एक श्रृंखला आयोजित की जाती है:

• श्रृंखला में शामिल और बदले गए स्ट्रिंग को हीप हॉट अपडेटेड बिट के साथ चिह्नित किया गया है;
• अनुक्रमणिका से संदर्भित पंक्तियाँ हीप ओनली टपल बिट (जो कि, "पंक्ति का केवल सारणीबद्ध संस्करण") के साथ चिह्नित है;
• ctid फ़ील्ड के माध्यम से स्ट्रिंग संस्करणों के नियमित लिंकिंग का समर्थन किया जाता है।

यदि, किसी इंडेक्स को स्कैन करते समय, PostgreSQL एक सारणीबद्ध पृष्ठ में प्रवेश करता है और हीप हॉट अपडेट के रूप में चिह्नित संस्करण को पता चलता है, तो यह समझता है कि इसे रोकने की आवश्यकता नहीं है और संपूर्ण अद्यतन श्रृंखला के साथ आगे बढ़ता है। बेशक, इस तरह से प्राप्त किए गए तारों के सभी संस्करणों के लिए, दृश्यता की जाँच की जाती है, इससे पहले कि वे ग्राहक को वापस कर दें।

HOT अपडेट के संचालन को देखने के लिए, एक इंडेक्स हटाएं और टेबल को साफ़ करें।

 => DROP INDEX hot_s; => TRUNCATE TABLE hot; 

सम्मिलित करें और पंक्ति को अपडेट करें।

 => INSERT INTO hot VALUES (1, 'A'); => UPDATE hot SET s = 'B'; 

यहाँ हम टेबल पेज में देखते हैं:

 => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+-------+-----+-----+-------- (0,1) | normal | 3986 (c) | 3987 | t | | (0,2) (0,2) | normal | 3987 | 0 (a) | | t | (0,2) (2 rows) 

पृष्ठ में परिवर्तनों की एक श्रृंखला है:

• हीप हॉट अपडेटेड ध्वज इंगित करता है कि आपको ctid श्रंखला के साथ जाने की आवश्यकता है,
• हीप ओनली टपल ध्वज इंगित करता है कि पंक्ति के इस संस्करण में कोई इंडेक्स लिंक नहीं हैं।

और परिवर्तनों के साथ, श्रृंखला बढ़ेगी (पृष्ठ के भीतर):

 => UPDATE hot SET s = 'C'; => UPDATE hot SET s = 'D'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+----------+-----+-----+-------- (0,1) | normal | 3986 (c) | 3987 (c) | t | | (0,2) (0,2) | normal | 3987 (c) | 3988 (c) | t | t | (0,3) (0,3) | normal | 3988 (c) | 3989 | t | t | (0,4) (0,4) | normal | 3989 | 0 (a) | | t | (0,4) (4 rows) 

इसके अलावा, सूचकांक में चेन के "हेड" का एक एकल संदर्भ है:

 => SELECT * FROM index_page('hot_id',1); 

  itemoffset | ctid ------------+------- 1 | (0,1) (1 row) 

हम जोर देते हैं कि अगर अद्यतन फ़ील्ड किसी भी सूचकांक में शामिल नहीं हैं, तो HOT-अपडेट कार्य। अन्यथा, कुछ सूचकांक में सीधे स्ट्रिंग के नए संस्करण के लिए एक लिंक होगा, जो इस अनुकूलन के विचार का खंडन करता है।

अनुकूलन केवल एक पृष्ठ की सीमा के भीतर काम करता है, इसलिए, श्रृंखला के एक अतिरिक्त बाईपास को अन्य पृष्ठों तक पहुंच की आवश्यकता नहीं होती है और प्रदर्शन को बाधित नहीं करता है।

HOT अपडेट के साथ इन-पेज सफाई

HOT अपडेट के दौरान इंट्रा-पेज सफाई का एक विशेष लेकिन महत्वपूर्ण मामला सफाई है।

पिछली बार की तरह, हम पहले से ही भराव की सीमा को पार कर चुके हैं, इसलिए अगले अद्यतन में इन-पेज सफाई होनी चाहिए। लेकिन पेज में इस बार अपडेट की एक श्रृंखला है। इस हॉट चेन का "हेड" हमेशा अपनी जगह पर रहना चाहिए, क्योंकि इंडेक्स इसे संदर्भित करता है, और बाकी पॉइंटर्स को मुक्त किया जा सकता है: यह ज्ञात है कि उन्हें बाहर से संदर्भित नहीं किया गया है।

"सिर" को छूने के लिए नहीं, डबल एड्रेसिंग का उपयोग किया जाता है: सूचक जिसे सूचकांक संदर्भित करता है - इस मामले में (0,1) - "पुनर्निर्देशन" की स्थिति प्राप्त करता है, स्ट्रिंग के वांछित संस्करण पर पुनर्निर्देशित करता है।

 => UPDATE hot SET s = 'E'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+-------+-----+-----+-------- (0,1) | redirect to 4 | | | | | (0,2) | normal | 3990 | 0 (a) | | t | (0,2) (0,3) | unused | | | | | (0,4) | normal | 3989 (c) | 3990 | t | t | (0,2) (4 rows) 

कृपया ध्यान दें कि:

• संस्करण (0,1), (0,2) और (0,3) को मंजूरी दे दी गई,
• हेड पॉइंटर (0,1) बना रहा, लेकिन रीडायरेक्ट स्थिति प्राप्त की,
• लाइन का एक नया संस्करण जगह (0.2) में लिखा गया है, क्योंकि इस संस्करण को इंडेक्स से कोई लिंक नहीं होने की गारंटी दी गई थी और सूचक को मुक्त (अप्रयुक्त) किया गया था।

अपडेट को कुछ और बार करें:

 => UPDATE hot SET s = 'F'; => UPDATE hot SET s = 'G'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+----------+-----+-----+-------- (0,1) | redirect to 4 | | | | | (0,2) | normal | 3990 (c) | 3991 (c) | t | t | (0,3) (0,3) | normal | 3991 (c) | 3992 | t | t | (0,5) (0,4) | normal | 3989 (c) | 3990 (c) | t | t | (0,2) (0,5) | normal | 3992 | 0 (a) | | t | (0,5) (5 rows) 

निम्नलिखित अद्यतन फिर से इंट्रा-पेज क्लीनअप का कारण बनता है:

 => UPDATE hot SET s = 'H'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+-------+-----+-----+-------- (0,1) | redirect to 5 | | | | | (0,2) | normal | 3993 | 0 (a) | | t | (0,2) (0,3) | unused | | | | | (0,4) | unused | | | | | (0,5) | normal | 3992 (c) | 3993 | t | t | (0,2) (5 rows) 

फिर से, कुछ संस्करणों को मंजूरी दे दी जाती है, और सूचक को "सिर" के अनुसार स्थानांतरित कर दिया जाता है।

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

हॉट चेन तोड़

यदि किसी पंक्ति के नए संस्करण को पोस्ट करने के लिए पृष्ठ पर पर्याप्त खाली स्थान नहीं है, तो श्रृंखला टूट जाएगी। दूसरे पृष्ठ पर पोस्ट की गई लाइन के संस्करण को इंडेक्स से एक अलग लिंक बनाना होगा।

इस स्थिति को प्राप्त करने के लिए, हम एक समानांतर लेनदेन शुरू करते हैं और इसमें एक डेटा स्नैपशॉट बनाते हैं।

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SELECT count(*) FROM hot; 

 | count | ------- | 1 | (1 row) 

एक स्नैपशॉट पृष्ठ पर लाइनों के संस्करण को स्पष्ट नहीं करेगा। अब हम पहले सत्र में अद्यतन करते हैं:

 => UPDATE hot SET s = 'I'; => UPDATE hot SET s = 'J'; => UPDATE hot SET s = 'K'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+----------+-----+-----+-------- (0,1) | redirect to 2 | | | | | (0,2) | normal | 3993 (c) | 3994 (c) | t | t | (0,3) (0,3) | normal | 3994 (c) | 3995 (c) | t | t | (0,4) (0,4) | normal | 3995 (c) | 3996 | t | t | (0,5) (0,5) | normal | 3996 | 0 (a) | | t | (0,5) (5 rows) 

अगली बार जब पृष्ठ ताज़ा किया जाता है, तो पृष्ठ पर पर्याप्त जगह नहीं होगी, लेकिन इन-पेज सफाई कुछ भी मुक्त नहीं कर सकती है:

 => UPDATE hot SET s = 'L'; 

 | => COMMIT; --     

 => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+----------+-----+-----+-------- (0,1) | redirect to 2 | | | | | (0,2) | normal | 3993 (c) | 3994 (c) | t | t | (0,3) (0,3) | normal | 3994 (c) | 3995 (c) | t | t | (0,4) (0,4) | normal | 3995 (c) | 3996 (c) | t | t | (0,5) (0,5) | normal | 3996 (c) | 3997 | | t | (1,1) (5 rows) 

संस्करण (0.5) में हम एक लिंक (1.1) देखते हैं जो पेज 1 पर जाता है।

 => SELECT * FROM heap_page('hot',1); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+------+-------+-----+-----+-------- (1,1) | normal | 3997 | 0 (a) | | | (1,1) (1 row) 

अब सूचकांक में दो पंक्तियाँ हैं, जिनमें से प्रत्येक इसकी गर्म श्रृंखला की शुरुआत की ओर इशारा करती है:

 => SELECT * FROM index_page('hot_id',1); 

  itemoffset | ctid ------------+------- 1 | (1,1) 2 | (0,1) (2 rows) 

दुर्भाग्य से, इन-पेज सफाई और HOT-अपडेट के बारे में जानकारी प्रलेखन में व्यावहारिक रूप से अनुपस्थित है, और स्रोत कोड में सच्चाई की तलाश की जानी चाहिए। मैं README.HOT से शुरू करने की सलाह देता हूं ।

जारी रखा जाए ।