मेसेंजर डेटाबेस (भाग 2): “नफ्यासाठी” विभाजन

पत्रव्यवहार संचयित करण्यासाठी आम्ही आमच्या PostgreSQL डेटाबेसची रचना यशस्वीरित्या तयार केली आहे, एक वर्ष उलटून गेले आहे, वापरकर्ते सक्रियपणे ते भरत आहेत आणि आता त्यात समाविष्ट आहे लाखो रेकॉर्ड, आणि... काहीतरी मंद होऊ लागले.

• भाग 1: बेस फ्रेम डिझाइन करणे
• भाग 2: "नफ्यासाठी" विभाग करणे

पॉइंट आहे सारणीचा आकार जसजसा वाढत जातो, तसतसे निर्देशांकांची “खोली” वाढते. - जरी लॉगरिदमिकदृष्ट्या. परंतु कालांतराने हे सर्व्हरला समान वाचन/लेखन कार्ये करण्यास भाग पाडते डेटाच्या अनेक पट अधिक पृष्ठांवर प्रक्रिया करासुरुवातीला पेक्षा.

इथेच तो बचावासाठी येतो विभागणी.

मी लक्षात घेतो की आम्ही शार्डिंगबद्दल बोलत नाही आहोत, म्हणजेच वेगवेगळ्या डेटाबेस किंवा सर्व्हरमध्ये डेटा वितरित करणे. कारण अगदी मध्ये डेटा विभागणे अनेक सर्व्हर, आपण कालांतराने निर्देशांक "सूज" च्या समस्येपासून मुक्त होणार नाही. हे स्पष्ट आहे की जर तुम्हाला दररोज नवीन सर्व्हर कार्यान्वित करणे परवडत असेल, तर तुमच्या समस्या यापुढे विशिष्ट डेटाबेसच्या प्लेनमध्ये अजिबात राहणार नाहीत.

आम्ही "हार्डवेअरमध्ये" विभाजनाची अंमलबजावणी करण्यासाठी विशिष्ट स्क्रिप्टचा विचार करणार नाही, परंतु दृष्टिकोन स्वतःच - काय आणि कसे "स्लाइसमध्ये कापले जावे" आणि अशा इच्छेमुळे काय होते.

संकल्पना

चला आमचे ध्येय पुन्हा एकदा परिभाषित करूया: आम्ही हे सुनिश्चित करू इच्छितो की आज, उद्या आणि एका वर्षात, कोणत्याही वाचन/लेखन ऑपरेशन दरम्यान PostgreSQL द्वारे वाचलेल्या डेटाचे प्रमाण अंदाजे समान राहील.

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

लक्षात घ्या की वापरकर्ते जवळजवळ नेहमीच फक्त "नवीनतम" सह कार्य करा असा डेटा - ते नवीनतम संदेश वाचतात, नवीनतम नोंदींचे विश्लेषण करतात,... नाही, नक्कीच, ते वेळेत आणखी मागे स्क्रोल करू शकतात, परंतु ते हे फार क्वचितच करतात.

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

जर आपण दिवसभरात जवळजवळ फक्त एका विभागात लिहितो आणि वाचतो, तर हे देखील आपल्याला देते मेमरी आणि डिस्कचा अधिक कार्यक्षम वापर - सर्व विभाग निर्देशांक सहजपणे RAM मध्ये बसतात, संपूर्ण टेबलमधील "मोठे आणि चरबी" च्या उलट.

क्रमाक्रमाने

सर्वसाधारणपणे, वर सांगितलेली प्रत्येक गोष्ट एक सतत नफा सारखी वाटते. आणि ते साध्य आहे, परंतु यासाठी आपल्याला कठोर प्रयत्न करावे लागतील - कारण घटकांपैकी एकाचे विभाजन करण्याच्या निर्णयामुळे संबंधितांना “पाहिले” जावे लागते.

संदेश, त्याचे गुणधर्म आणि अंदाज

आम्ही तारखांनुसार संदेश कापण्याचा निर्णय घेतल्यामुळे, त्यांच्यावर अवलंबून असलेल्या संस्था-गुणधर्म (संलग्न फायली, प्राप्तकर्त्यांची यादी) विभाजित करणे देखील अर्थपूर्ण आहे. संदेशाच्या तारखेनुसार देखील.

आमच्या ठराविक कामांपैकी एक म्हणजे मेसेज रजिस्टर्स (न वाचलेले, येणारे, सर्व) तंतोतंत पाहणे, मेसेज तारखांनुसार विभाजन करण्यासाठी "त्यांना काढणे" हे देखील तर्कसंगत आहे.

आम्ही सर्व सारण्यांमध्ये विभाजन की (संदेश तारीख) जोडतो: प्राप्तकर्ते, फाइल, नोंदणी. तुम्हाला ते मेसेजमध्येच जोडण्याची गरज नाही, परंतु सध्याची तारीख वेळ वापरा.

थ्रेड

अनेक संदेशांसाठी एकच विषय असल्याने, त्याच मॉडेलमध्ये "कट" करण्याचा कोणताही मार्ग नाही; तुम्हाला दुसऱ्या कशावर तरी अवलंबून राहावे लागेल. आमच्या बाबतीत ते आदर्श आहे पत्रव्यवहारातील पहिल्या संदेशाची तारीख — म्हणजे, निर्मितीचा क्षण, खरं तर, विषयाचा.

सर्व सारण्यांमध्ये विभाजन की (विषय तारीख) जोडा: विषय, सहभागी.

परंतु आता आम्हाला एकाच वेळी दोन समस्या आहेत:

• मी विषयावरील संदेश कोणत्या विभागात शोधायचे?
• मी संदेशातील विषय कोणत्या विभागात शोधायचा?

आम्ही अर्थातच, सर्व विभागांमध्ये शोध सुरू ठेवू शकतो, परंतु हे खूप दुःखदायक असेल आणि आमचे सर्व विजय नाकारतील. म्हणून, नेमके कुठे पाहायचे हे जाणून घेण्यासाठी, आम्ही विभागांना तार्किक दुवे/पॉइंटर बनवू:

• आम्ही संदेशात जोडू विषय तारीख फील्ड
• विषय जोडूया संदेश तारीख सेट हा पत्रव्यवहार (एक स्वतंत्र सारणी किंवा तारखांची अॅरे असू शकते)

प्रत्येक वैयक्तिक पत्रव्यवहारासाठी संदेश तारखांच्या सूचीमध्ये काही बदल केले जातील (अखेर, जवळजवळ सर्व संदेश 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