मेसेंजर डेटाबेस (भाग 1): बेस फ्रेमवर्क डिझाइन करणे

सुरवातीपासून मेसेंजर डेटाबेस डिझाइन करण्याचे उदाहरण वापरून तुम्ही विशिष्ट डेटा स्ट्रक्चर्समध्ये व्यवसाय आवश्यकतांचे भाषांतर कसे करू शकता.

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

आमचा आधार इतका मोठा आणि वितरित होणार नाही, VKontakte सारखे किंवा Badoo, परंतु “म्हणजे ते होते”, परंतु ते चांगले होते - कार्यशील, वेगवान आणि एका सर्व्हरवर फिट PostgreSQL - जेणेकरून तुम्ही सेवेचे वेगळे उदाहरण बाजूला कुठेतरी तैनात करू शकता, उदाहरणार्थ.

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

पायरी 1: काही व्यवसाय तपशील

आम्ही आमची मेसेजिंग अमूर्तपणे डिझाइन करणार नाही, परंतु ते वातावरणात समाकलित करू कॉर्पोरेट सामाजिक नेटवर्क. म्हणजेच, आमचे लोक "फक्त पत्रव्यवहार" करत नाहीत, परंतु काही व्यावसायिक समस्या सोडवण्याच्या संदर्भात एकमेकांशी संवाद साधतात.

आणि व्यवसायाची कार्ये कोणती आहेत?.. विकास विभागाचे प्रमुख वसिलीचे उदाहरण पाहू या.

• "निकोलाई, या कार्यासाठी आज आपल्याला पॅचची आवश्यकता आहे!"
  याचा अर्थ असा की काहींच्या संदर्भात पत्रव्यवहार केला जाऊ शकतो दस्तऐवज.
• "कोल्या, तू आज संध्याकाळी डोटाला जात आहेस?"
  म्हणजेच, इंटरलोक्यूटरची एक जोडी देखील एकाच वेळी संवाद साधू शकते विविध विषयांवर.
• "पीटर, निकोले, नवीन सर्व्हरसाठी किंमत सूचीसाठी संलग्नक पहा."
  तर, एक संदेश असू शकतो अनेक प्राप्तकर्ते. या प्रकरणात, संदेश असू शकतो जोडलेल्या फाइल्स.
• "सेम्यॉन, तू पण बघ."
  आणि विद्यमान पत्रव्यवहारात प्रवेश करण्याची संधी असावी नवीन सदस्याला आमंत्रित करा.

"स्पष्ट" गरजांच्या या यादीत आपण सध्या राहू या.

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

पायरी 2: किमान लॉजिक सर्किट

आतापर्यंत, सर्वकाही ईमेल पत्रव्यवहारासारखेच कार्य करते - एक पारंपारिक व्यवसाय साधन. होय, "अल्गोरिदमनुसार" अनेक व्यवसाय समस्या एकमेकांसारख्याच आहेत, म्हणून त्यांचे निराकरण करण्याची साधने संरचनात्मकदृष्ट्या समान असतील.

अस्तित्व संबंधांचे आधीच प्राप्त केलेले तार्किक आकृतीचे निराकरण करूया. आमचे मॉडेल समजून घेणे सोपे करण्यासाठी, आम्ही सर्वात प्राचीन डिस्प्ले पर्याय वापरू ER मॉडेल UML किंवा IDEF नोटेशन्सच्या गुंतागुंतीशिवाय:

आमच्या उदाहरणात, फाईलची व्यक्ती, दस्तऐवज आणि बायनरी "बॉडी" ही "बाह्य" संस्था आहेत जी आमच्या सेवेशिवाय स्वतंत्रपणे अस्तित्वात आहेत. त्यामुळे, आम्ही त्यांना भविष्यात UUID द्वारे "कुठेतरी" दुवे म्हणून समजू.

काढा आकृत्या शक्य तितक्या सोप्या - तुम्ही दाखवाल ते बहुतेक लोक UML/IDEF वाचण्यात तज्ञ नाहीत. पण जरूर काढा.

पायरी 3: टेबलची रचना रेखाटणे

टेबल आणि फील्ड नावांबद्दलफील्ड आणि टेबल्सची "रशियन" नावे वेगळ्या पद्धतीने हाताळली जाऊ शकतात, परंतु ही चवची बाब आहे. कारण द टेन्सर येथे तेथे कोणतेही परदेशी विकसक नाहीत आणि PostgreSQL आम्हाला चित्रलिपीमध्ये देखील नावे देण्याची परवानगी देते, जर ते कोट मध्ये बंद, मग आम्ही वस्तूंना अस्पष्टपणे आणि स्पष्टपणे नाव देण्यास प्राधान्य देतो जेणेकरून कोणतीही विसंगती नाही.
बरेच लोक आम्हाला एकाच वेळी संदेश लिहित असल्याने, त्यांच्यापैकी काही जण हे करू शकतात ऑफलाइन, तर सर्वात सोपा पर्याय आहे UUID चा अभिज्ञापक म्हणून वापर करा केवळ बाह्य घटकांसाठीच नाही तर आमच्या सेवेतील सर्व वस्तूंसाठी देखील. शिवाय, ते क्लायंटच्या बाजूने देखील व्युत्पन्न केले जाऊ शकतात - जेव्हा डेटाबेस तात्पुरते अनुपलब्ध असेल तेव्हा संदेश पाठविण्यास हे आम्हाला मदत करेल आणि टक्कर होण्याची शक्यता अत्यंत कमी आहे.

आमच्या डेटाबेसमधील मसुदा सारणी रचना अशी दिसेल:
टेबल्स: RU

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
);

टेबल्स: EN

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: स्मार्ट डिनोर्मलायझेशन

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


टेबल्स: RU

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

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

टेबल्स: EN

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