PostgreSQL में विरल डेटा का प्रतिनिधित्व

मैं मान रहा हूँ कि आप गणितीय संदर्भ से विरल मैट्रिक्स के बारे में सोच रहे हैं:http://en.wikipedia। org/wiki/Sparse_matrix (वहां वर्णित भंडारण तकनीकें मेमोरी स्टोरेज (तेज अंकगणितीय ऑपरेशन) के लिए हैं, न कि लगातार स्टोरेज (कम डिस्क उपयोग) के लिए।)

चूंकि कोई आमतौर पर सर्वर साइड के बजाय क्लाइंट साइड पर इस मैट्रिसेस पर काम करता है, इसलिए SQL-ARRAY[] सबसे अच्छा विकल्प है!

सवाल यह है कि मैट्रिक्स की विरलता का लाभ कैसे उठाया जाए? यहाँ कुछ जाँचों के परिणाम हैं।

सेटअप:

• 8.4 पोस्ट करता है
• मैट्रिसेस w/ 400*400 एलीमेंट डबल प्रिसिजन (8 बाइट्स) में -> 1.28MiB रॉ साइज प्रति मैट्रिक्स
• 33% गैर-शून्य तत्व -> 427kiB प्रति मैट्रिक्स प्रभावी आकार
• ~1000 विभिन्न यादृच्छिक आबादी वाले मैट्रिक्स का उपयोग करके औसत

प्रतिस्पर्धा के तरीके:

• स्वचालित पर भरोसा करें सर्वर साइड संपीड़न SET STORAGE MAIN या EXTENDED के साथ कॉलम का।
• केवल गैर-शून्य तत्वों और एक बिटमैप . को संग्रहित करें (bit varying(xx) ) मैट्रिक्स में गैर-शून्य तत्वों का पता लगाने का वर्णन करना। (एक डबल परिशुद्धता एक बिट से 64 गुना बड़ा है। सिद्धांत रूप में (ओवरहेड को अनदेखा करना) इस विधि में सुधार होना चाहिए यदि <=98% गैर-शून्य हैं;-)।) सर्वर साइड संपीड़न सक्रिय है।
• बदलें मैट्रिक्स में शून्य NULL के साथ . (RDBMS NULLs को स्टोर करने में बहुत प्रभावी हैं।) सर्वर साइड कम्प्रेशन सक्रिय है।

(दूसरी अनुक्रमणिका-ARRAY[] का उपयोग करके गैर-शून्य तत्वों का अनुक्रमण बहुत आशाजनक नहीं है और इसलिए इसका परीक्षण नहीं किया गया है।)

परिणाम:

• स्वचालित संपीड़न
  • कोई अतिरिक्त कार्यान्वयन प्रयास नहीं
  • कोई कम नेटवर्क ट्रैफ़िक नहीं
  • न्यूनतम संपीड़न ओवरहेड
  • लगातार भंडारण =कच्चे आकार का 39%
• बिटमैप
  • स्वीकार्य कार्यान्वयन प्रयास
  • नेटवर्क ट्रैफ़िक थोड़ा कम हुआ; विरलता पर निर्भर
  • लगातार भंडारण =कच्चे आकार का 33.9%
• शून्य को NULLs से बदलें
  • कुछ कार्यान्वयन प्रयास (API को यह जानने की आवश्यकता है कि INSERT क्वेरी का निर्माण करते समय ARRAY[] में NULLs कहाँ और कैसे सेट करें)
  • नेटवर्क ट्रैफ़िक में कोई बदलाव नहीं
  • लगातार भंडारण =कच्चे आकार का 35%

निष्कर्ष:विस्तारित/मुख्य भंडारण पैरामीटर से प्रारंभ करें। यदि आपके पास कुछ खाली समय है तो अपने डेटा की जांच करें और अपने विरल स्तर के साथ मेरे परीक्षण सेटअप का उपयोग करें। लेकिन प्रभाव आपकी अपेक्षा से कम हो सकता है।

मेरा सुझाव है कि मैट्रिक्स आयाम NxM के लिए हमेशा मैट्रिक्स क्रमांकन (जैसे पंक्ति-प्रमुख क्रम) प्लस दो पूर्णांक स्तंभों का उपयोग करें। चूंकि अधिकांश एपीआई टेक्स्टुअल SQL का उपयोग करते हैं, इसलिए आप नेस्टेड "ARRAY[ARRAY[..], ARRAY[..], ARRAY[..], ARRAY[..], ..]" के लिए बहुत सारे नेटवर्क ट्रैफ़िक और क्लाइंट मेमोरी को बचा रहे हैं। !!!

टेबस

CREATE TABLE _testschema.matrix_dense
(
  matdata double precision[]
);
ALTER TABLE _testschema.matrix_dense ALTER COLUMN matdata SET STORAGE EXTERN;


CREATE TABLE _testschema.matrix_sparse_autocompressed
(
  matdata double precision[]
);

CREATE TABLE _testschema.matrix_sparse_bitmap
(
  matdata double precision[]
  bitmap bit varying(8000000)
);

सभी तालिकाओं में समान मैट्रिक्स डालें। ठोस डेटा निश्चित तालिका पर निर्भर करता है। अप्रयुक्त लेकिन आवंटित पृष्ठों के कारण सर्वर साइड पर डेटा को न बदलें। या वैक्यूम करें।

SELECT 
pg_total_relation_size('_testschema.matrix_dense') AS dense, 
pg_total_relation_size('_testschema.matrix_sparse_autocompressed') AS autocompressed, 
pg_total_relation_size('_testschema.matrix_sparse_bitmap') AS bitmap;