मेसेन्जर डाटाबेस (भाग २): विभाजन "लाभको लागि"

हामीले पत्राचार भण्डारण गर्नको लागि हाम्रो PostgreSQL डाटाबेसको संरचना सफलतापूर्वक डिजाइन गरेका छौं, एक वर्ष बितिसकेको छ, प्रयोगकर्ताहरूले यसलाई सक्रिय रूपमा भरिरहेका छन्, र अब यसमा समावेश छ। लाखौं रेकर्डहरूर... केही सुस्त हुन थाल्यो।

• भाग १: आधार फ्रेम डिजाइन गर्दै
• भाग २: "लाभको लागि" खण्ड

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

यो जहाँ यो उद्धार को लागी आउँछ खण्डीकरण.

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

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

अवधारणा

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

कुनै पनि को लागी कालानुक्रमिक रूपमा संचित डाटा (सन्देशहरू, कागजातहरू, लगहरू, अभिलेखहरू, ...) विभाजन कुञ्जीको रूपमा प्राकृतिक छनौट हो। घटना मिति/समय। हाम्रो मामला मा, यस्तो घटना छ सन्देश पठाउने क्षण.

नोट गर्नुहोस् कि प्रयोगकर्ताहरू लगभग सधैं "नवीनतम" सँग मात्र काम गर्नुहोस् यस्तो डेटा - तिनीहरूले भर्खरका सन्देशहरू पढ्छन्, नवीनतम लगहरू विश्लेषण गर्छन्, ... होइन, निस्सन्देह, तिनीहरूले समय मा अगाडी स्क्रोल गर्न सक्छन्, तर तिनीहरूले यो धेरै विरलै गर्छन्।

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

यदि हामी दिनमा लगभग एक खण्डमा मात्र लेख्छौं र पढ्छौं भने, यसले हामीलाई पनि दिन्छ मेमोरी र डिस्कको अधिक कुशल प्रयोग - किनकि सबै खण्ड अनुक्रमणिकाहरू सजिलैसँग RAM मा फिट हुन्छन्, तालिकामा "ठूलो र फ्याट" को विपरीत।

चरण-चरण

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

सन्देश, यसको गुण र अनुमानहरू

हामीले मिति अनुसार सन्देशहरू काट्ने निर्णय गरेकाले, तिनीहरूमा निर्भर हुने संस्थाहरू-गुणहरू (संलग्न फाइलहरू, प्राप्तकर्ताहरूको सूची) र सन्देशको मिति अनुसार पनि.

हाम्रो सामान्य कार्यहरू मध्ये एउटा सन्देश दर्ताहरू (नपढिएको, आगमन, सबै) ठ्याक्कै हेर्नु भएकोले, सन्देश मितिहरूद्वारा विभाजनमा "तिनीहरूलाई तान्नु" पनि तार्किक छ।

हामी सबै तालिकाहरूमा विभाजन कुञ्जी (सन्देश मिति) थप्छौं: प्राप्तकर्ताहरू, फाइलहरू, रजिस्ट्रीहरू। तपाईंले यसलाई सन्देशमा नै थप्नु पर्दैन, तर अवस्थित मिति समय प्रयोग गर्नुहोस्।

सूत्रहरू

धेरै सन्देशहरूको लागि एउटा मात्र विषय भएकोले, त्यहाँ एउटै मोडेलमा "कट" गर्ने कुनै तरिका छैन; तपाईंले अरू केहीमा भर पर्नु पर्छ। हाम्रो मामला मा यो आदर्श छ पत्राचारमा पहिलो सन्देशको मिति - त्यो हो, सृष्टिको क्षण, वास्तवमा, विषयको।

सबै तालिकाहरूमा विभाजन कुञ्जी (विषय मिति) थप्नुहोस्: विषय, सहभागी।

तर अब हामीसँग एकैचोटि दुई समस्याहरू छन्:

• कुन खण्डमा मैले शीर्षकमा सन्देशहरू खोज्नु पर्छ?
• कुन खण्डमा मैले सन्देशबाट विषय खोज्नु पर्छ?

हामी, अवश्य पनि, सबै खण्डहरूमा खोजी गर्न जारी राख्न सक्छौं, तर यो धेरै दुखको कुरा हुनेछ र हाम्रा सबै जीतहरूलाई अस्वीकार गर्नेछ। तसर्थ, ठ्याक्कै कहाँ हेर्ने भनेर जान्नको लागि, हामी खण्डहरूमा तार्किक लिङ्कहरू/प्वाइंटरहरू बनाउनेछौं:

• हामी सन्देशमा थप्नेछौं विषय मिति क्षेत्र
• विषय थपौं सन्देश मिति सेट यो पत्राचार (एक अलग तालिका, वा मितिहरूको एर्रे हुन सक्छ)

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

कुलमा, हाम्रो डाटाबेसको संरचनाले विभाजनलाई ध्यानमा राख्दै निम्न फारम लियो:

तालिकाहरू: RU, यदि तपाईंसँग तालिकाहरू/फिल्डहरूको नाममा सिरिलिक वर्णमालाप्रति घृणा छ भने, यो नहेर्नु राम्रो हुन्छ।

-- секции по дате сообщения
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