SQL सर्वर में डेटा संपीड़न बचत का अनुमान लगाएं

SQL सर्वर में एक सिस्टम संग्रहीत कार्यविधि होती है जिसे sp_estimate_data_compression_savings . कहा जाता है , जो आपको संपीड़न के विभिन्न स्तरों के साथ किसी वस्तु के आकार और उसके अनुमानित आकार की जांच करने की अनुमति देता है।

यदि वस्तु पहले से ही संकुचित है, तो आप इस प्रक्रिया का उपयोग पुन:संपीड़ित होने पर इसके आकार का अनुमान लगाने के लिए कर सकते हैं।

ऑब्जेक्ट को रो, पेज, कॉलमस्टोर या कॉलमस्टोर आर्काइव कम्प्रेशन का उपयोग करके कंप्रेस किया जा सकता है।

संपूर्ण तालिकाओं या तालिकाओं के कुछ हिस्सों के लिए संपीड़न का मूल्यांकन किया जा सकता है। इसमें ढेर, क्लस्टर इंडेक्स, गैर-क्लस्टर इंडेक्स, कॉलमस्टोर इंडेक्स, इंडेक्स किए गए व्यू, और टेबल और इंडेक्स विभाजन शामिल हैं।

उदाहरण

प्रदर्शित करने के लिए यहां एक उदाहरण दिया गया है।

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'Warehouse', 
    @object_name = 'StockItemHoldings', 
    @index_id = NULL, 
    @partition_number = NULL, 
    @data_compression = 'ROW';

परिणाम:

+-------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------+
| object_name       | schema_name   | index_id   | partition_number   | size_with_current_compression_setting(KB)   | size_with_requested_compression_setting(KB)   | sample_size_with_current_compression_setting(KB)   | sample_size_with_requested_compression_setting(KB)   |
|-------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------|
| StockItemHoldings | Warehouse     | 1          | 1                  | 32                                          | 8                                             | 40                                                 | 16                                                   |
+-------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------+

आपको बहुत अधिक बग़ल में स्क्रॉल करने से बचाने के लिए, यहाँ यह फिर से लंबवत आउटपुट का उपयोग कर रहा है:

-[ RECORD 1 ]-------------------------
object_name                                        | StockItemHoldings
schema_name                                        | Warehouse
index_id                                           | 1
partition_number                                   | 1
size_with_current_compression_setting(KB)          | 32
size_with_requested_compression_setting(KB)        | 8
sample_size_with_current_compression_setting(KB)   | 40
sample_size_with_requested_compression_setting(KB) | 16

संपीड़न आकार किलोबाइट्स (KB) में हैं।

इस मामले में, इस तालिका पर पंक्ति संपीड़न का उपयोग करने में एक महत्वपूर्ण लाभ प्रतीत होता है। यह 32 केबी से 8 केबी तक जाता है। यह मानता है कि यह एक सटीक अनुमान है।

जब मैंने पिछला कोड चलाया, तो मैंने सभी तर्क नाम प्रदान किए। आप इन नामों को छोड़ भी सकते हैं, और केवल मान प्रदान कर सकते हैं।

इस तरह:

EXEC sp_estimate_data_compression_savings 
    'Warehouse', 
    'StockItemHoldings', 
    NULL, 
    NULL, 
    'ROW';

किसी भी तरह से, परिणाम वही है।

यहाँ यह फिर से है, लेकिन इस बार मैं निर्दिष्ट करता हूँ PAGE ROW . के बजाय संपीड़न प्रकार के रूप में।

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'Warehouse', 
    @object_name = 'StockItemHoldings', 
    @index_id = NULL, 
    @partition_number = NULL, 
    @data_compression = 'PAGE';

परिणाम (ऊर्ध्वाधर आउटपुट का उपयोग करके):

-[ RECORD 1 ]-------------------------
object_name                                        | StockItemHoldings
schema_name                                        | Warehouse
index_id                                           | 1
partition_number                                   | 1
size_with_current_compression_setting(KB)          | 32
size_with_requested_compression_setting(KB)        | 8
sample_size_with_current_compression_setting(KB)   | 40
sample_size_with_requested_compression_setting(KB) | 16

इस मामले में, संख्याएं समान दिखती हैं, लेकिन आप अपने डेटा के आधार पर बहुत भिन्न संख्याएं प्राप्त कर सकते हैं।

संपीड़न प्रकार

@data_compression तर्क निम्नलिखित मूल्यों को स्वीकार करता है:

• NONE
• ROW
• PAGE
• COLUMNSTORE
• COLUMNSTORE_ARCHIVE

तालिका या अनुक्रमणिका बनाते/बदलते समय ये संपीड़न विकल्प उपलब्ध होते हैं।

COLUMNSTORE और COLUMNSTORE_ARCHIVE विकल्प केवल कॉलमस्टोर इंडेक्स (गैर-क्लस्टर किए गए कॉलमस्टोर और क्लस्टर्ड कॉलमस्टोर इंडेक्स दोनों सहित) पर उपलब्ध हैं।

@index_id तर्क

कभी-कभी आपके परिणाम किसी दिए गए ऑब्जेक्ट के लिए कई पंक्तियाँ लौटा सकते हैं, प्रत्येक एक अलग index_id . के साथ ।

यदि आप चाहें तो आप इसे एक विशिष्ट सूचकांक तक सीमित कर सकते हैं। ऐसा करने के लिए, index_id . प्रदान करें @index_id . पर तर्क।

उदाहरण के लिए, जब मैं निम्नलिखित कोड चलाता हूं, तो आठ पंक्तियाँ दी जाती हैं, प्रत्येक अलग index_id के साथ मान।

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'Warehouse', 
    @object_name = 'StockItemTransactions', 
    @index_id = NULL, 
    @partition_number = NULL, 
    @data_compression = 'ROW';

परिणाम:

+-----------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------+
| object_name           | schema_name   | index_id   | partition_number   | size_with_current_compression_setting(KB)   | size_with_requested_compression_setting(KB)   | sample_size_with_current_compression_setting(KB)   | sample_size_with_requested_compression_setting(KB)   |
|-----------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------|
| StockItemTransactions | Warehouse     | 2          | 1                  | 5568                                        | 4120                                          | 4280                                               | 3168                                                 |
| StockItemTransactions | Warehouse     | 3          | 1                  | 5184                                        | 3720                                          | 4264                                               | 3064                                                 |
| StockItemTransactions | Warehouse     | 4          | 1                  | 5568                                        | 4224                                          | 4288                                               | 3256                                                 |
| StockItemTransactions | Warehouse     | 5          | 1                  | 5528                                        | 4416                                          | 4280                                               | 3424                                                 |
| StockItemTransactions | Warehouse     | 6          | 1                  | 5192                                        | 3456                                          | 4264                                               | 2840                                                 |
| StockItemTransactions | Warehouse     | 7          | 1                  | 5192                                        | 3464                                          | 4264                                               | 2848                                                 |
| StockItemTransactions | Warehouse     | 9          | 1                  | 5416                                        | 4456                                          | 4264                                               | 3512                                                 |
| StockItemTransactions | Warehouse     | 1          | 1                  | 2720                                        | 9096                                          | 2720                                               | 9096                                                 |
+-----------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------+

यदि हम इसे केवल एक पंक्ति तक सीमित करना चाहते हैं, तो हम इसकी index_id . का उपयोग कर सकते हैं ।

इस तरह:

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'Warehouse', 
    @object_name = 'StockItemTransactions', 
    @index_id =1, 
    @partition_number = NULL, 
    @data_compression = 'ROW';

परिणाम:

+-----------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------+
| object_name           | schema_name   | index_id   | partition_number   | size_with_current_compression_setting(KB)   | size_with_requested_compression_setting(KB)   | sample_size_with_current_compression_setting(KB)   | sample_size_with_requested_compression_setting(KB)   |
|-----------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------|
| StockItemTransactions | Warehouse     | 1          | 1                  | 2720                                        | 9096                                          | 2720                                               | 9096                                                 |
+-----------------------+---------------+------------+--------------------+---------------------------------------------+-----------------------------------------------+----------------------------------------------------+------------------------------------------------------+

आप @partition_number . का भी उपयोग कर सकते हैं विभाजन के साथ भी ऐसा ही करने के लिए।

संपीड़न की मात्रा महत्वपूर्ण रूप से भिन्न हो सकती है

आपको मिलने वाली कंप्रेशन की मात्रा डेटा और कंप्रेशन के प्रकार पर निर्भर करेगी।

ROW संपीड़न, उदाहरण के लिए, कॉलम मानों से अनावश्यक बाइट्स को चर लंबाई प्रारूप में संग्रहीत करके हटा देता है। PAGE दूसरी ओर, संपीड़न, प्रति पृष्ठ केवल एक बार दोहराए जाने वाले मानों को संग्रहीत करता है, और पृष्ठ के भीतर संबंधित कॉलम से पॉइंटर सेट करता है।

कभी-कभी आप पाते हैं कि किसी वस्तु को संपीड़ित करने से उसका आकार हमेशा कम नहीं होता है, और कुछ मामलों में वास्तव में वृद्धि हो सकती है इसका आकार।

ऐसा तब हो सकता है जब आपके कॉलम ऐसे डेटा प्रकार का उपयोग करते हैं जो संपीड़न से लाभान्वित नहीं होता है।

इसके अलावा, पंक्ति संपीड़न मेटाडेटा ओवरहेड को कम करता है, लेकिन कुछ मामलों में ओवरहेड पुराने स्टोरेज प्रारूप से अधिक हो सकता है।

यदि आपके डेटा को उसके डेटा प्रकार के कारण संपीड़न से कोई लाभ नहीं मिलता है, तो हो सकता है कि ओवरहेड कम होने के बजाय भंडारण आवश्यकताओं में वृद्धि का कारण बने।

लेकिन संपीड़न आकार में बदलाव वास्तविक डेटा पर भी निर्भर करेगा। उदाहरण के लिए, यदि आपके पास char(10) . है स्तंभ, संपीड़न किसी भी अनुगामी पैडिंग वर्ण को हटा देगा। यदि आपके पास अनुगामी पैडिंग वर्णों के साथ बहुत सारी पंक्तियाँ हैं, तो आपको एक बेहतर परिणाम प्राप्त करना चाहिए यदि आपके पास अनुगामी पैडिंग वर्णों वाली कोई (या कुछ) पंक्तियाँ नहीं हैं।

यह संपीड़न का अनुमान कैसे लगाता है?

जब आप sp_estimate_data_compression_savings execute निष्पादित करते हैं , यह डेटा का एक नमूना लेता है, और फिर इसे tempdb में बनाई गई समकक्ष तालिका और अनुक्रमणिका में लोड करता है . tempdb . में बनाई गई तालिका या अनुक्रमणिका फिर अनुरोधित सेटिंग में संपीड़ित किया जाता है और अनुमानित संपीड़न बचत की गणना की जाती है।

यह कितना सटीक है?

sp_estimate_data_compression_savings . का इस्तेमाल करने पर आपको मिले-जुले नतीजे मिल सकते हैं .

आइए थोड़ा परीक्षण करें।

SELECT * INTO Warehouse.StockItemTransactions2
FROM Warehouse.StockItemTransactions;

EXEC sp_spaceused 'Warehouse.StockItemTransactions2';

परिणाम (ऊर्ध्वाधर आउटपुट का उपयोग करके):

name       | StockItemTransactions2
rows       | 236667              
reserved   | 15944 KB
data       | 15800 KB
index_size | 8 KB
unused     | 136 KB

sp_spaceused संग्रहीत प्रक्रिया हमें उपयोग की गई वास्तविक डिस्क स्थान दिखाती है। इस मामले में, डेटा 15,800 KB डिस्क स्थान का उपयोग करता है।

अब, मैं sp_estimate_data_compression_savings निष्पादित करूँगा यह देखने के लिए कि यदि मैं उस तालिका में संपीड़न लागू करता हूं तो मुझे कितनी जगह बचत मिलेगी।

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'Warehouse', 
    @object_name = 'StockItemTransactions2', 
    @index_id = NULL, 
    @partition_number = NULL, 
    @data_compression = 'ROW';

परिणाम (ऊर्ध्वाधर आउटपुट का उपयोग करके):

object_name                                        | StockItemTransactions2
schema_name                                        | Warehouse
index_id                                           | 0
partition_number                                   | 1
size_with_current_compression_setting(KB)          | 15808
size_with_requested_compression_setting(KB)        | 9096
sample_size_with_current_compression_setting(KB)   | 15800
sample_size_with_requested_compression_setting(KB) | 9096

इन परिणामों के अनुसार, इस तालिका में पंक्ति संपीड़न लागू करने से इसका आकार 15,808 KB से घटकर केवल 9,096 KB का अनुमानित आकार हो जाएगा। बहुत बुरा नहीं है।

आइए अब इस तालिका में पंक्ति संपीड़न लागू करें, और फिर sp_spaceused चलाएं फिर से।

ALTER TABLE Warehouse.StockItemTransactions2
REBUILD WITH (DATA_COMPRESSION = ROW);

EXEC sp_spaceused 'Warehouse.StockItemTransactions2';

परिणाम (ऊर्ध्वाधर आउटपुट का उपयोग करके):

name       | StockItemTransactions2
rows       | 236667              
reserved   | 9160 KB
data       | 9088 KB
index_size | 8 KB

तो वास्तविक परिणाम अनुमानित परिणाम के बहुत करीब है।

इस मामले में, sp_estimate_data_compression_savings अंतिम परिणाम का काफी सटीक अनुमान प्रदान किया।

चलिए sp_estimate_data_compression_savingsचलाते हैं एक बार और बार, लेकिन NONE . के संपीड़न प्रकार का उपयोग करके ।

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'Warehouse', 
    @object_name = 'StockItemTransactions2', 
    @index_id = NULL, 
    @partition_number = NULL, 
    @data_compression = 'NONE';

परिणाम:

object_name                                        | StockItemTransactions2
schema_name                                        | Warehouse
index_id                                           | 0
partition_number                                   | 1
size_with_current_compression_setting(KB)          | 9096
size_with_requested_compression_setting(KB)        | 15808
sample_size_with_current_compression_setting(KB)   | 9096
sample_size_with_requested_compression_setting(KB) | 15808

यह हमें बताता है कि क्या होगा यदि हम बिना किसी संपीड़न का उपयोग करने के लिए वापस लौट आए।

इस मामले में यह हमें ठीक उसी संख्या (15,808 KB) को दिखा रहा है जो उसने हमें संपीड़न लागू करने से पहले दिखाया था, जैसा कि आपको याद होगा, sp_spaceused द्वारा लौटाए गए वास्तविक आकार (15,800 KB) के काफी करीब था। कोड> प्रक्रिया।

तो चलिए इसे फिर से चलाते हैं और पता करते हैं।

ALTER TABLE Warehouse.StockItemTransactions2
REBUILD WITH (DATA_COMPRESSION = NONE);

EXEC sp_spaceused 'Warehouse.StockItemTransactions2';

परिणाम (ऊर्ध्वाधर आउटपुट का उपयोग करके):

name       | StockItemTransactions2
rows       | 236667              
reserved   | 15880 KB
data       | 15800 KB
index_size | 8 KB
unused     | 72 KB

तो फिर, sp_estimate_data_compression_savings लगभग हाजिर था।

हालाँकि, यह सिर्फ एक साधारण परीक्षण है। अन्य परीक्षण उन अनुमानों को वापस कर सकते हैं जो रास्ते से हटकर हैं। मैंने sp_estimate_data_compression_savings . की कहानियां पढ़ी हैं बेतहाशा गलत परिणाम लौटा रहे हैं, लेकिन मुझे अभी तक खुद इसका अनुभव नहीं हुआ है।

इसलिए, ऐसा प्रतीत होता है कि sp_estimate_data_compression_savings समान मामलों में सटीक अनुमान प्रदान कर सकता है, और दूसरों में इतना नहीं।

आपको यह तय करना होगा कि आप इस संग्रहीत प्रक्रिया में कितना भरोसा करना चाहते हैं। किसी भी मामले में, उत्पादन में संपीड़न लागू करने से पहले आपको शायद अपने विकास या परीक्षण वातावरण में एक परीक्षण चलाना चाहिए।