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

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

• भाग 1: आधार फ़्रेम को डिज़ाइन करना
• भाग 2: "लाभ के लिए" अनुभागीकरण

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

यहीं बचाव की बात आती है सेक्शनिंग.

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

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

संकल्पना

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

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

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

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

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

क्रमशः

सामान्य तौर पर, ऊपर कही गई हर बात एक निरंतर लाभ की तरह लगती है। और यह साध्य है, लेकिन इसके लिए हमें कड़ी मेहनत करनी होगी - क्योंकि किसी एक इकाई को विभाजित करने का निर्णय संबंधित को "देखने" की आवश्यकता की ओर ले जाता है.

संदेश, उसके गुण और प्रक्षेपण

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

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

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

टॉपिक्स

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

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

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

• मुझे इस विषय पर संदेशों को किस अनुभाग में देखना चाहिए?
• मुझे संदेश के विषय को किस अनुभाग में देखना चाहिए?

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

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

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

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

तालिकाएँ: आरयू, यदि आपको तालिकाओं/फ़ील्डों के नाम में सिरिलिक वर्णमाला से घृणा है, तो इसे न देखना ही बेहतर है

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

CREATE TABLE "РеестрСообщений_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений_YYYYMMDD"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "УчастникТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

एक अच्छा पैसा बचाएं

खैर, अगर हम इसका इस्तेमाल नहीं करेंगे तो क्या होगा क्लासिक सेक्शनिंग विकल्प फ़ील्ड मानों के वितरण (ट्रिगर और इनहेरिटेंस या PARTITION BY के माध्यम से), और एप्लिकेशन स्तर पर "मैन्युअल रूप से" के आधार पर, आप देखेंगे कि विभाजन कुंजी का मान पहले से ही तालिका के नाम पर संग्रहीत है।

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

स्रोत: www.habr.com