বেস বনাম এসিড

6.1 সংক্ষেপণের যুদ্ধ: BASE বনাম। এসিআইডি

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

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

আসলে তা না. সর্বোপরি, তাদের, সম্পর্কীয় ডাটাবেসের মতো, একটি সুন্দর প্যাকেজে নিজেকে বিক্রি করতে হবে। এবং তারা তাদের নিজস্ব "রাসায়নিক" সংক্ষেপ - BASE নিয়ে এসেছিল।

6.2 প্রতিপক্ষ হিসাবে BASE

এবং এখানে আবার আমি অক্ষরের ক্রমানুসারে যাব না, তবে আমি মৌলিক শব্দ - ধারাবাহিকতা দিয়ে শুরু করব। আমাকে আপনার স্বীকৃতির প্রভাবকে সমান করতে হবে, কারণ এই ধারাবাহিকতার সাথে ACID-এর ধারাবাহিকতার কোনো সম্পর্ক নেই। সামঞ্জস্য শব্দের সমস্যা হল যে এটি অনেকগুলি প্রসঙ্গে ব্যবহৃত হয়। কিন্তু এই সঙ্গতিটির ব্যবহারের অনেক বিস্তৃত প্রেক্ষাপট রয়েছে এবং প্রকৃতপক্ষে এটি ঠিক সেই ধারাবাহিকতা যা বিতরণ করা সিস্টেম নিয়ে আলোচনা করার সময় আলোচনা করা হয়।

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

অনেক NoSQL ডাটাবেস বিচ্ছিন্নতার গ্যারান্টি ত্যাগ করে এবং "আন্তরিক সামঞ্জস্য" অফার করে যার ফলে আপনি শেষ পর্যন্ত বৈধ ডেটা দেখতে পাবেন, তবে আপনার লেনদেনটি অবৈধ মান পড়তে পারে - অর্থাৎ, অস্থায়ী, বা আংশিকভাবে আপডেট করা বা পুরানো। এটা সম্ভব যে ডেটা পড়ার সময় "অলস" মোডে সামঞ্জস্যপূর্ণ হবে ("পড়ার সময় অলসভাবে")।

NoSQL কে রিয়েল-টাইম অ্যানালিটিক্সের জন্য একটি ডাটাবেস হিসাবে কল্পনা করা হয়েছিল, এবং আরও বেশি গতি অর্জনের জন্য, তারা ধারাবাহিকতা ত্যাগ করেছে। এবং এরিক ব্রুয়ার, একই লোক যিনি BASE শব্দটি তৈরি করেছিলেন, তথাকথিত "CAP উপপাদ্য" প্রণয়ন করেছিলেন, যা অনুসারে:

ডিস্ট্রিবিউটেড কম্পিউটিং এর যেকোনো বাস্তবায়নের জন্য, নিম্নলিখিত তিনটি বৈশিষ্ট্যের মধ্যে দুটির বেশি প্রদান করা সম্ভব নয়:

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

আপনি যদি CAP এর একটি খুব সহজ ব্যাখ্যা চান, তাহলে আপনি এখানে যান।

এমন মতামত রয়েছে যে CAP উপপাদ্য কাজ করে না এবং সাধারণত খুব বিমূর্তভাবে প্রণয়ন করা হয়। কোন না কোন উপায়ে, NoSQL ডাটাবেসগুলি প্রায়শই CAP উপপাদ্যের প্রেক্ষাপটে সামঞ্জস্যতা অস্বীকার করে, যা নিম্নলিখিত পরিস্থিতি বর্ণনা করে: অনেকগুলি উদাহরণ সহ একটি ক্লাস্টারে ডেটা আপডেট করা হয়েছে, কিন্তু পরিবর্তনগুলি এখনও সমস্ত দৃষ্টান্তে সিঙ্ক্রোনাইজ করা হয়নি। মনে রাখবেন, আমি উপরে DynamoDB উদাহরণটি উল্লেখ করেছি, যা আমাকে বলেছিল: আপনার পরিবর্তনগুলি টেকসই হয়ে উঠেছে - এখানে আপনার জন্য একটি HTTP 200 - কিন্তু আমি শুধুমাত্র 10 সেকেন্ড পরে পরিবর্তনগুলি দেখেছি? একজন ডেভেলপারের দৈনন্দিন জীবনের আরেকটি উদাহরণ হল DNS, ডোমেইন নাম সিস্টেম। যদি কেউ না জানে, তবে এটি ঠিক সেই "অভিধান" যা http(গুলি) ঠিকানাগুলিকে IP ঠিকানায় অনুবাদ করে।

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

উপরন্তু, এন্ড-টু-এন্ড সামঞ্জস্যের অর্থ হতে পারে যে লেখার অনুরোধগুলি অর্ডারের বাইরে করা হবে: অর্থাৎ, সমস্ত ডেটা লেখা হবে, কিন্তু শেষ পর্যন্ত যে মানটি প্রাপ্ত হবে তা লেখার সারিতে শেষ হবে না।

নন-এসিড নোএসকিউএল ডাটাবেসগুলির একটি তথাকথিত "নরম অবস্থা" রয়েছে যা শেষ থেকে শেষ সামঞ্জস্যপূর্ণ মডেলের কারণে, যার অর্থ সিস্টেমের অবস্থা সময়ের সাথে সাথে পরিবর্তন হতে পারে, এমনকি ইনপুট ছাড়াই। কিন্তু এই ধরনের সিস্টেম বৃহত্তর অ্যাক্সেসিবিলিটি প্রদান করার জন্য প্রচেষ্টা করে। 100% প্রাপ্যতা প্রদান করা একটি তুচ্ছ কাজ নয়, তাই আমরা "মৌলিক প্রাপ্যতা" সম্পর্কে কথা বলছি। এবং একসাথে এই তিনটি ধারণা: "মূলত উপলব্ধ", "সফ্ট স্টেট" ("নরম অবস্থা") এবং "আন্তরিক সামঞ্জস্য" সংক্ষিপ্ত রূপ BASE গঠন করে।

সত্যি কথা বলতে, BASE এর ধারণাটি আমার কাছে ACID এর চেয়ে বেশি খালি বিপণন মোড়ক বলে মনে হয় - কারণ এটি নতুন কিছু দেয় না এবং ডাটাবেসকে কোনোভাবেই বৈশিষ্ট্যযুক্ত করে না। এবং নির্দিষ্ট ডেটাবেসে লেবেল (ACID, BASE, CAP) সংযুক্ত করা শুধুমাত্র বিকাশকারীদের বিভ্রান্ত করতে পারে। আমি যাইহোক এই শব্দের সাথে আপনাকে পরিচয় করিয়ে দেওয়ার সিদ্ধান্ত নিয়েছি, কারণ ডাটাবেস অধ্যয়ন করার সময় এটি বাইপাস করা কঠিন, কিন্তু এখন আপনি জানেন যে এটি কী, আমি চাই আপনি যত তাড়াতাড়ি সম্ভব এটি ভুলে যান। এবং আসুন বিচ্ছিন্নতার ধারণায় ফিরে যাই।

6.3 তাহলে BASE ডাটাবেসগুলি কি এসিআইডি মানদণ্ডগুলি পূরণ করে না?

মূলত, যেখানে এসিআইডি ডাটাবেসগুলি নন-এসিডি থেকে আলাদা তা হল নন-এসিডিগুলি আসলে বিচ্ছিন্নতা ত্যাগ করে। এই বুঝতে গুরুত্বপূর্ণ। কিন্তু ডাটাবেস ডকুমেন্টেশন পড়া এবং হার্মিটেজ প্রকল্পের ছেলেরা যেভাবে করে তা পরীক্ষা করা আরও গুরুত্বপূর্ণ। এটি এত গুরুত্বপূর্ণ নয় যে এই বা সেই ডাটাবেসের নির্মাতারা তাদের ব্রেনচাইল্ড - এসিআইডি বা বেস, ক্যাপ বা ক্যাপ নয়। গুরুত্বপূর্ণ বিষয় হল এই বা সেই ডাটাবেস ঠিক কি প্রদান করে।

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

• ডিবি পারমাণবিকতার কোন গ্যারান্টি প্রদান করে না। যদিও কিছু NoSQL ডাটাবেস পারমাণবিক ক্রিয়াকলাপের জন্য একটি পৃথক API অফার করে (যেমন DynamoDB);

• ডিবি কোন বিচ্ছিন্নতার গ্যারান্টি প্রদান করে না। এর অর্থ হতে পারে, উদাহরণস্বরূপ, ডাটাবেস ডেটাগুলি যে ক্রমে লেখা হয়েছিল সেই ক্রমে লিখবে না।

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

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

6.4 কিভাবে বিভিন্ন ডাটাবেস তথ্য সূচক, এবং কিভাবে এটি স্থায়িত্ব প্রভাবিত করে, এবং আরও অনেক কিছু

ডেটা সংরক্ষণ এবং পুনরুদ্ধার করার দুটি প্রধান পদ্ধতি রয়েছে।

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

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

সূচীকরণের আরেকটি পদ্ধতি B-trees ("B-trees") এর উপর ভিত্তি করে। একটি বি-ট্রিতে, ডেটা নির্দিষ্ট আকারের পৃষ্ঠাগুলিতে ডিস্কে লেখা হয়। ডেটার এই ব্লকগুলি প্রায়ই প্রায় 4 KB আকারের হয় এবং কী-মানের জোড়াগুলি কী দ্বারা সাজানো থাকে। একটি বি-ট্রি নোড হল একটি অ্যারের মতো যার সাথে বিভিন্ন পৃষ্ঠার লিঙ্ক রয়েছে। সর্বোচ্চ একটি অ্যারেতে লিঙ্কের সংখ্যাকে ব্রাঞ্চ ফ্যাক্টর বলা হয়। প্রতিটি পৃষ্ঠার পরিসর হল অন্য B-ট্রি নোড যার সাথে অন্যান্য পৃষ্ঠার রেঞ্জের লিঙ্ক রয়েছে।

অবশেষে, শীট স্তরে, আপনি পৃথক পৃষ্ঠাগুলি পাবেন। এই ধারণাটি নিম্ন-স্তরের প্রোগ্রামিং ভাষার পয়েন্টারগুলির অনুরূপ, এই পৃষ্ঠার উল্লেখগুলি মেমরির পরিবর্তে ডিস্কে সংরক্ষণ করা হয়। যখন ডাটাবেসে INSERTs এবং DELETEs ঘটে, তখন কিছু নোড ব্রাঞ্চিং ফ্যাক্টরের সাথে মেলে দুটি সাবট্রিতে বিভক্ত হতে পারে। প্রক্রিয়ার মাঝখানে কোনো কারণে ডাটাবেস ব্যর্থ হলে, ডেটার অখণ্ডতা আপোস করা হতে পারে। এটি যাতে না ঘটে তার জন্য, B-trees ব্যবহার করে ডাটাবেসগুলি একটি "রাইট-হেড লগ" বা WAL বজায় রাখে, যেখানে প্রতিটি লেনদেন রেকর্ড করা হয়। এই WAL বি-বৃক্ষের অবস্থা পুনরুদ্ধার করতে ব্যবহৃত হয় যদি এটি নষ্ট হয়ে যায়। এবং মনে হচ্ছে এটিই ডাটাবেসগুলিকে স্থায়িত্বের ক্ষেত্রে বি-ট্রি ব্যবহার করে আরও ভাল করে তোলে। কিন্তু LSM-ভিত্তিক ডাটাবেসগুলি এমন একটি ফাইলও বজায় রাখতে পারে যা মূলত WAL এর মতো একই কাজ করে। অতএব, আমি ইতিমধ্যে যা বলেছি তা পুনরাবৃত্তি করব, এবং সম্ভবত একাধিকবার: আপনি যে ডাটাবেসটি বেছে নিয়েছেন তার পরিচালনার প্রক্রিয়াগুলি বুঝুন।

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

যাইহোক, সূচকের নকশা ডাটাবেসের কর্মক্ষমতাকে সরাসরি প্রভাবিত করে। একটি LSM গাছের সাথে, ডিস্কে লেখাগুলি ক্রমিক হয় এবং B-trees একাধিক র্যান্ডম ডিস্ক অ্যাক্সেসের কারণ হয়, তাই B-trees-এর তুলনায় LSM-এর সাথে লেখার কাজ দ্রুত হয়। পার্থক্যটি বিশেষ করে চৌম্বকীয় হার্ড ডিস্ক ড্রাইভের (HDDs) জন্য তাৎপর্যপূর্ণ, যেখানে ক্রমিক লেখাগুলি এলোমেলো লেখার চেয়ে অনেক দ্রুত হয়। LSM গাছে পঠন ধীর হয় কারণ আপনাকে বিভিন্ন ডেটা স্ট্রাকচার এবং SS টেবিলগুলি দেখতে হবে যা কমপ্যাকশনের বিভিন্ন পর্যায়ে রয়েছে। আরো বিস্তারিতভাবে এটি এই মত দেখায়. যদি আমরা LSM এর সাথে একটি সাধারণ ডাটাবেস কোয়েরি করি, আমরা প্রথমে মেমটেবলে কীটি সন্ধান করব। যদি এটি সেখানে না থাকে, আমরা সাম্প্রতিকতম SSTable দেখুন; যদি সেখানে না থাকে, তাহলে আমরা উপান্তর SSTable দেখি, ইত্যাদি। যদি অনুরোধ করা কীটি বিদ্যমান না থাকে, তাহলে LSM এর মাধ্যমে আমরা এটি শেষ জানতে পারব। LSM গাছ ব্যবহার করা হয়, উদাহরণস্বরূপ: LevelDB, RocksDB, Cassandra এবং HBase.

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

যদি আমরা স্থায়িত্বের দিকটিতে ফিরে আসি, তাহলে উপসংহারটি নিম্নরূপ হবে: যেকোন ডাটাবেস যা ডিস্কে লিখে, ইনডেক্সিং প্রক্রিয়া নির্বিশেষে, আপনার ডেটার স্থায়িত্বের জন্য ভাল গ্যারান্টি প্রদান করতে পারে, তবে আপনাকে প্রতিটি নির্দিষ্ট ডাটাবেসের সাথে মোকাবিলা করতে হবে , এটা ঠিক কি অফার.

6.5 ইন-মেমরি ডিবি কীভাবে কাজ করে

যাইহোক, ডিস্কে লেখা ডাটাবেসগুলি ছাড়াও, তথাকথিত "ইন-মেমরি" ডাটাবেসগুলিও রয়েছে যা মূলত RAM এর সাথে কাজ করে। সংক্ষেপে, ইন-মেমরি ডেটাবেসগুলি সাধারণত দ্রুত লেখা এবং পড়ার গতির জন্য কম স্থায়িত্ব প্রদান করে, তবে এটি কিছু অ্যাপ্লিকেশনের জন্য উপযুক্ত হতে পারে।

আসল বিষয়টি হ'ল RAM মেমরি দীর্ঘকাল ধরে ডিস্কের চেয়ে বেশি ব্যয়বহুল, তবে সম্প্রতি এটি দ্রুত সস্তা হতে শুরু করেছে, যা একটি নতুন ধরণের ডাটাবেসের জন্ম দিয়েছে - যা যৌক্তিক, RAM থেকে ডেটা পড়ার এবং লেখার গতির কারণে। কিন্তু আপনি সঠিকভাবে জিজ্ঞাসা করবেন: এই ডাটাবেসগুলির ডেটা সুরক্ষা সম্পর্কে কী? এখানে আবার, আপনাকে বাস্তবায়নের বিশদটি দেখতে হবে। সাধারণভাবে, এই ধরনের ডাটাবেসের বিকাশকারীরা নিম্নলিখিত প্রক্রিয়াগুলি অফার করে:

• আপনি ব্যাটারি দ্বারা চালিত RAM ব্যবহার করতে পারেন;
• ডিস্কে পরিবর্তন লগ লেখা সম্ভব (উপরে উল্লিখিত WAL-এর মতো কিছু), কিন্তু ডেটা নিজেই নয়;
• আপনি পর্যায়ক্রমে ডাটাবেস অবস্থার অনুলিপিগুলি ডিস্কে লিখতে পারেন (যা, অন্যান্য বিকল্পগুলি ব্যবহার না করে, গ্যারান্টি দেয় না, তবে কেবল স্থায়িত্ব উন্নত করে);
• আপনি অন্যান্য মেশিনে RAM এর অবস্থা প্রতিলিপি করতে পারেন।

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

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