🤸🏼 👩🏼‍💼 🧗🏼 मैसेंजर डेटाबेस (भाग 1): हम बेस फ्रेम डिजाइन करते हैं 🥥 💈 👨‍🚀

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

भाग 1: आधार फ्रेम को डिजाइन करना
भाग 2: "लाभ" का विभाजन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

तालिका और फ़ील्ड नामों के बारे में

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

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

हमारे डेटाबेस में तालिकाओं की खुरदरी संरचना इस तरह दिखाई देगी:

टेबल्स: आरयू

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

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

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

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

मैसेंजर डेटाबेस (भाग 1): हम बेस फ्रेम डिजाइन करते हैं

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

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

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

चरण 4: अनौपचारिक आवश्यकताओं का पता लगाना

चरण 5: उचित अपसरण

More articles: