MongoDB और MySQL का संयोजन: एक आधुनिक डेटा रणनीति

डेटास्टोर चयन के दौरान हमारे पास उपलब्ध विकल्प और संयोजन साबित करते हैं कि हम अब वन-साइज़-फिट्स-ऑल डेटास्टोर दुनिया में नहीं हैं।

आज, अपने SQL डेटास्टोर (जैसे MySQL, PostgreSQL, Oracle या SQL Server) को अपने NoSQL डेटास्टोर (MongoDB, CouchDB, और Neo4J आदि) के साथ मिश्रित और मिलान करने के लिए ठोस कारण हैं। जबकि Oracle अभी भी उद्यमों के लिए पसंदीदा सिस्टम ऑफ रिकॉर्ड हो सकता है, यह अब शहर में एकमात्र खेल नहीं है।

डेवलपर्स अपनी समस्याओं को हल करने के लिए SQL और NoSQL के संयोजन का उपयोग करना शुरू कर रहे हैं - कभी-कभी DBAs या IT विभागों की इच्छा के विरुद्ध।

काम के लिए सही उपकरण चुनना

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

सडालेज और फाउलर NoSQL डिस्टिल्ड में पॉलीग्लॉट पर्सिस्टेंस की आवश्यकता को नोट करते हुए कहते हैं:

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

आइए डेटा संबंधों के बारे में सोचें। RDBMS समाधान संबंधों को लागू करने में अच्छे हैं। यदि हम संबंधों की खोज करना चाहते हैं, या अलग-अलग टेबल से उस डेटा को ढूंढना चाहते हैं जो एक ही ऑब्जेक्ट से संबंधित है, तो RDBMS का उपयोग करना मुश्किल होने लगता है।

डेटास्टोर चयन दो मानदंडों पर निर्भर करता है:

संग्रहीत किए जा रहे डेटा की संरचना
डेटा के साथ इंटरैक्ट करने के लिए उपयोग की जाने वाली क्वेरी

जिस तरह से हम डेटा क्वेरी करते हैं वह बदलता है कि हम इसे कैसे संरचित करते हैं। जैसा कि ऊपर सडालेज और फाउलर कहते हैं, रिलेशनल डेटास्टोर संबंधित संस्थाओं को लागू करने में उत्कृष्ट हैं; हालांकि, वे रास्ते में आ जाते हैं जैसे ही हमें उन संस्थाओं के बीच अन्य संबंधों की खोज करने की आवश्यकता होती है।

नीचे, मैं एक उपयोग केस, MongoDB के साथ CraigsList डेटा आर्काइवल, और इस बारे में अनुमान लगाता हूं कि उन्होंने इसे कैसे पूरा किया होगा।

खिलाड़ी: MongoDB, MySQL और CraigsList

MongoDB

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

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

MongoDB की बारीकियों के बारे में अधिक जानकारी MongoDB की वेबसाइट पर पाई जा सकती है।

MySQL

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

MySQL हमें क्लासिक रिलेशनल डेटा मॉडल का कार्यान्वयन प्रदान करता है। टाइप थ्योरी और सेट थ्योरी का उपयोग करके, इसे 1970 के दशक में E.F. Codd द्वारा विकसित किया गया था। प्रोग्रामेटिक रूप से सामान्यीकृत, योजनाबद्ध या आत्मनिरीक्षण करने में सक्षम होने के कारण, रिलेशनल डेटा सिस्टम बेहद लोकप्रिय हैं। वास्तव में, ये डेटास्टोर अभी भी पसंदीदा हैं क्योंकि वे डेटा को सामान्य तरीके से मॉडल करने की समस्या को हल करते हैं।

CraigsList

एक प्रसिद्ध ऑनलाइन व्यवसाय जो MongoDB और MySQL दोनों डेटास्टोर को नियोजित करता है, वह है CraigsList। MongoDB केस स्टडी में उनके दो डेटास्टोर को साथ-साथ अपनाने की रूपरेखा दी गई है, लेकिन नीचे एक संक्षिप्त विवरण है।

नियामक आवश्यकताओं के कारण, Craigslist को अपने क्लासीफाइड के डिजिटल रिकॉर्ड बनाए रखने होंगे। प्रति दिन दस लाख से अधिक नए क्लासीफाइड के साथ, यह CraigsList के लिए बनाए रखने के लिए डेटा की एक महत्वपूर्ण मात्रा है। यह सक्रिय क्लासीफाइड के बारे में सभी सक्रिय जानकारी को रखने के लिए MySQL डेटास्टोर का उपयोग करता है, जबकि MongoDB का उपयोग आर्काइव्ड डेटा को संग्रहीत करने के लिए किया जाता है - संभवतः 30 दिनों से अधिक कुछ भी। सामान्य व्यावसायिक परिवर्तनों के हिस्से के रूप में, संग्रहीत डेटा का डेटा स्कीमा बदलता है। आर्काइव्ड डेटा के लिए MongoDB का उपयोग करके, CraigsList अपने डेटा को प्रभावी ढंग से विभाजित करने और स्कीमा माइग्रेशन के कारण होने वाली समस्याओं को कम करने में सक्षम था।

एक विचार प्रयोग के रूप में, मैं MongoDB और MySQL को CraigsList-जैसे एप्लिकेशन में साथ-साथ उपयोग करने के लिए एक संभावित कार्यान्वयन के बारे में अनुमान लगाना चाहता हूं। यह अत्यधिक संभावना नहीं है कि यह वास्तव में CraigsList अपने डेटा स्टोरेज को कैसे कर रहा है, लेकिन यह एक दिलचस्प तरीका है कि कैसे कई डेटास्टोर एक परिचित, अत्यधिक लेनदेन वाली वेबसाइट के लिए एक साथ काम कर सकते हैं।

यह कैसे किया जाता है?

डेवलपर्स और इंजीनियर अनिवार्य रूप से समस्याओं में पड़ जाते हैं जब वे एक भारी SQL डेटाबेस पर स्कीमा अपडेट करते हैं। इसे केवल अपडेट के बाद "ठीक" करने के लिए कम डेटा रखकर टाला जा सकता है। इन माइग्रेशन या स्कीमा अपडेट का दर्द आमतौर पर डेटा की मात्रा के अनुपात में बढ़ता है।

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

इनमें से कुछ आर्काइवल और माइग्रेशन साइकिल के बाद, CraigsList ने विषम डेटा का एक भारी संग्रह बनाया होगा जिसे एक स्कीमालेस डेटास्टोर की आवश्यकता होगी यदि यह एक ही स्थान पर रहना है। MongoDB इस बिल को बहुत अच्छी तरह से फिट करता है।

क्लासीफाइड के लिए एक उदाहरण स्कीमा निम्नलिखित जैसा दिखेगा (craigslist-clone से बेशर्मी से पुनः कार्यान्वित):

CREATE TABLE `classifieds` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `title` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
 `description` text COLLATE utf8_unicode_ci,
 `location` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
 `adtype` varchar(1) COLLATE utf8_unicode_ci DEFAULT 'O',
 `email` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
 `phone` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
 `activation_code` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
 `status` tinyint(4) DEFAULT '0',
 `category_id` int(11) DEFAULT NULL,
 `subcategory_id` int(11) DEFAULT NULL,
 `city_id` int(11) DEFAULT NULL,
 `permalink` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `image_file_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `image_content_type` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `image_file_size` int(11) DEFAULT NULL,
 `created_at` datetime DEFAULT NULL,
 `updated_at` datetime DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

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

आइए दिखावा करें कि Craigslist की क्लासीफाइड नीति में कहा गया है कि एक क्लासीफाइड वेबसाइट पर दो सप्ताह तक उपलब्ध रहेगा। इस समय के बाद, वे चाहते हैं कि क्लासीफाइड अभी भी उपलब्ध हो लेकिन जरूरी नहीं कि सक्रिय हो (MySQL में)। इसे पूरा करने के लिए हम SQLAlchemy और pymongo के संयोजन का उपयोग कर सकते हैं:

सबसे पहले, हमें अपने MySQL इंस्टेंस से डेटा निकालने की आवश्यकता है। हम इसे पूरा करने के लिए SQLAlchemy का उपयोग करेंगे और इसे हमारे स्कीमा का आत्मनिरीक्षण करने देंगे (इस कोड को इस उद्देश्य के लिए कहीं अधिक पुन: प्रयोज्य बना देगा)।

import sqlalchemy.schema
m = sqlalchemy.schema.MetaData("mysql://root:I'm required why?@192.0.2.3/craigslist")
m.reflect()
print m.tables.keys()

यदि आप अपने डेटाबेस से सफलतापूर्वक कनेक्ट हो रहे हैं, तो आप अपने कुंजी (कॉलम नाम) को मानक पायथन फैशन में प्रिंट होते देखेंगे: [u'classifieds', u'cities', u'subcategories', u'categories']। हमें अभी भी इन टेबल से व्यक्तिगत डेटा आइटम निकालने की आवश्यकता है। न केवल हम उन्हें देख सकते हैं, बल्कि SQLAlchemy इसे बहुत आसान बनाने के लिए एक सुंदर इंटरफ़ेस भी प्रदान करता है।

अब हमारे पास आत्मनिरीक्षण से हमारी टेबल परिभाषाएं हैं। ऑब्जेक्ट मैप बनाने या उन टेबल को क्वेरी करने का समय आ गया है जिनमें वे डेटा आइटम हैं। नीचे दी गई क्वेरी हमारे क्लासीफाइड को डेटास्टोर से निकालेगी (अन्य टेबल पाठक के लिए एक अभ्यास के रूप में छोड़ दिए गए हैं)।

import sqlalchemy.sql
connection = m.bind.connect()
classifieds = m.tables['classifieds']
query = classifieds.select()
result = connection.execute(query)
for row in result:
    print dict(row.items())

यह स्निपेट हमारे MySQL कनेक्शन का उपयोग सभी क्लासीफाइड के लिए क्वेरी करने के लिए करता है। इसे आसानी से सभी टेबल को संभालने के लिए विस्तारित किया जा सकता है, डेटा को डिनॉर्मलाइज़ करके MongoDB की दस्तावेज़ शैली में बेहतर फिट करने के लिए। लेकिन इस प्रदर्शन के उद्देश्य के लिए, हम केवल क्लासीफाइड टेबल पर ध्यान केंद्रित करेंगे। इस बिंदु पर, हमने क्लासीफाइड टेबल में प्रत्येक व्यक्तिगत आइटम को एक डिक्शनरी में बदल दिया है, जो कि ठीक वही है जो हमें pymongo के माध्यम से MongoDB में डालने के लिए चाहिए।

अगला नमूना दिखाता है कि pymongo से कैसे कनेक्ट करें और एक डिक्शनरी डालें:

import pymongo
client = pymongo.MongoClient('mongodb://192.0.2.2')
db = client['craigslist']
collection = db['classifieds']
collection.insert({'_id': 1})

एकमात्र समस्या अब यह है कि SQLAlchemy और MongoDB अपनी IDs कैसे निर्दिष्ट करते हैं। SQLAlchemy id की कुंजी का उपयोग करता है जबकि MongoDB _id की कुंजी का उपयोग करता है। इस प्रकार, हमें उस कुंजी का अनुवाद करने की आवश्यकता है (काफी सरल प्रक्रिया): classified['_id'] = classified.pop('id')।

निष्कर्ष

जबकि SQL और NoSQL डेटास्टोर को अक्सर एक ऑल-ऑर-नथिंग प्रस्ताव के रूप में चित्रित किया जाता है, यह पता चलता है कि उनका उपयोग जटिल समस्याओं को हल करने के लिए एक साथ किया जा सकता है। इस उदाहरण के माध्यम से, हमने देखा कि एक सिस्टम के लिए बहुत कम कोड की आवश्यकता होती है जो MongoDB और MySQL दोनों डेटास्टोर का उपयोग करता है। वास्तव में, इसे डिमोनाइज़्ड होने के बजाय क्रॉन द्वारा संचालित किया जा सकता है।

कई डेटास्टोर का उपयोग करने में कठिनाई आवश्यक रूप से अनुवाद कोड या माइग्रेशन कोड के विकास में नहीं है, बल्कि अतिरिक्त प्रणालियों का प्रशासन कठिनाई को बढ़ाता है। एक डेटास्टोर को बनाए रखने के लिए पहले से ही विशेषज्ञता की आवश्यकता होती है (DBAs या डेटास्टोर ज्ञान वाले एडमिन), और जैसे-जैसे आप अधिक डेटास्टोर पेश करते हैं, विशेषज्ञता की यह मांग बढ़ती जाती है।

व्यवसाय को यह तय करना होगा कि कई डेटास्टोर चलाना मूल्यवान है या नहीं। ऐसी प्रौद्योगिकियां हैं जो इन चुनौतियों को कम करने में मदद करेंगी।

Chef और Salt जैसी ऑटोमेशन तकनीकों के अलावा, इस चुनौती को ObjectRocket, Rackspace द्वारा प्रबंधित MongoDB सेवा जैसे सेवा विक्रेताओं का लाभ उठाकर कम किया जा सकता है। बढ़ी हुई जटिलता के बावजूद, यदि कोई समस्या कई डेटास्टोर के उपयोग से लाभान्वित होगी, तो धारणाओं को उन समाधानों का पता लगाने से न रोकें।