मैसेंजर डेटाबेस (भाग 2): हम "लाभ" का विभाजन करते हैं

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

• भाग 1: आधार फ्रेम को डिजाइन करना
• भाग 2: "लाभ" का विभाजन

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

यह वह जगह है जहाँ विभाजन बचाव में आता है।

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

हम "हार्डवेयर" में विभाजन को लागू करने के लिए विशिष्ट लिपियों पर विचार नहीं करेंगे, लेकिन दृष्टिकोण खुद - क्या और कैसे "स्लाइस में कटौती," और इस तरह की इच्छा क्या होती है।

संकल्पना

एक बार फिर, हम अपने लक्ष्य को परिभाषित करते हैं: हम यह सुनिश्चित करना चाहते हैं कि आज, कल और एक साल के बाद, किसी भी रीड / राइट ऑपरेशन के दौरान पढ़े जाने वाले PostgreSQL डेटा की संख्या लगभग समान रहे।

किसी भी कालानुक्रमिक रूप से संचित डेटा (संदेश, दस्तावेज, लॉग, अभिलेखागार, ...) के लिए, विभाजन कुंजी के रूप में प्राकृतिक विकल्प घटना की तारीख / समय है । हमारे मामले में, इस तरह की घटना वह क्षण है जब संदेश भेजा गया था ।

ध्यान दें कि उपयोगकर्ता लगभग हमेशा "नवीनतम" ऐसे डेटा के साथ काम करते हैं - वे नवीनतम संदेशों को पढ़ते हैं, नवीनतम लॉग का विश्लेषण करते हैं ... नहीं, निश्चित रूप से, वे समय में आगे पीछे स्क्रॉल कर सकते हैं, केवल यह बहुत कम ही करते हैं।

इन सीमाओं से, यह स्पष्ट हो जाता है कि "दैनिक" अनुभाग संदेशों के लिए सबसे अच्छा समाधान होंगे - आखिरकार, हमारा उपयोगकर्ता लगभग हमेशा "आज" या "कल" ​​जो आया था उसे पढ़ेगा।

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

कदम-दर-कदम

सामान्य तौर पर, उपरोक्त सभी एक ठोस लाभ की तरह लगते हैं। और यह प्राप्त करने योग्य है, लेकिन इसके लिए हमें कड़ी मेहनत करनी होगी - क्योंकि किसी एक संस्था को विभाजित करने के निर्णय से "कट" करने की आवश्यकता होती है और इसके साथ जुड़ा होता है ।

संदेश, इसके गुण और अनुमान

चूंकि हमने तारीखों से संदेशों को काटने का फैसला किया है, इसलिए उन पर निर्भर करते हुए, संस्थाओं-संपत्तियों (संलग्न फ़ाइलों, मेलिंग सूचियों), और संदेश की तारीख से विभाजित करना भी उचित है।

चूंकि हमारा एक सामान्य कार्य केवल संदेश रजिस्टरों (अपठित, आने वाले, सभी) को देख रहा है, इसलिए यह संदेश तिथियों के विभाजन में उन्हें "आकर्षित" करना भी तर्कसंगत है।

सभी तालिकाओं में पार्टीशन कुंजी (संदेश की तारीख) जोड़ें: प्राप्तकर्ता, फ़ाइल, रजिस्ट्रियां। आप स्वयं संदेश में नहीं जोड़ सकते हैं, लेकिन मौजूदा DateTime का उपयोग कर सकते हैं।

सूत्र

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

सभी तालिका में विभाजन कुंजी (विषय तिथि) जोड़ें: विषय, प्रतिभागी।

लेकिन अब हमें एक ही बार में दो समस्याएँ हैं:

• विषय पर पदों की खोज करने के लिए किस अनुभाग में हैं?
• संदेश से किसी विषय की खोज किस अनुभाग में की जाती है?

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

• संदेश में, विषय की तारीख के साथ एक फ़ील्ड जोड़ें
• इस पत्राचार के लिए संदेश तिथियों का एक सेट विषय पर जोड़ें (आप एक अलग तालिका का उपयोग कर सकते हैं, या आप किसी दिनांक का उपयोग कर सकते हैं)

चूंकि प्रत्येक व्यक्तिगत पत्राचार के लिए संदेश की तारीखों की सूची में कुछ संशोधन होंगे (आखिरकार, लगभग सभी संदेश अगले 1-2 दिनों में आते हैं), मैं इस विकल्प पर ध्यान केंद्रित करूंगा।

कुल, विभाजन को ध्यान में रखते हुए, हमारे आधार की संरचना ने निम्नलिखित रूप लिया:

एक सुंदर पैसा बचाओ

ठीक है, अगर हम क्षेत्र के मूल्यों (ट्रिगर और इनहेरिटेंस या पार्टिशन बाय) के वितरण के आधार पर शास्त्रीय विभाजन विकल्प का उपयोग नहीं करते हैं, लेकिन आवेदन स्तर पर "मैन्युअल रूप से", हम देख सकते हैं कि विभाजन कुंजी का मान पहले से ही तालिका के नाम पर संग्रहीत है।

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