पूर्ण-पाठ सूचकांक रखरखाव के लिए दिशानिर्देश

Question

पूर्ण-पाठ अनुक्रमणिका बनाए रखने के लिए क्या दिशा-निर्देशों पर विचार किया जाना चाहिए?

क्या मुझे पूर्ण-पाठ सूची ( BOL देखें ) को REBUILD या REORGANIZE करना चाहिए ? एक उचित रखरखाव ताल क्या है? रखरखाव की आवश्यकता होने पर यह निर्धारित करने के लिए कि क्या आंकड़े (10% और 30% विखंडन दहलीज के समान) का उपयोग किया जा सकता है?

(नीचे सब कुछ बस अतिरिक्त जानकारी पर विस्तृत है और दिखा रहा है कि मैंने अब तक क्या सोचा है।)

अतिरिक्त जानकारी: मेरा प्रारंभिक शोध

बी-ट्री इंडेक्स मेंटेनेंस पर बहुत सारे संसाधन हैं (उदाहरण के लिए, यह सवाल , ओला हैलेनग्रेन की स्क्रिप्ट , और अन्य साइटों से इस विषय पर कई ब्लॉग पोस्ट)। हालाँकि, मैंने पाया है कि इनमें से कोई भी संसाधन फुलटेक्स इंडेक्स को बनाए रखने के लिए सिफारिशें या स्क्रिप्ट प्रदान नहीं करता है।

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

मुझे यह प्रश्न भी मिला , लेकिन यह मुख्य रूप से परिवर्तन-ट्रैकिंग (अंतर्निहित तालिका में डेटा अपडेट कैसे फुलटेक्स इंडेक्स में प्रचारित किया गया है) पर केंद्रित है और नियमित रूप से अनुसूचित रखरखाव के प्रकार पर नहीं जो सूचकांक की दक्षता को अधिकतम कर सकता है।

अतिरिक्त जानकारी: बुनियादी प्रदर्शन परीक्षण

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

भले ही इस स्क्रिप्ट में अपडेट स्टेटमेंट काफी कंट्रोवर्सी में थे, लेकिन इस डेटा से पता चलता है कि रेगुलर मेंटेनेंस के लिए बहुत कुछ हासिल करना है।

अतिरिक्त जानकारी: प्रारंभिक विचार

मैं एक रात या साप्ताहिक कार्य बनाने के बारे में सोच रहा हूं। ऐसा लगता है कि यह कार्य या तो REBUILD या REORGANIZE कर सकता है।

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

Answer 1

मुझे कोई भी अच्छा संसाधन ऑनलाइन नहीं मिल रहा था, इसलिए मैंने कुछ और शोध किए और सोचा कि उस पूर्ण-पाठ रखरखाव योजना को पोस्ट करना उपयोगी होगा जिसे हम उस शोध के आधार पर लागू कर रहे हैं।

रखरखाव की आवश्यकता होने पर यह निर्धारित करने के लिए हमारा अनुमान

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

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

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

रखरखाव की योजना

हमने प्रत्येक पूर्ण-पाठ अनुक्रमणिका के लिए विखंडन% की गणना करने के लिए निम्न कोड का उपयोग करने का निर्णय लिया है। कम से कम 10% के विखंडन के साथ गैर-तुच्छ आकार के किसी भी पूर्ण-पाठ अनुक्रमणिका को हमारे रात के रख-रखाव द्वारा फिर से बनाया जाएगा।

-- Compute fragmentation information for all full-text indexes on the database
SELECT c.fulltext_catalog_id, c.name AS fulltext_catalog_name, i.change_tracking_state,
    i.object_id, OBJECT_SCHEMA_NAME(i.object_id) + '.' + OBJECT_NAME(i.object_id) AS object_name,
    f.num_fragments, f.fulltext_mb, f.largest_fragment_mb,
    100.0 * (f.fulltext_mb - f.largest_fragment_mb) / NULLIF(f.fulltext_mb, 0) AS fulltext_fragmentation_in_percent
INTO #fulltextFragmentationDetails
FROM sys.fulltext_catalogs c
JOIN sys.fulltext_indexes i
    ON i.fulltext_catalog_id = c.fulltext_catalog_id
JOIN (
    -- Compute fragment data for each table with a full-text index
    SELECT table_id,
        COUNT(*) AS num_fragments,
        CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS fulltext_mb,
        CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb
    FROM sys.fulltext_index_fragments
    GROUP BY table_id
) f
    ON f.table_id = i.object_id

-- Apply a basic heuristic to determine any full-text indexes that are "too fragmented"
-- We have chosen the 10% threshold based on performance benchmarking on our own data
-- Our over-night maintenance will then drop and re-create any such indexes
SELECT *
FROM #fulltextFragmentationDetails
WHERE fulltext_fragmentation_in_percent >= 10
    AND fulltext_mb >= 1 -- No need to bother with indexes of trivial size

इन प्रश्नों के परिणाम निम्नलिखित जैसे हैं, और इस स्थिति में 1, 6, और 9 को इष्टतम प्रदर्शन के लिए बहुत अधिक खंडित किया जाएगा क्योंकि पूर्ण-पाठ अनुक्रमणिका 1MB से अधिक और कम से कम 10% खंडित है।

अनुरक्षण ताल

हमारे पास पहले से ही एक रात का रखरखाव खिड़की है, और गणना करने के लिए विखंडन गणना बहुत सस्ती है। इसलिए हम प्रत्येक रात इस चेक को चलाएंगे और तब केवल 10% विखंडन सीमा के आधार पर आवश्यक होने पर एक पूर्ण-पाठ सूचकांक के पुनर्निर्माण के अधिक महंगे संचालन का प्रदर्शन करेंगे।

REBUILD बनाम REORGANIZE बनाम DROP / CREATE

SQL सर्वर प्रदान करता है REBUILDऔर REORGANIZEविकल्प, लेकिन वे केवल पूर्ण-पाठ कैटलॉग के लिए उपलब्ध हैं (जिसमें पूर्ण-पाठ अनुक्रमणिका की संख्या हो सकती है)। विरासत के कारणों के लिए, हमारे पास एक पूर्ण-पाठ सूची है जिसमें हमारे सभी पूर्ण-पाठ अनुक्रमित हैं। इसलिए, हमने इसके बजाय एक व्यक्तिगत पूर्ण-पाठ इंडेक्स स्तर पर छोड़ने ( DROP FULLTEXT INDEX) और फिर से बनाने ( CREATE FULLTEXT INDEX) का विकल्प चुना है ।

पूर्ण-पाठ अनुक्रमणिका को अलग-अलग कैटलॉग में तार्किक तरीके से तोड़ने और REBUILDइसके बजाय प्रदर्शन करने के लिए यह अधिक आदर्श हो सकता है , लेकिन इस बीच ड्रॉप / क्रिएट सॉल्यूशन हमारे लिए काम करेगा।