2.1 NoSQL শব্দটির উত্থান
সম্প্রতি, "NoSQL" শব্দটি খুব ফ্যাশনেবল এবং জনপ্রিয় হয়ে উঠেছে, এই চিহ্নের অধীনে সমস্ত ধরণের সফ্টওয়্যার সমাধান সক্রিয়ভাবে বিকশিত এবং প্রচার করা হচ্ছে। NoSQL বিপুল পরিমাণ ডেটা, লিনিয়ার স্কেলেবিলিটি, ক্লাস্টার, ফল্ট টলারেন্স, অ-রিলেশনালিটির সমার্থক হয়ে উঠেছে। যাইহোক, খুব কম লোকই NoSQL স্টোরেজ কী, শব্দটি কীভাবে উপস্থিত হয়েছে এবং তাদের কী সাধারণ বৈশিষ্ট্য রয়েছে সে সম্পর্কে স্পষ্ট ধারণা রয়েছে। আসুন এই শূন্যতা পূরণ করার চেষ্টা করি।
শব্দটি সম্পর্কে সবচেয়ে মজার বিষয় হল যে এটি 90 এর দশকের শেষের দিকে প্রথম ব্যবহৃত হওয়া সত্ত্বেও, এটি শুধুমাত্র 2009-এর মাঝামাঝি সময়ে যে আকারে এটি ব্যবহার করা হয় তার প্রকৃত অর্থ অর্জন করেছিল। প্রাথমিকভাবে, এটি একটি খোলার নাম ছিল। কার্লো স্ট্রোজি দ্বারা তৈরি সোর্স ডাটাবেস, যা ASCII ফাইল হিসাবে সমস্ত ডেটা সংরক্ষণ করে এবং ডেটা অ্যাক্সেস করতে SQL এর পরিবর্তে শেল স্ক্রিপ্ট ব্যবহার করে। এটির বর্তমান আকারে "NoSQL" এর সাথে কোনও সম্পর্ক ছিল না।
জুন 2009 সালে জোহান অস্কারসন আইটি স্টোরেজ এবং প্রক্রিয়াকরণ বাজারে নতুন প্রবণতা নিয়ে আলোচনা করার জন্য সান ফ্রান্সিসকোতে একটি বৈঠকের আয়োজন করেছিলেন। মিটিংয়ের প্রধান অনুপ্রেরণা ছিল বিগটেবল এবং ডায়নামোর মতো নতুন ওপেন সোর্স পণ্য। একটি সভার জন্য একটি উজ্জ্বল চিহ্নের জন্য, একটি ধারণক্ষমতা সম্পন্ন এবং সংক্ষিপ্ত শব্দ খুঁজে বের করা প্রয়োজন ছিল যা টুইটার হ্যাশট্যাগে পুরোপুরি ফিট হবে। এই শর্তগুলির মধ্যে একটি RackSpace থেকে এরিক ইভান্স দ্বারা প্রস্তাবিত হয়েছিল - "NoSQL"। শব্দটি শুধুমাত্র একটি মিটিংয়ের জন্য পরিকল্পনা করা হয়েছিল এবং এতে গভীর শব্দার্থিক লোড ছিল না, কিন্তু এটি এমন ঘটেছে যে এটি একটি ভাইরাল বিজ্ঞাপনের মতো বিশ্বব্যাপী নেটওয়ার্ক জুড়ে ছড়িয়ে পড়ে এবং আইটি শিল্পের পুরো প্রবণতার প্রকৃত নাম হয়ে ওঠে। যাইহোক, Voldemort (Amazon Dynamo ক্লোন), Cassandra, Hbase (Google BigTable এর analogues), Hypertable, CouchDB, MongoDB সম্মেলনে বক্তব্য রাখেন।
এটা আবারও জোর দিয়ে বলা উচিত যে "NoSQL" শব্দটি সম্পূর্ণরূপে স্বতঃস্ফূর্ত এবং এর পিছনে একটি সাধারণভাবে স্বীকৃত সংজ্ঞা বা বৈজ্ঞানিক প্রতিষ্ঠান নেই। এই নামটি বরং রিলেশনাল ডাটাবেস থেকে দূরে আইটি বিকাশের ভেক্টরকে চিহ্নিত করে। এটি নট অনলি এসকিউএল-এর জন্য দাঁড়িয়েছে, যদিও নো এসকিউএল-এর সরাসরি সংজ্ঞার সমর্থক রয়েছে। প্রমোদ সদালাজ এবং মার্টিন ফাওলার তাদের সাম্প্রতিক বই "NoSQL ডিস্টিলড"-এ NoSQL বিশ্ব সম্পর্কে জ্ঞানকে দলবদ্ধ এবং পদ্ধতিগত করার চেষ্টা করেছেন।
2.2 NoSQL ডাটাবেসের মৌলিক বৈশিষ্ট্য
সমস্ত NoSQL-এর জন্য কিছু সাধারণ বৈশিষ্ট্য রয়েছে, যেহেতু অনেক ভিন্নধর্মী সিস্টেম এখন NoSQL লেবেলের অধীনে লুকিয়ে আছে (সম্ভবত সবচেয়ে সম্পূর্ণ তালিকাটি http://nosql-database.org/ এ পাওয়া যাবে)। অনেক বৈশিষ্ট্য শুধুমাত্র নির্দিষ্ট NoSQL ডাটাবেসের জন্য অদ্ভুত, তালিকা করার সময় আমি অবশ্যই এটি উল্লেখ করব।
1. কোন SQL ব্যবহার করা হয় না
আমি এএনএসআই এসকিউএল ডিএমএল বলতে চাচ্ছি, যেহেতু অনেক ডাটাবেস সুপরিচিত প্রিয় সিনট্যাক্সের অনুরূপ ক্যোয়ারী ভাষা ব্যবহার করার চেষ্টা করে, কিন্তু কেউ এটি সম্পূর্ণরূপে বাস্তবায়ন করতে পারেনি এবং সফল হওয়ার সম্ভাবনা কম। যদিও এমন গুজব রয়েছে যেগুলি এসকিউএল বাস্তবায়নের চেষ্টা করছে, উদাহরণস্বরূপ হ্যাডআপে ( http://www.drawntoscalehq.com/ এবং http://www.hadapt.com/ )।
2. কাঠামোবিহীন (স্কিমহীন)
অর্থ হল যে NoSQL ডাটাবেসে, রিলেশনাল ডাটাবেসের বিপরীতে, ডেটা স্ট্রাকচার নিয়ন্ত্রিত হয় না (অথবা দুর্বলভাবে টাইপ করা হয়, যদি আমরা প্রোগ্রামিং ভাষার সাথে সাদৃশ্য আঁকি) - আপনি প্রথমে ঘোষণামূলকভাবে কাঠামো পরিবর্তন না করে একটি পৃথক লাইন বা নথিতে একটি নির্বিচারে ক্ষেত্র যোগ করতে পারেন। পুরো টেবিলের। এইভাবে, যদি ডেটা মডেল পরিবর্তন করার প্রয়োজন হয়, তবে শুধুমাত্র যথেষ্ট পদক্ষেপ হল অ্যাপ্লিকেশন কোডের পরিবর্তন প্রতিফলিত করা।
উদাহরণস্বরূপ, মঙ্গোডিবিতে একটি ক্ষেত্রের নাম পরিবর্তন করার সময়:
BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"আমরা যদি অ্যাপ্লিকেশন যুক্তি পরিবর্তন করি, তাহলে পড়ার সময় আমরা একটি নতুন ক্ষেত্র আশা করি। কিন্তু ডেটা স্কিমার অভাবের কারণে, টোটালসাম ক্ষেত্রটি ইতিমধ্যে বিদ্যমান অন্যান্য অর্ডার অবজেক্ট থেকে অনুপস্থিত। এই পরিস্থিতিতে, পরবর্তী পদক্ষেপের জন্য দুটি বিকল্প রয়েছে।
প্রথমটি হল সমস্ত নথি ক্রল করা এবং সমস্ত বিদ্যমান নথিতে এই ক্ষেত্রটি আপডেট করা৷ ডেটার ভলিউমের কারণে, এই প্রক্রিয়াটি কোনও লক ছাড়াই ঘটে (অল্টার টেবিল রিনেম কলাম কমান্ডের সাথে তুলনীয়), তাই আপডেটের সময়, ইতিমধ্যে বিদ্যমান ডেটা অন্যান্য প্রক্রিয়া দ্বারা পড়তে পারে। অতএব, দ্বিতীয় বিকল্প - অ্যাপ্লিকেশন কোড পরীক্ষা করা - অনিবার্য:
BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum == null)
totalSum = order.getDouble("totalSum"); // This is the updated modelএবং ইতিমধ্যে যখন আমরা পুনরায় রেকর্ড করব, আমরা এই ক্ষেত্রটিকে একটি নতুন বিন্যাসে ডাটাবেসে লিখব।
স্কিমার অনুপস্থিতির একটি আনন্দদায়ক পরিণতি হ'ল স্পার্স ডেটা নিয়ে কাজ করার দক্ষতা। যদি একটি নথিতে একটি তারিখ_প্রকাশিত ক্ষেত্র থাকে এবং দ্বিতীয়টিতে না থাকে, তাহলে দ্বিতীয়টির জন্য কোনো খালি তারিখ_প্রকাশিত ক্ষেত্র তৈরি করা হবে না। এটি, নীতিগতভাবে, যৌক্তিক, কিন্তু একটি কম সুস্পষ্ট উদাহরণ হল কলাম-ফ্যামিলি NoSQL ডাটাবেস, যা টেবিল/কলামের পরিচিত ধারণা ব্যবহার করে। যাইহোক, একটি স্কিমার অভাবের কারণে, কলামগুলি ঘোষণামূলকভাবে ঘোষণা করা হয় না এবং ব্যবহারকারীর ডাটাবেস সেশনের সময় পরিবর্তন/যোগ করা যেতে পারে। এটি, বিশেষ করে, তালিকা বাস্তবায়নের জন্য গতিশীল কলাম ব্যবহার করার অনুমতি দেয়।
অসংগঠিত স্কিমার ত্রুটি রয়েছে - ডেটা মডেল পরিবর্তন করার সময় অ্যাপ্লিকেশন কোডে উপরে উল্লিখিত ওভারহেড ছাড়াও - বেস থেকে সমস্ত ধরণের বিধিনিষেধের অনুপস্থিতি (নাল, অনন্য, চেক সীমাবদ্ধতা, ইত্যাদি নয়), এবং সেখানে সমান্তরালভাবে বিভিন্ন প্রকল্পের ডাটাবেসের সাথে কাজ করার সময় কাঠামোর ডেটা বোঝা এবং নিয়ন্ত্রণে অতিরিক্ত অসুবিধা হয় (ডাটাবেসের পাশে কোনও অভিধান নেই)। যাইহোক, একটি দ্রুত পরিবর্তনশীল আধুনিক বিশ্বে, এই ধরনের নমনীয়তা এখনও একটি সুবিধা। একটি উদাহরণ হল টুইটার, যা পাঁচ বছর আগে টুইটের সাথে শুধুমাত্র সামান্য অতিরিক্ত তথ্য (সময়, টুইটার হ্যান্ডেল এবং মেটা-তথ্যের আরও কয়েকটি বাইট) সংরক্ষণ করেছিল, কিন্তু এখন, বার্তা ছাড়াও, আরও কয়েকটি কিলোবাইট মেটাডেটা ডাটাবেসে সংরক্ষণ করা হয়।
(এরপরে, আমরা প্রধানত মূল-মান, নথি এবং কলাম-ফ্যামিলি ডাটাবেস সম্পর্কে কথা বলছি, গ্রাফ ডাটাবেসে এই বৈশিষ্ট্যগুলি নাও থাকতে পারে)
2.3। সমষ্টি (সমষ্টি) আকারে ডেটার প্রতিনিধিত্ব
রিলেশনাল মডেলের বিপরীতে, যা অ্যাপ্লিকেশানের যৌক্তিক ব্যবসায়িক সত্তাকে স্বাভাবিককরণের উদ্দেশ্যে বিভিন্ন ভৌত সারণীতে সংরক্ষণ করে, NoSQL স্টোরগুলি সামগ্রিক বস্তু হিসাবে এই সত্তাগুলিতে কাজ করে:
এই উদাহরণটি একটি স্ট্যান্ডার্ড ই-কমার্স ধারণাগত রিলেশনাল মডেল "অর্ডার - অর্ডার আইটেম - পেমেন্ট - প্রোডাক্ট" এর জন্য সমষ্টি প্রদর্শন করে। উভয় ক্ষেত্রেই, অর্ডারটি একটি যৌক্তিক বস্তুতে অবস্থানের সাথে একত্রিত হয়, যখন প্রতিটি অবস্থান পণ্যের একটি লিঙ্ক এবং এর কিছু বৈশিষ্ট্য সংরক্ষণ করে, উদাহরণস্বরূপ, নাম (যেমন একটি পণ্য বস্তু পুনরুদ্ধার করার সময় অনুরোধ না করার জন্য এই ধরনের অস্বাভাবিককরণ প্রয়োজনীয়। একটি আদেশ - বিতরণ করা সিস্টেমের প্রধান নিয়ম হল বস্তুর মধ্যে "যোগদান")। একটি সমষ্টিতে, পেমেন্টগুলি অর্ডারের সাথে মিলিত হয় এবং এটি বস্তুর একটি অবিচ্ছেদ্য অংশ, অন্যটিতে সেগুলি একটি পৃথক বস্তুতে স্থাপন করা হয়। এটি NoSQL ডাটাবেসে একটি ডেটা স্ট্রাকচার ডিজাইন করার জন্য প্রধান নিয়ম প্রদর্শন করে - এটি অবশ্যই অ্যাপ্লিকেশনের প্রয়োজনীয়তাগুলি মেনে চলতে হবে এবং সর্বাধিক ঘন ঘন অনুরোধের জন্য যতটা সম্ভব অপ্টিমাইজ করা উচিত।
অনেকে আপত্তি করবেন, লক্ষ্য করবেন যে বড়, প্রায়শই অস্বাভাবিক, বস্তুর সাথে কাজ করা অনেক সমস্যায় পরিপূর্ণ হয় যখন ডেটাতে নির্বিচারে প্রশ্ন করার চেষ্টা করে যখন প্রশ্নগুলি সমষ্টির কাঠামোর সাথে খাপ খায় না। আমরা যদি অর্ডার লাইন আইটেম এবং অর্থপ্রদানের সাথে অর্ডারগুলি ব্যবহার করি (এভাবে অ্যাপটি কাজ করে), তবে ব্যবসা আমাদেরকে গত মাসে একটি নির্দিষ্ট পণ্যের কত ইউনিট বিক্রি হয়েছিল তা গণনা করতে বলে? এই ক্ষেত্রে, OrderItem টেবিলটি স্ক্যান করার পরিবর্তে (একটি রিলেশনাল মডেলের ক্ষেত্রে), আমাদের NoSQL স্টোরেজের সম্পূর্ণ অর্ডারগুলি পুনরুদ্ধার করতে হবে, যদিও আমাদের এই তথ্যের খুব বেশি প্রয়োজন হবে না। দুর্ভাগ্যবশত, এটি একটি আপস যা একটি বিতরণ করা সিস্টেমে করা উচিত: আমরা একটি প্রচলিত একক সার্ভার সিস্টেমের মতো ডেটা স্বাভাবিক করতে পারি না,
আমি একটি টেবিলে উভয় পদ্ধতির সুবিধা এবং অসুবিধাগুলিকে গ্রুপ করার চেষ্টা করেছি:
