एसक्यूएल क्यों?

जब हमने अपने अंग्रेजी भाषा के तकनीकी ब्लॉग पर अपनी सेवा की वास्तुकला का सामान्य विवरण दिया, तो उन पाठकों के लिए, जिनके पास अन्य महान सेवाओं के साथ काम करने का अनुभव है, सबसे आम सवाल थे:

1. आपका संरचित डेटा NoSQL समाधानों का उपयोग करने के बजाय SQL के साथ डेटाबेस में संग्रहीत क्यों है?
2. क्लाउड होस्टिंग सेवाओं का उपयोग करने के बजाय आप अपने स्वयं के हार्डवेयर का उपयोग क्यों कर रहे हैं?

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

जब सही तरीके से उपयोग किया जाता है, तो सहयोगी सरणियों (कुंजी-मूल्य) में डेटा संग्रहीत करने के लिए एक आधुनिक तंत्र SQL- सर्वर के एकल उदाहरण की तुलना में महत्वपूर्ण प्रदर्शन और मापनीयता प्रदान कर सकता है। हालाँकि, कई कारण हैं कि हमने आपके सभी खाते की जानकारी MySQL में पोस्ट करने का निर्णय लिया है।

एसक्यूएल लाभ

आरंभ करने के लिए, Transactional डेटाबेस के ACID गुण , जैसे कि MySQL के साथ InnoDB, हमारे आवेदन और तुल्यकालन मॉडल के लिए महत्वपूर्ण हैं।

यहां सर्वर डेटाबेस में नोटपैड और नोट्स को संग्रहीत करने के लिए डेटाबेस तालिकाओं का एक छोटा टुकड़ा है:

CREATE TABLE notebooks (
id int UNSIGNED NOT NULL PRIMARY KEY,
guid binary(16) NOT NULL,
user_id int UNSIGNED NOT NULL,
name varchar(100) COLLATE utf8_bin NOT NULL,
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE notes (
id int UNSIGNED NOT NULL PRIMARY KEY,
guid binary(16) NOT NULL,
user_id int UNSIGNED NOT NULL,
notebook_id int UNSIGNED NOT NULL,
title varchar(255) NOT NULL,
...
FOREIGN KEY (notebook_id) REFERENCES notebooks(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

यदि आप अपने एवरनोट विंडोज क्लाइंट पर "रेसिपी" नामक एक नोटबुक बनाते हैं, और फिर इस नोटबुक में पसंदीदा पुलाव रेसिपी को तुरंत कॉपी करते हैं, तो आपका क्लाइंट अगले सिंक्रोनाइज़ेशन के दौरान निम्नलिखित कार्य करेगा:

• NoteStore.createNotebook () सर्वर पर एक नोटबुक के निर्माण का अनुरोध करने के लिए कहता है। जो उसे बनाए गए नोटबुक का पहचानकर्ता (GUID) लौटाएगा।
• नोटपैडore.reateNote () नोटपैड GUID के साथ सर्वर पर पहले से ही सेट के निर्माण के लिए अनुरोध करने के लिए कहता है ।

इनमें से प्रत्येक उच्च-स्तरीय एपीआई अनुरोध एक एकल SQL लेनदेन के माध्यम से किया जाता है, जो यह सुनिश्चित करता है कि ग्राहक किसी भी सर्वर प्रतिक्रिया पर पूरी तरह से भरोसा कर सकता है।

एसीआईडी-अनुपालन डेटाबेस इस तरह के लाभ प्रदान करता है:

Atomicity। यदि एपीआई कॉल सफल होता है, तो 100% परिवर्तन किए जाएंगे, और अगर एपीआई कॉल विफल हो जाती है, तो उनमें से कोई भी नहीं बनाया जाएगा। इसका मतलब है कि अगर हम आपके नोट में चौथी छवि नहीं डाल सकते हैं, तो आपके खाते में एक आधा-गठन नोट नहीं होगा, जो कि, इसके अलावा, डेटा डाउनलोड करने के लिए शेष मासिक राशि से गणना की जाएगी।

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

वारंटी। जब सर्वर रिपोर्ट करता है कि एक नोटबुक बनाई गई है, तो ग्राहक यह विचार कर सकता है कि उसके पास पहले से ही एक नोटबुक है और इसे आगे के संचालन में ध्यान में रखें (जैसे कि एक नोट बनाने के लिए कॉल करना)। इस परिवर्तन की गारंटी है, और ग्राहक को पता है कि यह लगातार किसी भी समय सेवा की स्थिति को दर्शाता है।

गारंटी सिद्धांत हमारे सिंक्रनाइज़ेशन प्रोटोकॉल के लिए सबसे महत्वपूर्ण भूमिका निभाता है। यदि क्लाइंट एप्लिकेशन को यह सुनिश्चित नहीं था कि सेवा द्वारा किए गए परिवर्तन होने की गारंटी है, तो सिंक्रनाइज़ेशन प्रोटोकॉल बहुत अधिक जटिल और कम प्रभावी हो जाएगा। प्रत्येक सिंक्रनाइज़ किए गए क्लाइंट को लगातार जांचना होगा कि क्या प्रत्येक सर्वर ऑब्जेक्ट वर्तमान स्थिति से मेल खाता है। 20 हज़ार के नोट, 40 हज़ार संसाधन फ़ाइलों और 10 हज़ार टैग वाले खाते के लिए निरपेक्ष स्थिरता नियंत्रण का ऐसा क्रियान्वयन बेहद महंगा होगा यदि परिवर्तन की कोई गारंटी नहीं है।

बहुत सारे डेटा के बारे में कैसे?

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

सौभाग्य से, एवरनोट को अभी इस समस्या को हल करने की आवश्यकता नहीं है। हालाँकि हमारे पास पहले से ही एक बिलियन नोट्स और लगभग 2 बिलियन रिसोर्स फाइल्स हमारे सर्वरों पर हैं, लेकिन यह वास्तव में एक बड़ा डेटा सेट नहीं है - यह 20 मिलियन अलग-अलग सेट्स हैं, प्रति उपयोगकर्ता एक है।

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

शायद भविष्य में ...

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

हालांकि, हम शार्क आधारित MySQL उपयोगकर्ता डेटा रिपॉजिटरी से काफी संतुष्ट हैं, हालांकि कुछ लोगों के अनुसार यह इतना अच्छा नहीं है।