অদ্ভুত দম্পতি:MongoDB এবং MySQL

ডেটাস্টোর নির্বাচনের সময় আমাদের উপলব্ধ পছন্দ এবং সংমিশ্রণগুলি প্রমাণ করে যে আমরা আর এক-আকার-ফিট-সমস্ত ডেটাস্টোর জগতে নেই।

আজ, আপনার এসকিউএল ডেটাস্টোরগুলিকে (যেমন MySQL, PostgreSQL, Oracle বা SQLServer) আপনার NoSQL ডেটাস্টোরের সাথে (MongoDB, CouchDB, এবং Neo4J অন্যান্যদের মধ্যে) মিশ্রিত করার এবং মিলানোর জন্য বাধ্যতামূলক কারণ রয়েছে। যদিও ওরাকল এখনও রেকর্ডের পছন্দের সিস্টেম হতে পারে এন্টারপ্রাইজ, এটি আর শহরে একমাত্র খেলা নয়।

ডেভেলপাররা তাদের সমস্যা সমাধানের জন্য SQL এবং NoSQL-এর সমন্বয় ব্যবহার করতে শুরু করেছে—কখনও কখনও DBAs বা IT ডিপার্টমেন্টের ইচ্ছার বিরুদ্ধে।

চাকরির জন্য সঠিক টুল নির্বাচন করা

আজকের বিশ্বে ডাটাস্টোরের পাঁচটি বিস্তৃত বিভাগ রয়েছে:কলাম-পরিবার, নথি, গ্রাফ, কী-মান এবং রিলেশনাল। পলিগ্লট অধ্যবসায়ের আক্ষরিক অর্থ হল আপনার ডেটা সঞ্চয় বা ধরে রাখতে অনেকগুলি ভাষা ব্যবহার করা৷ আরও ব্যবহারিক পরিভাষায় এর অর্থ হল আমরা একই অ্যাপ্লিকেশনের মধ্যে থেকে আমাদের ডেটা অ্যাক্সেস করতে সাইফার, JSON, SQL বা অন্যান্য কয়েকটি কোয়েরি ভাষা ব্যবহার করতে পারি৷ এই বিভিন্ন ডেটাস্টোরগুলি ব্যবহার করে এবং তাদের বিভিন্ন ভাষা আরও বিশিষ্ট হয়ে উঠছে কারণ ডেভেলপাররা তাদের অধ্যবসায়ের প্রয়োজনের সমাধানের জন্য লেজারের জন্য আরও ভাল সরঞ্জামের সন্ধান করে৷

Sadalage এবং Fowler NoSQL ডিস্টিল্ডে পলিগ্লট স্থিরতার প্রয়োজনীয়তা এই বলে উল্লেখ করেছেন:

বিভিন্ন ডাটাবেস বিভিন্ন সমস্যা সমাধানের জন্য ডিজাইন করা হয়েছে। সমস্ত প্রয়োজনীয়তার জন্য একটি একক ডাটাবেস ইঞ্জিন ব্যবহার করলে সাধারণত অ-কার্যকর সমাধান হয়; লেনদেনের ডেটা সংরক্ষণ করা, সেশনের তথ্য ক্যাশ করা, গ্রাহকদের গ্রাফ [sic] এবং তাদের বন্ধুরা যে পণ্যগুলি কিনেছে তা মূলত ভিন্ন সমস্যা।

আসুন ডেটা সম্পর্কের কথা চিন্তা করি৷ RDBMS সলিউশনগুলি যে সম্পর্কগুলি বিদ্যমান তা কার্যকর করতে ভাল৷ যদি আমরা সম্পর্কগুলি আবিষ্কার করতে চাই, বা একই বস্তুর অন্তর্গত বিভিন্ন টেবিল থেকে ডেটা খুঁজতে চাই, তাহলে RDBMS-এর ব্যবহার কঠিন হতে শুরু করে৷

ডেটাস্টোর পছন্দ দুটি মানদণ্ডে নেমে আসে:

1. সংরক্ষিত ডেটার গঠন
2. ডাটার সাথে ইন্টারঅ্যাক্ট করতে ব্যবহৃত প্রশ্নগুলি

আমরা যেভাবে ডেটা অনুসন্ধান করি সেই পদ্ধতিতে আমরা এটি গঠনের পদ্ধতি পরিবর্তন করি৷ উপরে স্যাডালেজ এবং ফাউলারের হিসাবে, রিলেশনাল ডেটাস্টোরগুলি সম্পর্কিত সত্তাগুলিকে কার্যকর করার ক্ষেত্রে দক্ষতা অর্জন করে; যাইহোক, আমাদের সেই সত্ত্বাগুলির মধ্যে অন্যান্য সম্পর্ক আবিষ্কার করার সাথে সাথেই তারা পথে চলে যায়।

নীচে, আমি MongoDB-এর সাথে CraigsList ডেটা আর্কাইভালের একটি ব্যবহারের ক্ষেত্রে আলোচনা করেছি এবং তারা কীভাবে এটি সম্পন্ন করতে পারে সে সম্পর্কে অনুমান করছি৷

খেলোয়াড়রা:MongoDB, MySQL এবং CraigsList

MongoDB

MongoDB MySQL-এর একটি পছন্দের NoSQL বিকল্প হয়ে উঠেছে। এর অনেক সুবিধার মধ্যে রয়েছে স্কেলেবিলিটি, অটো-শার্ডিং এবং আজকের জনপ্রিয় প্রোগ্রামিং ভাষার জন্য নেটিভ বাইন্ডিংয়ের উপলব্ধতা। MongoDB এবং রিলেশনাল ডেটাস্টোরের মধ্যে মূল পার্থক্য হল MongoDB যেভাবে ডেটা নিয়ে চিন্তা করে এবং সংরক্ষণ করে। সম্পর্ক প্রয়োগ করার জন্য বিদেশী কী সীমাবদ্ধতার সাথে টেবিলের একটি সংগ্রহ ব্যবহার করে, MongoDB-তে ডেটা নথির সংগ্রহ হিসাবে উপস্থাপন করা হয়।

নথিগুলি রিলেশনাল ডেটা স্ট্রাকচারের সারি বা টুপলগুলির সাথে সাদৃশ্যপূর্ণ (অভিন্ন নয়)৷ একটি নথির ডেটাস্টোরের শ্রেণীকরণ এবং নামকরণ সরাসরি সংগ্রহে গোষ্ঠীবদ্ধ JSON নথি হিসাবে সংরক্ষিত ডেটা থেকে আসে৷ এই নথিগুলির গভীরতা সীমাহীন এবং সম্পূর্ণরূপে পরিদর্শনযোগ্য প্রশ্ন বা সূচী। সাধারণত মঙ্গোডিবি-র জন্য ডেটার একটি ভাল উপস্থাপনা করা যায় এমন ডেটা ডিনরমালাইজ করে যা একটি রিলেশনাল ডাটাবেসের জন্য উপযুক্ত হবে। অবশ্যই, আপনি যে বিশেষ প্রশ্নগুলি করতে চান তা এই প্রক্রিয়াটিকে গাইড করবে।

MongoDB এর সূক্ষ্মতা সম্পর্কে আরও তথ্য MongoDB এর ওয়েবসাইটে পাওয়া যাবে।

MySQL

ক্লাসিক যেটিকে সবাই জানে এবং ভালোবাসে, MySQL সময়কালের শুরু থেকেই (কম্পিউটিং টাইমস্কেলে) এবং সহজেই সবচেয়ে ব্যাপকভাবে ব্যবহৃত DBMS। এটি যে কার্যকারিতা প্রদান করে তা অ্যাপ্লিকেশনগুলিকে প্রায় এক দশক ধরে ডেটা মডেল করতে এবং একটি সিস্টেম হিসাবে কাজ করার অনুমতি দিয়েছে অনেক ব্যবসায়িক উদ্দেশ্যের চারপাশে রেকর্ড। আজকাল যখন লোকেরা একটি রিলেশনাল ডাটাবেসের কথা ভাবে তখন তারা সম্ভবত MySQL এর কথা ভাবে।

MySQL আমাদেরকে ক্লাসিক রিলেশনাল ডেটা মডেলের বাস্তবায়ন প্রদান করে। টাইপ থিওরি এবং সেট থিওরি ব্যবহার করে, এটি 1970 এর দশকে E.F. Codd দ্বারা বিকশিত হয়েছিল। প্রোগ্রামেটিকভাবে স্বাভাবিকীকরণ, পরিকল্পিত বা আত্মবিশ্লেষণ করতে সক্ষম হওয়ায় রিলেশনাল ডেটা সিস্টেমগুলিকে অত্যন্ত জনপ্রিয় করে তোলে। , এই ডেটাস্টোরগুলিকে পছন্দ করা হচ্ছে কারণ তারা সাধারণ পদ্ধতিতে ডেটা মডেলিংয়ের সমস্যা সমাধান করে৷

CraigsList

একটি সুপরিচিত অনলাইন ব্যবসা যা একটি MongoDB এবং MySQL ডেটাস্টোর উভয়কেই নিয়োগ করে তা হল CraigsList৷ তাদের দুটি ডেটাস্টোরের পাশাপাশি গ্রহণের বিষয়টি একটি MongoDB কেস স্টাডিতে বর্ণিত হয়েছে, কিন্তু নীচে একটি থাম্বনেইল স্কেচ রয়েছে৷

নিয়ন্ত্রক প্রয়োজনীয়তার কারণে, ক্রেগলিস্টকে তার ক্লাসিফাইডের ডিজিটাল রেকর্ড ধরে রাখতে হবে৷ প্রতিদিন এক মিলিয়নেরও বেশি নতুন ক্লাসিফায়েডের সাথে, এটি ক্রেগলিস্টের জন্য একটি উল্লেখযোগ্য পরিমাণ ডেটা বজায় রাখার জন্য৷ এটি ক্লাসিফাইড সম্পর্কে সমস্ত সক্রিয় তথ্য রাখতে একটি MySQL ডেটাস্টোর ব্যবহার করে, যখন মঙ্গোডিবি সংরক্ষণাগারভুক্ত ডেটা সংরক্ষণ করতে ব্যবহৃত হয়-সম্ভবত 30 দিনের বেশি কিছু। স্বাভাবিক ব্যবসায়িক পরিবর্তনের অংশ হিসাবে, সংরক্ষিত ডেটার স্কিমায় পরিবর্তন হয়। সংরক্ষণাগারভুক্ত ডেটার জন্য মঙ্গোডিবি ব্যবহার করে, CraigsList কার্যকরভাবে তার ডেটা বিভাগ করতে এবং সমস্যাগুলি প্রশমিত করতে সক্ষম হয়েছিল স্কিমা মাইগ্রেশন।

একটি চিন্তা পরীক্ষা হিসাবে, আমি একটি CraigsList-esque অ্যাপ্লিকেশনে MongoDB এবং MySQL পাশাপাশি ব্যবহার করার জন্য একটি সম্ভাব্য বাস্তবায়ন সম্পর্কে অনুমান করতে চাই৷ এটি খুব অসম্ভাব্য যে CraigsList আসলে তাদের ডেটা স্টোরেজ কীভাবে করছে, তবে এটি একটি আকর্ষণীয় একটি পরিচিত, অত্যন্ত লেনদেনমূলক, ওয়েবসাইটের জন্য একাধিক ডেটাস্টোর একসাথে কাজ করতে পারে তা দেখার উপায়৷

এটি কিভাবে করা হয়?

বিকাশকারী এবং প্রকৌশলীরা যখন একটি বিশাল SQL ডাটাবেসে একটি স্কিমা আপডেট সম্পাদন করেন তখন অনিবার্যভাবে সমস্যায় পড়েন৷ স্কিমা আপডেট প্রয়োগ করার পরে "ফিক্স আপ" করার জন্য কম ডেটা থাকার মাধ্যমে এটি এড়ানো যেতে পারে৷ এই স্থানান্তর বা স্কিমা আপডেটগুলির ব্যথা সাধারণত বৃদ্ধি পায়৷ আনুপাতিকভাবে ডেটার পরিমাণ।

আমাদের উদাহরণে, কল্পনা করা যাক CraigsList-এর জন্য একটি আইটেম বিক্রি করার জন্য ব্যবহারকারীদের কাছ থেকে একটি নতুন তথ্যের প্রয়োজন৷ যেহেতু স্কিমাটি অবশ্যই আপডেট করা উচিত, CraigsList আপডেটের ব্যথা কমাতে প্রভাবিত ডেটার আকার কমাতে চায়৷

এই কয়েকটি সংরক্ষণাগার এবং স্থানান্তর চক্রের পরে, CraigsList ভিন্নধর্মী ডেটার একটি বিশাল সংগ্রহ তৈরি করবে যার জন্য একটি স্কিমালেস ডেটাস্টোর প্রয়োজন যদি এটি একটি একক অবস্থানে থাকে৷ MongoDB এই বিলটিকে খুব ভালভাবে ফিট করে৷

ক্লাসিফাইডের জন্য একটি উদাহরণ স্কিমা দেখতে নিচের মত কিছু হবে (ক্রেইগলিস্ট-ক্লোন থেকে নির্লজ্জভাবে পুনরায় প্রয়োগ করা হয়েছে):

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-এর সংমিশ্রণ ব্যবহার করতে পারি। এবং পাইমঙ্গো:

প্রথমত, আমাদের 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-এ ঢোকাতে আমাদের প্রয়োজন হবে।

পরবর্তী নমুনা দেখায় কিভাবে সংযোগ করতে হয় এবং পাইমঙ্গোতে একটি অভিধান সন্নিবেশ করতে হয়:

import pymongo

client = pymongo.MongoClient('mongodb://192.0.2.2')

db = client['craigslist']
collection = db['classifieds']
collection.insert({'_id': 1})

এখন একমাত্র সমস্যা হল কিভাবে SQLAlchemy এবং MongoDB তাদের আইডি নির্দিষ্ট করে।SQLAlchemy id-এর একটি কী ব্যবহার করে যেখানে MongoDB _id-এর একটি কী ব্যবহার করে তাই, আমাদের সেই কীটি অনুবাদ করতে হবে (বেশ একটি সাধারণ প্রক্রিয়া):classified['_id'] = classified.pop('id') .

উপসংহার

যদিও SQL এবং NoSQL ডেটাস্টোরগুলিকে প্রায়শই একটি সমস্ত বা কিছুই প্রস্তাবনা হিসাবে চিত্রিত করা হয়, এটি দেখা যাচ্ছে যে জটিল সমস্যাগুলি সমাধান করতে এগুলি একসাথে ব্যবহার করা যেতে পারে৷ এই উদাহরণের মাধ্যমে, আমরা দেখেছি যে একটি সিস্টেমের জন্য খুব কম কোডের প্রয়োজন হয় যা একটি MongoDB এবং উভয়ই ব্যবহার করে MySQL ডেটাস্টোর। আসলে, এটি ডেমনাইজড না হয়ে ক্রোন দ্বারা চালিত হতে পারে।

একাধিক ডেটাস্টোর ব্যবহার করার অসুবিধা অগত্যা অনুবাদ কোড বা মাইগ্রেশন কোডের বিকাশের মধ্যে পড়ে না, তবে অতিরিক্ত সিস্টেমগুলির প্রশাসন অসুবিধা বাড়ায়৷ একটি ডেটাস্টোর বজায় রাখার জন্য ইতিমধ্যেই দক্ষতার প্রয়োজন (ডিবিএ বা ডেটাস্টোর জ্ঞান সহ অ্যাডমিন) এবং এটি আপনি আরও ডেটাস্টোর চালু করার সাথে সাথে দক্ষতার চাহিদা বৃদ্ধি পায়।

একাধিক ডেটাস্টোর চালানো মূল্যবান কিনা তা ব্যবসাকে অবশ্যই সিদ্ধান্ত নিতে হবে৷ এমন প্রযুক্তি রয়েছে যা এই চ্যালেঞ্জগুলি কমাতে সাহায্য করবে৷

শেফ এবং সল্টের মতো অটোমেশন প্রযুক্তির পাশাপাশি, অবজেক্ট রকেট, র‌্যাকস্পেস দ্বারা পরিচালিত মঙ্গোডিবি পরিষেবার মতো পরিষেবা বিক্রেতাদের সুবিধা গ্রহণ করে এই চ্যালেঞ্জটি প্রশমিত করা যেতে পারে। জটিলতা যতই বর্ধিত হোক না কেন, একাধিক ডেটাস্টোর ব্যবহার করলে সমস্যাটি উপকৃত হবে। , অনুমানগুলি আপনাকে সেই সমাধানগুলি অন্বেষণ করা থেকে বিরত করতে দেবে না৷