3.4 ডেটা স্থাপত্য ও সংরক্ষণ

পরিচিতি ও প্রেরণা

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

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

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

মূল নীতিসমূহ

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

সুপারিশ

ওয়ার্কলোড থেকে সংরক্ষণ দৃষ্টান্ত বাছুন

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

পলিগ্লট পারসিস্টেন্স ইচ্ছাকৃতভাবে গ্রহণ করুন

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

ডেটা মডেল করুন এবং স্কিমা বিবর্তনকে নিরন্তর গণ্য করুন

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

চোখ খুলে ক্যাশিং ও অকার্যকরকরণ নকশা করুন

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

পরিসরের জন্য লেনদেন, লকিং ও কনকারেন্সি সামলান

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

স্টোর ধরন	সবচেয়ে ভালো	শক্তি	দুর্বলতা
রিলেশনাল	রেকর্ডের সিস্টেম, জটিল অখণ্ডতা	ACID, জয়েন, পরিণত টুলিং	লেখা অনুভূমিকভাবে স্কেল করা কঠিনতর
ডকুমেন্ট	সমষ্টিগত পড়া, নমনীয় স্কিমা	দ্রুত পূর্ণ-অবজেক্ট পড়া/লেখা, নমনীয়	দুর্বল ডকুমেন্ট-জোড়া জয়েন/লেনদেন
কী-ভ্যালু	সেশন, ক্যাশ, সরল লুকআপ	চরম গতি ও স্কেল	কী ছাড়া কোয়েরি নেই
গ্রাফ	সম্পর্ক-ভারী কোয়েরি	দ্রুত ট্র্যাভার্সাল, প্রকাশক্ষম	সংকীর্ণ পরিচালনা দক্ষতা, স্কেলিং সীমা
কলামার	বিশ্লেষণ, রিপোর্টিং	দ্রুত সমষ্টিগত স্ক্যান, সংকোচন	সারি-স্তরের লেনদেনমূলক লেখায় দুর্বল
টাইম-সিরিজ	মেট্রিক, টেলিমেট্রি, IoT	দক্ষ যোগ ও সময় কোয়েরি	সংকীর্ণ উদ্দেশ্য

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. প্রতিটি জটিল ডেটাসেটের জন্য, সবাই কি একটি রেকর্ডের সিস্টেমের নাম বলতে পারে, নাকি ক্যাশ ও প্রজেকশন নিঃশব্দে সত্য হিসেবে গণ্য হয়? ডেটা কোডকে ছাড়িয়ে টেকে, এবং সবচেয়ে ক্ষতিকর ডেটা ঘটনা আসে সরে যাওয়া থেকে: একটি ক্যাশ, অনুসন্ধান ইনডেক্স বা পড়ার প্রজেকশন কর্তৃত্বপূর্ণ বলে ভুল বোঝা হয় এবং আসল উৎস থেকে নিঃশব্দে বিচ্যুত হয়। একটি বড় দলে এটি ঘটে যখন মালিকানা ঝাপসা এবং বেশ কয়েকটি সার্ভিস ওভারল্যাপ করা কপি লেখে, তাই ঘটনার সময় কেউ বলতে পারে না কোন মান সঠিক। আপনার গুরুত্বপূর্ণ ডেটার একটি মানচিত্র আনুন এবং প্রতিটির জন্য একটি কর্তৃত্বপূর্ণ স্টোর এবং তা থেকে পুনর্নির্মাণযোগ্য হতে হবে এমন উদ্ভূত কপি। অর্থ ও সরকারে কোন রেকর্ড আইনি উৎস তা প্রমাণ করতে এবং বাকিগুলো পুনর্গঠন করতে পারা প্রায়ই নিয়ন্ত্রক প্রয়োজন, সুবিধা নয়। রেকর্ডের সিস্টেম থেকে পুনর্নির্মাণ করতে পারেন না এমন যেকোনো কিছুই নিজেই একটি রেকর্ডের সিস্টেম, আপনি তা চান বা না চান।

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

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

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

5. কোন ক্যাশ করা বা রেপ্লিকেট করা মান বাসি হয়ে সেবা পেলে প্রসাধনী নয়, সম্মতি বা নিরাপত্তা ব্যর্থতা ঘটাবে, এবং সেই প্রতিটি অকার্যকরকরণ পথ কি পরীক্ষিত? ক্যাশিং হলো পারফরম্যান্সের পোশাকে সঠিকতার সমস্যা: বিপদ ধীরতা নয়, বরং বদলে যাওয়ার পরে একটি অধিকার, ব্যালেন্স, সম্মতি ফ্ল্যাগ বা অ্যাক্সেস সিদ্ধান্ত সেবা দেওয়া। একটি বড় প্রতিষ্ঠানের জন্য বিপদ ছড়ানো, কারণ ক্যাশ ও এজ স্তর দল জুড়ে জমে এবং কোনো একজন বলতে পারে না কী কোথায় ক্যাশ করা বা কখন মুছে যায়। টানাপোড়েন প্রকৃত: আক্রমণাত্মক ক্যাশিং ও দীর্ঘ TTL লেটেন্সি কেনে এবং ডেটাবেস রক্ষা করে, আর কঠোর সতেজতা দুটিই খরচ করে। ক্যাশ করা ও CDN-সেবিত ডেটার একটি তালিকা আনুন, কোন এন্ট্রি সম্মতি বা নিরাপত্তা পরিণতি বহন করে তা চিহ্নিত করে, এবং সেই প্রতিটির অকার্যকরকরণ পথ কেবল কনফিগার না হয়ে চর্চায় চালানো হয়েছে তার প্রমাণসহ। নিয়ন্ত্রিত ও সরকারি পরিবেশে একটি বাসি সম্মতি বা যোগ্যতা মান নিরীক্ষণযোগ্য ব্যর্থতা, তাই সেই আইটেমের সুস্পষ্ট, পরীক্ষিত অকার্যকরকরণ পথ লাগে নয়তো তা আদৌ ক্যাশ করা উচিত নয়।

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

খাতভেদে দৃষ্টিভঙ্গি

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

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

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

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

উদাহরণ

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

এন্টারপ্রাইজ। একটি খুচরা ব্যাংক তার কর্তৃত্বপূর্ণ খতিয়ান একটি শক্তিশালীভাবে সামঞ্জস্যপূর্ণ রিলেশনাল ডেটাবেসে রাখে: প্রতিটি পোস্টিং একটি যথাযথ ACID লেনদেন, লেখার স্কেলের জন্য অ্যাকাউন্ট পরিসর ধরে শার্ড করা। তাকে ঘিরে একটি পলিগ্লট সম্পত্তি: গ্রাহক লুকআপের জন্য একটি অনুসন্ধান ইনডেক্স, মোবাইল অ্যাপে অ্যাকাউন্ট সারাংশের জন্য একটি Redis ক্যাশ (রাইট-থ্রু, ছোট TTL), নিয়ন্ত্রক ও বিশ্লেষণাত্মক রিপোর্টিংয়ের জন্য একটি কলামার ওয়্যারহাউস, এবং লেনদেন-নেটওয়ার্ক প্রতারণা শনাক্তকরণের জন্য একটি গ্রাফ ডেটাবেস। খতিয়ানের স্কিমা পরিবর্তন ডুয়াল-রাইটসহ এক্সপ্যান্ড-কন্ট্র্যাক্ট ব্যবহার করে যাতে ২৪/৭ সিস্টেম স্থানান্তরের জন্য কখনো ডাউনটাইম নেয় না।

সরকার। একটি জাতীয় যানবাহন রেজিস্ট্রি বিধিবদ্ধ ধারণ ও পূর্ণ নিরীক্ষা ইতিহাসসহ একটি রিলেশনাল রেকর্ডের সিস্টেমে কর্তৃত্বপূর্ণ রেকর্ড সংরক্ষণ করে। জনসাধারণ-মুখী “একটি যানবাহন পরীক্ষা করুন” লুকআপ একটি রিড রেপ্লিকা ও ছোট TTL-এর এজ ক্যাশ থেকে সেবা পায়, কারণ সামান্য বাসি পাবলিক ডেটা গ্রহণযোগ্য এবং পড়ার ভলিউম লেখাকে বামন করে। ডেটা আবাসন আইন সব রেকর্ড দেশের ভেতরে রাখতে দাবি করে, তাই প্রতিটি স্টোর সার্বভৌম অঞ্চলে প্রভিশন করা এবং CDN কেবল ব্যক্তিগত নয় এমন ডেটা ক্যাশ করতে কনফিগার করা। পরিবহন নীতি দ্বারা আদিষ্ট নতুন ক্ষেত্র যোগ করার স্থানান্তর পাইপলাইনের মাধ্যমে পশ্চাৎ-সামঞ্জস্যপূর্ণভাবে প্রয়োগ করা হয় যাতে আইনি সময়সীমার সময় সেবা উপলব্ধ থাকে।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

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

পরিপক্বতা মডেল

• স্তর ১: সূচনা। প্রতিটি উদ্দেশ্যে একটি ডেটাবেস ব্যবহার হয়। স্কিমা পরিবর্তন হাতে ও অ্যাড হক, স্থানান্তর শৃঙ্খলা নেই। ক্যাশিং আকস্মিক এবং অকার্যকরকরণ পরবর্তী ভাবনা। পারফরম্যান্স সমস্যা প্রতিক্রিয়ায় বড় মেশিন কিনে সমাধান করা হয়, এবং কেউ নির্ভরযোগ্যভাবে একটি ডেটাসেটের রেকর্ডের সিস্টেমের নাম বলতে পারে না।
• স্তর ২: বিকাশ। কিছু সংরক্ষণ পছন্দ সুচিন্তিত এবং একটি ক্যাশ বা ওয়্যারহাউস দেখা দিয়েছে, কিন্তু চর্চা দল ভেদে ভিন্ন। স্থানান্তর সংস্করণযুক্ত কিন্তু মাঝেমধ্যে ডাউনটাইম দাবি করে, এবং যে এটি জানে সে এক্সপ্যান্ড-কন্ট্র্যাক্ট ব্যবহার করে। বেশ কয়েকটি সার্ভিস এখনো ডেটাবেস ভাগ করে, এবং ক্যাশিং কৌশল এক দল থেকে অন্যটিতে ভিন্ন।
• স্তর ৩: মানসম্মতকরণ। পলিগ্লট পারসিস্টেন্স ওয়ার্কলোডের সঙ্গে মেলানো, প্রতিটি স্টোর একটি সার্ভিসের মালিকানাধীন এবং কখনো ভাগ করা নয়। স্বয়ংক্রিয়, পশ্চাৎ-সামঞ্জস্যপূর্ণ, শূন্য-ডাউনটাইম এক্সপ্যান্ড-কন্ট্র্যাক্ট স্থানান্তর নথিবদ্ধ, প্রয়োগ করা প্রতিষ্ঠান-ব্যাপী মান। ক্যাশিং কৌশল, TTL ও অকার্যকরকরণ পথ সুস্পষ্ট নকশা নিদর্শন, এবং প্রতিটি ডেটাসেটের একক রেকর্ডের সিস্টেম নথিবদ্ধ, উদ্ভূত কপি তা থেকে পুনর্নির্মাণযোগ্য।
• স্তর ৪: ব্যবস্থাপনা। ডেটা সম্পত্তি ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। আপনি স্থানান্তরের সময়কাল ও রোলব্যাক হার, নিজের-লেখা-পড়া প্রয়োজনের বিপরীতে রেপ্লিকেশন ল্যাগ, ক্যাশ হিট অনুপাত ও বাসিভাব ঘটনা, প্রতি-স্টোর পরিচালনগত খরচ, এবং লক্ষ্য পার্সেন্টাইলে কোয়েরি লেটেন্সি অনুসরণ করেন, তারপর সংখ্যার ওপর কাজ করেন। ধারণ ও আবাসন বিধিবদ্ধ প্রয়োজনের বিপরীতে নিরীক্ষিত, উদ্ভূত ডেটার সঠিকতা নিরন্তর যাচাই করা হয়, এবং প্রতিটি ইঞ্জিনকে সে যে ওয়ার্কলোড সেবা দেয় তার বিপরীতে নিজের খরচ যথার্থ করতে হয়।
• স্তর ৫: সমন্বয়। ডেটা স্থাপত্য নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে সক্ষমতা, খরচ ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত। অ্যাক্সেস প্যাটার্ন ও খরচ সরলে শার্ডিং, ক্যাশিং ও সামঞ্জস্য পছন্দ প্রতি ওয়ার্কলোডে পুনর্ভারসাম্যে আনা হয়, এবং যে স্টোর আর নিজের জায়গা অর্জন করে না তা পরিকল্পিত স্থানান্তরের মাধ্যমে অবসর দেওয়া হয়। স্কিমা বিবর্তন, আর্কাইভ ও আবাসন সম্পূর্ণ স্বয়ংক্রিয় ও খাপ-খাওয়ানো, তাই সম্পত্তি জরুরি পুনঃপ্ল্যাটফর্মিং ছাড়াই নতুন আদেশ ও লোডে নিজেকে নতুন আকার দেয়।

আলোচনার ভাবনা

1. আপনার বর্তমান স্টোরের কোনগুলো এমন কাজ করছে যার জন্য তাদের নকশা করা হয়নি, এবং সঠিক ইঞ্জিন কী হত?
2. আপনি কি আজ আপনার সবচেয়ে বড় টেবিলে শূন্য ডাউনটাইমে একটি স্কিমা পরিবর্তন করতে পারেন? না পারলে কেন?
3. আপনার সিস্টেম কোথায় এমন ডেটা ক্যাশ করে যার বাসিভাব সম্মতি বা সঠিকতা ব্যর্থতা ঘটাতে পারে?
4. কোন সার্ভিস ডেটাবেস ভাগ করে, এবং প্রত্যেককে নিজস্ব একটি দিতে কী লাগবে?
5. কোথায় একটি একক লেখাযোগ্য ডেটাবেস আপনার স্কেলিং সীমা, এবং রিড-রেপ্লিকেশন নাকি শার্ডিং সঠিক পরবর্তী ধাপ?
6. আপনার ধারণ ও আর্কাইভ কৌশল কী, এবং এর জন্য জবাবদিহি কার?

প্রধান শিক্ষা

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

তথ্যসূত্র ও আরও পড়ার জন্য

• Martin Kleppmann, Designing Data-Intensive Applications
• Pramod Sadalage ও Martin Fowler, NoSQL Distilled
• Pramod Sadalage ও Scott Ambler, Refactoring Databases: Evolutionary Database Design
• C. J. Date, An Introduction to Database Systems
• Joe Celko, SQL for Smarties
• Vlad Mihalcea, High-Performance Java Persistence (লেনদেন, আইসোলেশন, কনকারেন্সি)
• Eric Evans, Domain-Driven Design (বাউন্ডেড কনটেক্সট ও ডেটা মালিকানা)
• Werner Vogels, “Eventually Consistent”