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

এই ধরনের পরিস্থিতিতে উদ্ভূত যৌক্তিক প্রশ্ন হল এমন সিস্টেমগুলির সাথে কী করা উচিত যা ক্লাসিকভাবে অপারেশনগুলির পারমাণবিক-সামঞ্জস্যতার উপর উচ্চ চাহিদা রাখে এবং একই সাথে দ্রুত বিতরণ করা ক্লাস্টারগুলির প্রয়োজন - আর্থিক, অনলাইন স্টোর, ইত্যাদি? অনুশীলন দেখায় যে এই প্রয়োজনীয়তাগুলি আর প্রাসঙ্গিক নয়: আর্থিক ব্যাঙ্কিং সিস্টেমের একজন ডিজাইনার এখানে যা বলেছেন: “আমরা যদি সত্যিই এটিএম-এর গ্লোবাল নেটওয়ার্কে (এটিএম) প্রতিটি লেনদেন সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতাম, তাহলে লেনদেনে এত বেশি সময় লাগবে যে গ্রাহকরা রাগ করে পালিয়ে যাবে। যদি আপনি এবং আপনার সঙ্গী একই সময়ে টাকা উত্তোলন করেন এবং সীমা অতিক্রম করেন তাহলে কি হবে? "আপনারা উভয়েই টাকা পাবেন, এবং আমরা পরে এটি ঠিক করব।"
আরেকটি উদাহরণ হল ছবিতে দেখানো হোটেল বুকিং। যে সমস্ত অনলাইন স্টোরের ডেটা নীতি চূড়ান্ত সামঞ্জস্যতা অনুমান করে তাদের এই ধরনের পরিস্থিতিতে (স্বয়ংক্রিয় দ্বন্দ্ব সমাধান, অপারেশন রোলব্যাক, অন্যান্য ডেটার সাথে আপডেট) ক্ষেত্রে ব্যবস্থা প্রদান করা প্রয়োজন। অনুশীলনে, হোটেলগুলি সর্বদা জরুরী পরিস্থিতিতে বিনামূল্যে কক্ষগুলির একটি "পুল" রাখার চেষ্টা করে এবং এটি একটি বিতর্কিত পরিস্থিতির সমাধান হতে পারে।
আসলে, দুর্বল ACID বৈশিষ্ট্যগুলির মানে এই নয় যে তারা একেবারেই নেই। বেশিরভাগ ক্ষেত্রে, একটি রিলেশনাল ডাটাবেসের সাথে কাজ করা একটি অ্যাপ্লিকেশন যৌক্তিকভাবে সম্পর্কিত বস্তুগুলি (অর্ডার - অর্ডার আইটেম) পরিবর্তন করতে একটি লেনদেন ব্যবহার করে, যা প্রয়োজনীয়, যেহেতু এগুলি বিভিন্ন টেবিল। একটি NoSQL ডাটাবেসে ডেটা মডেলের সঠিক ডিজাইনের সাথে (একটি সমষ্টি হল একটি অর্ডার এবং অর্ডার আইটেমগুলির একটি তালিকা), আপনি একটি রিলেশনাল ডাটাবেসের মতো একটি রেকর্ড পরিবর্তন করার সময় একই স্তরের বিচ্ছিন্নতা অর্জন করতে পারেন।
3.2। বিতরণ করা সিস্টেম, ভাগ করা সংস্থান নেই (কিছুই ভাগ করে না)
আবার, এটি ডাটাবেস গ্রাফের ক্ষেত্রে প্রযোজ্য নয়, যার গঠন, সংজ্ঞা অনুসারে, দূরবর্তী নোডগুলিতে ভালভাবে ছড়িয়ে পড়ে না।
এটি সম্ভবত NoSQL ডেটাবেসগুলির বিকাশের প্রধান লেইটমোটিফ। বিশ্বে তথ্যের তুষারপাত বৃদ্ধি এবং যুক্তিসঙ্গত সময়ে এটি প্রক্রিয়া করার প্রয়োজনীয়তার সাথে, উল্লম্ব স্কেলেবিলিটির সমস্যা দেখা দিয়েছে - প্রসেসরের গতি 3.5 গিগাহার্জে বন্ধ হয়ে গেছে, ডিস্ক থেকে পড়ার গতিও বাড়ছে ধীর গতি, এবং একটি শক্তিশালী সার্ভারের মূল্য সর্বদা বেশ কয়েকটি সাধারণ সার্ভারের মোট মূল্যের চেয়ে বেশি। এই পরিস্থিতিতে, প্রচলিত রিলেশনাল ডাটাবেস, এমনকি ডিস্কের অ্যারেতে ক্লাস্টার করা, গতি, স্কেলেবিলিটি এবং থ্রুপুট সমস্যা সমাধান করতে সক্ষম নয়।
পরিস্থিতি থেকে বেরিয়ে আসার একমাত্র উপায় হল অনুভূমিক স্কেলিং, যখন বেশ কয়েকটি স্বাধীন সার্ভার একটি দ্রুত নেটওয়ার্ক দ্বারা সংযুক্ত থাকে এবং প্রতিটি ডেটার শুধুমাত্র অংশ এবং / অথবা পঠন-আপডেট অনুরোধের শুধুমাত্র অংশের মালিক/প্রসেস করে। এই আর্কিটেকচারে, স্টোরেজ ক্ষমতা (ক্ষমতা, প্রতিক্রিয়া সময়, থ্রুপুট) বাড়ানোর জন্য, আপনাকে কেবল ক্লাস্টারে একটি নতুন সার্ভার যুক্ত করতে হবে - এবং এটিই। শেয়ারিং, রেপ্লিকেশন, ফল্ট টলারেন্স (এক বা একাধিক সার্ভার সাড়া দেওয়া বন্ধ করলেও ফলাফল পাওয়া যাবে), নোড যোগ করার ক্ষেত্রে ডেটা পুনঃবন্টন NoSQL ডাটাবেস নিজেই পরিচালনা করে।
আমি সংক্ষেপে বিতরণ করা NoSQL ডাটাবেসের প্রধান বৈশিষ্ট্য উপস্থাপন করব:
প্রতিলিপি - আপডেট করার সময় অন্যান্য নোডে ডেটা অনুলিপি করা। উভয়কেই বৃহত্তর স্কেলেবিলিটি অর্জন করতে এবং ডেটার প্রাপ্যতা এবং নিরাপত্তা বাড়াতে দেয়। এটি দুটি প্রকারে বিভক্ত করার প্রথাগত:
প্রভু-দাস :

প্রথম প্রকার পড়ার জন্য ভাল মাপযোগ্যতা অনুমান করে (যেকোন নোড থেকে ঘটতে পারে), কিন্তু অ-স্কেলযোগ্য লেখা (শুধুমাত্র মাস্টার নোডে)। ধ্রুবক প্রাপ্যতা নিশ্চিত করার সাথে সূক্ষ্মতাও রয়েছে (একটি মাস্টার ক্র্যাশের ক্ষেত্রে, ম্যানুয়ালি বা স্বয়ংক্রিয়ভাবে অবশিষ্ট নোডগুলির একটি তার জায়গায় বরাদ্দ করা হয়)। দ্বিতীয় প্রকারের প্রতিলিপি অনুমান করে যে সমস্ত নোড সমান এবং এটি পড়ার এবং লেখার অনুরোধ উভয়ই পরিবেশন করতে পারে।
শেয়ারিং হল নোড দ্বারা ডেটা বিভাজন:

স্পিড এবং থ্রুপুট বাড়ানোর জন্য রিলেশনাল ডাটাবেসের জন্য শার্ডিং প্রায়ই একটি "ক্র্যাচ" হিসাবে ব্যবহার করা হত: ব্যবহারকারী অ্যাপ্লিকেশনটি বিভিন্ন স্বাধীন ডাটাবেস জুড়ে ডেটা বিভাজন করে এবং, যখন ব্যবহারকারী সংশ্লিষ্ট ডেটার অনুরোধ করে, একটি নির্দিষ্ট ডাটাবেস অ্যাক্সেস করে । NoSQL ডাটাবেসে, শার্ডিং, যেমন প্রতিলিপি, ডাটাবেস নিজেই স্বয়ংক্রিয়ভাবে সম্পন্ন হয় এবং ব্যবহারকারীর অ্যাপ্লিকেশন এই জটিল প্রক্রিয়া থেকে আলাদা।
3.3। NoSQL ডাটাবেসগুলি বেশিরভাগই ওপেন সোর্স এবং 21 শতকে তৈরি করা হয়েছে
এটি দ্বিতীয় ভিত্তিতে যে সদালাজ এবং ফাউলার অবজেক্ট ডেটাবেসগুলিকে NoSQL হিসাবে শ্রেণীবদ্ধ করেননি (যদিও http://nosql-database.org/ এগুলিকে সাধারণ তালিকায় অন্তর্ভুক্ত করে), যেহেতু সেগুলি 90 এর দশকে তৈরি হয়েছিল এবং কখনই খুব বেশি জনপ্রিয়তা পায়নি। ..
NoSQL আন্দোলন একটি বিশাল গতিতে জনপ্রিয়তা অর্জন করছে। যাইহোক, এর মানে এই নয় যে রিলেশনাল ডাটাবেসগুলি ভেস্টিজিয়াল বা প্রাচীন কিছু হয়ে উঠছে। খুব সম্ভবত তারা সক্রিয়ভাবে আগের মতোই ব্যবহার করা হবে এবং ব্যবহার করা হবে, তবে আরও বেশি সংখ্যক নোএসকিউএল ডেটাবেস তাদের সাথে সিম্বিয়াসিসে কাজ করবে। আমরা পলিগ্লট অধ্যবসায়ের একটি যুগে প্রবেশ করছি, এমন একটি যুগ যেখানে বিভিন্ন প্রয়োজনের জন্য বিভিন্ন ডেটা স্টোর ব্যবহার করা হয়। এখন ডেটার অপ্রতিদ্বন্দ্বী উৎস হিসেবে রিলেশনাল ডাটাবেসের কোনো একচেটিয়া অধিকার নেই। ক্রমবর্ধমানভাবে, স্থপতিরা ডেটার প্রকৃতির উপর ভিত্তি করে স্টোরেজ বেছে নেয় এবং আমরা কীভাবে এটিকে ম্যানিপুলেট করতে চাই, কী পরিমাণ তথ্য প্রত্যাশিত। এবং তাই সবকিছু আরও আকর্ষণীয় হয়ে ওঠে।
নীচে আমরা একটি উদাহরণ হিসাবে NoSQL Cassandra DBMS ব্যবহার করে একটি বিতরণ করা ডাটাবেসের অপারেশন বোঝার চেষ্টা করব ...
GO TO FULL VERSION