একটি কী-ভ্যালু স্টোর ডিজাইন (Design A Key-value Store)

একটি কী-ভ্যালু স্টোর, যাকে কী-ভ্যালু ডাটাবেসও বলা হয়, হলো একটি নন-রিলেশনাল (non-relational) ডাটাবেস। প্রতিটি অনন্য শনাক্তকারী (unique identifier) একটি কী (key) হিসাবে সংরক্ষিত হয় এবং এর সাথে সংশ্লিষ্ট ভ্যালু (value) থাকে। এই ডেটা পেয়ারিংকে “কী-ভ্যালু” পেয়ার বলা হয়।

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

• প্লেইন টেক্সট কী: “last_logged_in_at”
• হ্যাশ করা কী: 253DDEC4

একটি কী-ভ্যালু পেয়ারের ভ্যালু স্ট্রিং, লিস্ট, অবজেক্ট ইত্যাদি হতে পারে। কী-ভ্যালু স্টোরগুলোতে ভ্যালুকে সাধারণত একটি অপেক (opaque) অবজেক্ট হিসাবে বিবেচনা করা হয়, যেমন Amazon dynamo [1], Memcached [2], Redis [3], ইত্যাদি।

এখানে একটি কী-ভ্যালু স্টোরে একটি ডেটা স্নিপেট দেওয়া হলো:

টেবিল ১

এই অধ্যায়ে, আপনাকে একটি কী-ভ্যালু স্টোর ডিজাইন করতে বলা হয়েছে যা নিম্নলিখিত অপারেশনগুলো সমর্থন করে:

• put(key, value) // “key”-এর সাথে সংশ্লিষ্ট “value” ইনসার্ট করুন
• get(key) // “key”-এর সাথে সংশ্লিষ্ট “value” নিয়ে আসুন

সমস্যাটি বোঝা এবং ডিজাইনের সুনির্দিষ্ট ক্ষেত্র (scope) নির্ধারণ করা

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

• একটি কী-ভ্যালু পেয়ারের সাইজ ছোট: 10 KB এর কম।
• বড় ডেটা সংরক্ষণ করার ক্ষমতা।
• উচ্চ প্রাপ্যতা (High availability): সিস্টেমটি দ্রুত রেসপন্স করে, এমনকি ফেইলিওরের (failures) সময়ও।
• উচ্চ স্কেলেবিলিটি (High scalability): সিস্টেমটিকে বড় ডেটা সেট সমর্থন করার জন্য স্কেল করা যায়।
• স্বয়ংক্রিয় স্কেলিং (Automatic scaling): ট্র্যাফিকের ওপর ভিত্তি করে সার্ভার যোগ/মুছে ফেলা স্বয়ংক্রিয় হওয়া উচিত।
• টিউনেবল কনসিস্টেন্সি (Tunable consistency)।
• কম লেটেন্সি (Low latency)।

সিঙ্গেল সার্ভার কী-ভ্যালু স্টোর

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

• ডেটা কম্প্রেশন (Data compression)
• শুধুমাত্র ঘন ঘন ব্যবহৃত ডেটা মেমরিতে এবং বাকিগুলো ডিস্কে সংরক্ষণ করা

এই অপ্টিমাইজেশনগুলো সত্ত্বেও, একটি সিঙ্গেল সার্ভার খুব দ্রুত তার ক্ষমতায় পৌঁছে যেতে পারে। বড় ডেটা সমর্থন করার জন্য একটি ডিস্ট্রিবিউটেড কী-ভ্যালু স্টোর প্রয়োজন।

ডিস্ট্রিবিউটেড কী-ভ্যালু স্টোর

একটি ডিস্ট্রিবিউটেড কী-ভ্যালু স্টোরকে ডিস্ট্রিবিউটেড হ্যাশ টেবিলও বলা হয়, যা অনেক সার্ভার জুড়ে কী-ভ্যালু পেয়ার বিতরণ করে। একটি ডিস্ট্রিবিউটেড সিস্টেম ডিজাইন করার সময়, CAP (Consistency, Availability, Partition Tolerance) থিওরেম বোঝা গুরুত্বপূর্ণ।

CAP থিওরেম

CAP থিওরেম বলে যে একটি ডিস্ট্রিবিউটেড সিস্টেমের জন্য এই তিনটি গ্যারান্টির মধ্যে দুটির বেশি একই সাথে প্রদান করা অসম্ভব: কনসিস্টেন্সি, অ্যাভেইলেবিলিটি, এবং পার্টিশন টলারেন্স। আসুন কয়েকটি সংজ্ঞা প্রতিষ্ঠা করি।

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

CAP থিওরেম বলে যে ৩টি বৈশিষ্ট্যের মধ্যে ২টিকে সমর্থন করতে হলে তিনটির মধ্যে একটি বৈশিষ্ট্যকে ত্যাগ করতে হবে, যেমনটি চিত্র ১-এ দেখানো হয়েছে।

[চিত্র ১-এর বর্ণনা: ছবিটি CAP থিওরেম উপস্থাপন করে, তিনটি ওভারল্যাপিং বৃত্ত ব্যবহার করে ভিজ্যুয়ালাইজ করা হয়েছে। প্রতিটি বৃত্ত ডিস্ট্রিবিউটেড ডেটা স্টোরের তিনটি মূল গ্যারান্টির একটি নির্দেশ করে: কনসিস্টেন্সি, অ্যাভেইলেবিলিটি, এবং পার্টিশন টলারেন্স। সবচেয়ে বড় বৃত্তটি, যা টিল (teal) রঙের, ‘কনসিস্টেন্সি’ লেবেলযুক্ত, যা নির্দেশ করে যে সমস্ত নোড একই সময়ে একই ডেটা দেখে। সবুজ বৃত্তটি, ‘অ্যাভেইলেবিলিটি’ লেবেলযুক্ত, নির্দেশ করে যে প্রতিটি রিকোয়েস্ট একটি রেসপন্স পায়, এমনকি যদি এটি সবচেয়ে আপ-টু-ডেট ডেটা নাও হয়। হলুদ বৃত্তটি, ‘পার্টিশন টলারেন্স’ লেবেলযুক্ত, সিস্টেমের নেটওয়ার্ক পার্টিশন ঘটলেও কাজ চালিয়ে যাওয়ার ক্ষমতা নির্দেশ করে। ওভারল্যাপিং অঞ্চলগুলো অর্জনযোগ্য সম্ভাব্য সমন্বয়গুলো দেখায়: কনসিস্টেন্সি এবং পার্টিশন টলারেন্সের ছেদকে ‘CP’ লেবেল করা হয়েছে, যা এই দুটি গ্যারান্টি অগ্রাধিকার দেওয়া সিস্টেম নির্দেশ করে (অ্যাভেইলেবিলিটির বিনিময়ে)। অ্যাভেইলেবিলিটি এবং পার্টিশন টলারেন্সের ছেদকে ‘AP’ লেবেল করা হয়েছে, যা এই দুটি অগ্রাধিকার দেওয়া সিস্টেম দেখায় (কনসিস্টেন্সির বিনিময়ে)। তিনটি বৃত্তের ছোট ছেদকে ‘CA’ লেবেল করা হয়েছে, যা CAP থিওরেম অনুযায়ী বাস্তবে অর্জনযোগ্য নয়। পরিশেষে, নিচে একটি ছোট টেক্সট পড়া যায় ‘Viewer does not support full SVG 1.1,’ যা ইমেজ রেন্ডারিং সফটওয়্যারের একটি সীমাবদ্ধতা নির্দেশ করে।] চিত্র ১

আজকাল, কী-ভ্যালু স্টোরগুলো তারা সমর্থন করে এমন দুটি CAP বৈশিষ্ট্যের ওপর ভিত্তি করে শ্রেণীবদ্ধ করা হয়:

• CP (কনসিস্টেন্সি এবং পার্টিশন টলারেন্স) সিস্টেম: একটি CP কী-ভ্যালু স্টোর অ্যাভেইলেবিলিটি ত্যাগ করে কনসিস্টেন্সি এবং পার্টিশন টলারেন্স সমর্থন করে।
• AP (অ্যাভেইলেবিলিটি এবং পার্টিশন টলারেন্স) সিস্টেম: একটি AP কী-ভ্যালু স্টোর কনসিস্টেন্সি ত্যাগ করে অ্যাভেইলেবিলিটি এবং পার্টিশন টলারেন্স সমর্থন করে।
• CA (কনসিস্টেন্সি এবং অ্যাভেইলেবিলিটি) সিস্টেম: একটি CA কী-ভ্যালু স্টোর পার্টিশন টলারেন্স ত্যাগ করে কনসিস্টেন্সি এবং অ্যাভেইলেবিলিটি সমর্থন করে। যেহেতু নেটওয়ার্ক ফেইলিওর অনিবার্য, একটি ডিস্ট্রিবিউটেড সিস্টেমকে অবশ্যই নেটওয়ার্ক পার্টিশন সহ্য করতে হবে। তাই, বাস্তব-বিশ্বের অ্যাপ্লিকেশনগুলোতে একটি CA সিস্টেম থাকতে পারে না।

আপনি উপরে যা পড়েছেন তা বেশিরভাগই সংজ্ঞার অংশ। এটি বোঝা সহজ করতে, আসুন কিছু বাস্তব উদাহরণের দিকে তাকাই। ডিস্ট্রিবিউটেড সিস্টেমে, ডেটা সাধারণত একাধিকবার রেপ্লিকেট (replicated) করা হয়। ধরে নিন ডেটা তিনটি রেপ্লিকা নোড, n1, n2 এবং n3-এ রেপ্লিকেট করা হয়েছে যেমনটি চিত্র ২-এ দেখানো হয়েছে।

আদর্শ পরিস্থিতি

আদর্শ বিশ্বে, নেটওয়ার্ক পার্টিশন কখনও ঘটে না। n1-এ লেখা ডেটা স্বয়ংক্রিয়ভাবে n2 এবং n3-এ রেপ্লিকেট হয়। কনসিস্টেন্সি এবং অ্যাভেইলেবিলিটি উভয়ই অর্জিত হয়।

[চিত্র ২-এর বর্ণনা: ছবিটি একটি সাধারণ নেটওয়ার্ক টপোলজি ডায়াগ্রাম উপস্থাপন করে যা তিনটি নোড দেখায়, যাদের লেবেল n1, n2, এবং n3, সিলিন্ডারের মতো ডাটাবেস আইকন হিসাবে চিত্রিত। প্রতিটি নোড যোগাযোগ লিংক নির্দেশকারী রেখার মাধ্যমে অন্য দুটি নোডের সাথে সংযুক্ত, একটি সম্পূর্ণ গ্রাফ বা ত্রিভুজ গঠন করে। n1 উভয় n2 এবং n3 এর সাথে সংযুক্ত, এবং n2 এবং n3 সরাসরি একে অপরের সাথে সংযুক্ত। সংযোগকারী রেখাগুলোতে কোনো নির্দিষ্ট ডেটা প্রবাহের দিক বা ধরন নির্দেশ করা হয়নি; ডায়াগ্রামটি শুধুমাত্র নোডগুলোর মধ্যে সংযোগের অস্তিত্ব চিত্রিত করে। ডায়াগ্রামের নিচে ‘Viewer does not support full SVG 1.1’ টেক্সটটি উপস্থিত, যা ব্যবহৃত ইমেজ ভিউয়ারের একটি সম্ভাব্য রেন্ডারিং সমস্যা নির্দেশ করে। ডায়াগ্রামের মধ্যে কোনো URL বা প্যারামিটার দৃশ্যমান নয়।] চিত্র ২

বাস্তব-বিশ্বের ডিস্ট্রিবিউটেড সিস্টেম

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

[চিত্র ৩-এর বর্ণনা: ছবিটি একটি সাধারণ নেটওয়ার্ক টপোলজি ডায়াগ্রাম উপস্থাপন করে যা তিনটি নোড দেখায়, যাদের লেবেল n1, n2, এবং n3, সিলিন্ডারের মতো ডাটাবেস আইকন হিসাবে চিত্রিত। প্রতিটি নোড যোগাযোগ লিংক নির্দেশকারী রেখার মাধ্যমে অন্য দুটি নোডের সাথে সংযুক্ত, একটি সম্পূর্ণ গ্রাফ বা ত্রিভুজ গঠন করে। n1 উভয় n2 এবং n3 এর সাথে সংযুক্ত, এবং n2 এবং n3 সরাসরি একে অপরের সাথে সংযুক্ত। সংযোগকারী রেখাগুলোতে কোনো নির্দিষ্ট ডেটা প্রবাহের দিক বা ধরন নির্দেশ করা হয়নি; ডায়াগ্রামটি শুধুমাত্র নোডগুলোর মধ্যে সংযোগের অস্তিত্ব চিত্রিত করে। নিচে ‘Viewer does not support full SVG 1.1’ টেক্সটটি একটি ব্রাউজার-সম্পর্কিত বার্তা যা নেটওয়ার্ক টপোলজির সাথে সম্পর্কিত নয়।] চিত্র ৩

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

তবে, যদি আমরা কনসিস্টেন্সির চেয়ে অ্যাভেইলেবিলিটি বেছে নিই (AP সিস্টেম), তবে সিস্টেমটি রিড গ্রহণ করা চালিয়ে যায়, যদিও এটি স্টেল ডেটা রিটার্ন করতে পারে। রাইটের জন্য, n1 এবং n2 রাইট গ্রহণ করা চালিয়ে যাবে, এবং নেটওয়ার্ক পার্টিশন সমাধান হলে ডেটা n3-এ সিঙ্ক করা হবে।

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