मैसेंजर डेटाबेस (भाग 1): आधार ढांचे को डिजाइन करना

शुरुआत से ही मैसेंजर डेटाबेस को डिज़ाइन करने के उदाहरण का उपयोग करके आप व्यावसायिक आवश्यकताओं को विशिष्ट डेटा संरचनाओं में कैसे अनुवादित कर सकते हैं।

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

हमारा आधार उतना बड़ा और वितरित नहीं होगा, VKontakte की तरह या Badoo, लेकिन "ताकि यह था", लेकिन यह अच्छा था - कार्यात्मक, तेज़ और एक सर्वर पर फ़िट करें PostgreSQL - ताकि आप उदाहरण के लिए, कहीं किनारे पर सेवा का एक अलग उदाहरण तैनात कर सकें।

इसलिए, हम शार्डिंग, प्रतिकृति और भू-वितरित सिस्टम के मुद्दों पर ध्यान नहीं देंगे, लेकिन डेटाबेस के अंदर सर्किट समाधान पर ध्यान केंद्रित करेंगे।

चरण 1: कुछ व्यावसायिक विशिष्टताएँ

हम अपने संदेश को अमूर्त रूप से डिज़ाइन नहीं करेंगे, बल्कि इसे पर्यावरण में एकीकृत करेंगे कॉर्पोरेट सोशल नेटवर्क. अर्थात्, हमारे लोग "केवल पत्र-व्यवहार" नहीं करते हैं, बल्कि कुछ व्यावसायिक समस्याओं को हल करने के संदर्भ में एक-दूसरे के साथ संवाद करते हैं।

और एक व्यवसाय के कार्य क्या हैं?.. आइए विकास विभाग के प्रमुख वसीली का उदाहरण देखें।

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

आइए फिलहाल "स्पष्ट" जरूरतों की इस सूची पर ध्यान दें।

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

चरण 2: न्यूनतम तर्क सर्किट

अब तक, सब कुछ ईमेल पत्राचार के समान ही काम करता है - एक पारंपरिक व्यावसायिक उपकरण। हां, "एल्गोरिदमिक रूप से" कई व्यावसायिक समस्याएं एक-दूसरे के समान हैं, इसलिए उन्हें हल करने के उपकरण संरचनात्मक रूप से समान होंगे।

आइए इकाई संबंधों के पहले से प्राप्त तार्किक आरेख को ठीक करें। अपने मॉडल को समझने में आसान बनाने के लिए, हम सबसे आदिम डिस्प्ले विकल्प का उपयोग करेंगे ईआर मॉडल यूएमएल या आईडीईएफ नोटेशन की जटिलताओं के बिना:

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

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

चरण 3: तालिका संरचना का रेखाचित्र बनाना

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

हमारे डेटाबेस में ड्राफ्ट टेबल संरचना इस तरह दिखेगी:
टेबल्स: आरयू

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

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

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

टेबल्स: एन

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

किसी प्रारूप का वर्णन करते समय सबसे सरल बात कनेक्शन ग्राफ़ को "अनवाइंडिंग" करना शुरू करना है उन तालिकाओं से जिनका संदर्भ नहीं दिया गया है स्वयं किसी के लिए नहीं।

चरण 4: गैर-स्पष्ट आवश्यकताओं का पता लगाएं

बस, हमने एक डेटाबेस डिज़ाइन किया है जिसमें आप बेहतरीन ढंग से लिख सकते हैं और किसी न किसी तरह पढ़ने के लिए।

आइए स्वयं को हमारी सेवा के उपयोगकर्ता के स्थान पर रखें - हम इसके साथ क्या करना चाहते हैं?

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

हमारी संरचना हमें इन दोनों समस्याओं को "सामान्य तौर पर" हल करने की अनुमति देती है, लेकिन जल्दी से नहीं। समस्या यह है कि पहले कार्य को क्रमबद्ध करने के लिए सूचकांक बनाने में असमर्थ, प्रत्येक प्रतिभागियों के लिए उपयुक्त (और आपको सभी रिकॉर्ड निकालने होंगे), और दूसरे को हल करने के लिए आपको आवश्यकता होगी सभी संदेश निकालें इस विषय पर।

अनपेक्षित उपयोगकर्ता कार्यों को बोल्ड किया जा सकता है उत्पादकता पर क्रॉस.

चरण 5: स्मार्ट डीनॉर्मलाइज़ेशन

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


टेबल्स: आरयू

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

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

टेबल्स: एन

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

यहां हमने सहायक तालिकाएँ बनाते समय उपयोग किए जाने वाले दो विशिष्ट दृष्टिकोण लागू किए हैं:

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

लेख के अगले भाग में हम बात करेंगे विभाजन का कार्यान्वयन हमारे डेटाबेस की संरचना में।

स्रोत: www.habr.com