🥇 আরও ডেভেলপারদের ডাটাবেস সম্পর্কে এটি জানা উচিত প্রোহোস্টার

বিঃদ্রঃ. অনুবাদ: Jaana Dogan Google-এর একজন অভিজ্ঞ প্রকৌশলী যিনি বর্তমানে Go-তে লেখা কোম্পানির প্রোডাকশন পরিষেবার পর্যবেক্ষণের উপর কাজ করছেন। এই নিবন্ধে, যা ইংরেজিভাষী শ্রোতাদের মধ্যে ব্যাপক জনপ্রিয়তা অর্জন করেছে, তিনি DBMSs (এবং কখনও কখনও সাধারণভাবে বিতরণ করা সিস্টেম) সম্পর্কিত 17 পয়েন্ট গুরুত্বপূর্ণ প্রযুক্তিগত বিবরণ সংগ্রহ করেছেন যা বড়/চাহিদার অ্যাপ্লিকেশনগুলির বিকাশকারীদের জন্য বিবেচনা করার জন্য দরকারী।

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

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

আমি ইমানুয়েল ওডেকে, রেইন হেনরিকস এবং অন্যদের এই নিবন্ধটির পূর্ববর্তী সংস্করণে তাদের প্রতিক্রিয়ার জন্য ধন্যবাদ জানাতে চাই।

আপনি ভাগ্যবান যদি 99,999% সময় নেটওয়ার্ক সমস্যার সৃষ্টি না করে।

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

স্প্যানার (গুগলের বিশ্বব্যাপী বিতরণকৃত ডাটাবেস) এর জন্য 99,999% এর প্রাপ্যতার হার সহ, Google দাবি করে যে শুধুমাত্র 7,6% সমস্যা নেটওয়ার্কের সাথে সম্পর্কিত। একই সময়ে, কোম্পানিটি তার বিশেষায়িত নেটওয়ার্ককে উচ্চ প্রাপ্যতার "প্রধান স্তম্ভ" বলে। অধ্যয়ন বেইলিস এবং কিংসবেরি, 2014 সালে পরিচালিত, একটি চ্যালেঞ্জবিতরণকৃত কম্পিউটিং সম্পর্কে ভুল ধারণা", যা পিটার ডয়েচ 1994 সালে প্রণয়ন করেছিলেন। নেটওয়ার্ক কি সত্যিই নির্ভরযোগ্য?

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

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

ACID মানে অনেক ভিন্ন জিনিস

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

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

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

MongoDB ACID প্রয়োজনীয়তা মেনে চলে কিনা তা নিয়ে বিতর্ক 4 সংস্করণ প্রকাশের পরেও অব্যাহত রয়েছে। MongoDB দীর্ঘদিন ধরে সমর্থিত নয় লগিং, যদিও ডিফল্টভাবে ডেটা প্রতি 60 সেকেন্ডে একবারের বেশি ডিস্কে প্রতিশ্রুতিবদ্ধ ছিল। নিম্নলিখিত দৃশ্যকল্প কল্পনা করুন: একটি অ্যাপ্লিকেশন দুটি লেখা পোস্ট করে (w1 এবং w2)। MongoDB সফলভাবে w1 সঞ্চয় করে, কিন্তু হার্ডওয়্যার ব্যর্থতার কারণে w2 হারিয়ে গেছে।

চিত্র দৃশ্যকল্প চিত্রিত. মঙ্গোডিবি ডিস্কে ডেটা লেখার আগেই ক্র্যাশ হয়ে যায়

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

প্রতিটি ডাটাবেসের নিজস্ব ধারাবাহিকতা এবং বিচ্ছিন্নতা প্রক্রিয়া রয়েছে

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

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

বিদ্যমান সঙ্গতি মডেল এবং তাদের মধ্যে সম্পর্কের পর্যালোচনা

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

এসকিউএল স্ট্যান্ডার্ড নিম্নলিখিত বিচ্ছিন্নতা স্তর উল্লেখ করে:

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

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

বিচ্ছিন্নতা স্তরের জন্য সমর্থন প্রায়শই একটি প্রদত্ত DBMS-এ বিজ্ঞাপন দেওয়া হয়, তবে শুধুমাত্র এর আচরণের একটি যত্নশীল অধ্যয়ন প্রকৃতপক্ষে কী ঘটছে তা প্রকাশ করতে পারে।

বিভিন্ন ডিবিএমএস-এর জন্য বিভিন্ন বিচ্ছিন্নতা স্তরে একযোগে অসঙ্গতির পর্যালোচনা

মার্টিন ক্লেপম্যান তার প্রকল্পে আশ্রম বিভিন্ন বিচ্ছিন্নতা স্তরের তুলনা করে, সঙ্গতিগত অসঙ্গতিগুলি সম্পর্কে কথা বলে এবং ডাটাবেস একটি নির্দিষ্ট বিচ্ছিন্নতা স্তর মেনে চলতে সক্ষম কিনা। ক্লেপম্যানের গবেষণা দেখায় যে ডেটাবেস বিকাশকারীরা বিচ্ছিন্নতা স্তর সম্পর্কে কীভাবে ভিন্নভাবে চিন্তা করে।

আশাবাদী ব্লকিং উদ্ধারে আসে যখন স্বাভাবিকটি বজায় রাখা কঠিন হয়।

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

আশাবাদী লক একটি পদ্ধতি যেখানে একটি স্ট্রিং পড়ার সময়, এটি তার সংস্করণ, চেকসাম বা শেষ পরিবর্তনের সময় বিবেচনা করে। এটি আপনাকে নিশ্চিত করতে দেয় যে কোনও এন্ট্রি পরিবর্তন করার আগে কোনও পারমাণবিক সংস্করণ পরিবর্তন নেই:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

এই ক্ষেত্রে, টেবিল আপডেট করা products অন্য একটি অপারেশন পূর্বে এই সারি পরিবর্তন করা হলে বাহিত করা হবে না. যদি এই সারিতে অন্য কোন অপারেশন না করা হয়, তাহলে একটি সারির পরিবর্তন ঘটবে এবং আমরা বলতে পারি যে আপডেটটি সফল হয়েছে।

নোংরা পড়া এবং ডেটা ক্ষতি ছাড়াও অন্যান্য অসঙ্গতি রয়েছে

যখন ডেটা সামঞ্জস্যের কথা আসে, তখন ফোকাস রেসের অবস্থার সম্ভাব্যতার উপর থাকে যা নোংরা পড়া এবং ডেটা ক্ষতির কারণ হতে পারে। যাইহোক, ডেটা অসঙ্গতি সেখানে থামে না।

এই ধরনের অসঙ্গতির একটি উদাহরণ হল রেকর্ডিং বিকৃতি (skews লিখুন). বিকৃতি সনাক্ত করা কঠিন কারণ সেগুলি সাধারণত সক্রিয়ভাবে অনুসন্ধান করা হয় না। এগুলি নোংরা পড়া বা ডেটা হারানোর কারণে নয়, তবে ডেটাতে রাখা যৌক্তিক সীমাবদ্ধতার লঙ্ঘনের কারণে।

উদাহরণস্বরূপ, আসুন একটি পর্যবেক্ষণ অ্যাপ্লিকেশন বিবেচনা করি যার জন্য একজন অপারেটরকে সর্বদা অন-কল থাকতে হবে:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

ডাটাবেস এবং ব্যবহারকারী সবসময় কি করতে হবে তা নিয়ে একমত হয় না

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

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

প্রথম নজরে, নীচের প্রোগ্রামে, T1 এবং T2 ক্রমানুসারে বলা হয়, কিন্তু যদি এই ফাংশনগুলি অ-ব্লকিং হয় এবং অবিলম্বে ফলাফলটি ফর্মে ফিরিয়ে দেয় প্রতিশ্রুতি, তারপর কলের ক্রম নির্ধারণ করা হবে যখন তারা ডাটাবেসে প্রবেশ করবে তখন মুহুর্তগুলি দ্বারা নির্ধারিত হবে:

ফলাফল1 = T1() // বাস্তব ফলাফল প্রতিশ্রুতি
ফলাফল2 = T2()

যদি পারমাণবিকতার প্রয়োজন হয় (অর্থাৎ, হয় সমস্ত ক্রিয়াকলাপ সম্পূর্ণ করতে হবে বা বাতিল করতে হবে) এবং সিকোয়েন্সের বিষয়গুলি, তাহলে অপারেশন T1 এবং T2 একটি একক লেনদেনের মধ্যে সঞ্চালিত হতে হবে।

অ্যাপ্লিকেশন-স্তরের শার্ডিং অ্যাপ্লিকেশনের বাইরে সরানো যেতে পারে

Sharding একটি ডাটাবেসকে অনুভূমিকভাবে বিভাজন করার একটি পদ্ধতি। কিছু ডেটাবেস স্বয়ংক্রিয়ভাবে অনুভূমিকভাবে ডেটা বিভক্ত করতে পারে, অন্যরা পারে না, বা এটিতে খুব ভাল নয়। যখন ডেটা আর্কিটেক্ট/ডেভেলপাররা ঠিক কীভাবে ডেটা অ্যাক্সেস করা হবে তা ভবিষ্যদ্বাণী করতে সক্ষম হন, তখন তারা ডাটাবেসে এই কাজটি অর্পণ করার পরিবর্তে ব্যবহারকারীর জায়গায় অনুভূমিক পার্টিশন তৈরি করতে পারে। এই প্রক্রিয়াটিকে "অ্যাপ্লিকেশন-লেভেল শার্ডিং" বলা হয় (অ্যাপ্লিকেশন-লেভেল শার্ডিং).

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

একটি আর্কিটেকচারের উদাহরণ যেখানে অ্যাপ্লিকেশন সার্ভারগুলিকে শার্ডিং পরিষেবা থেকে আলাদা করা হয়

একটি পৃথক পরিষেবাতে শার্ডিং স্থানান্তর করা অ্যাপ্লিকেশনগুলিকে পুনরায় স্থাপন করার প্রয়োজন ছাড়াই বিভিন্ন শার্ডিং কৌশল ব্যবহার করার ক্ষমতাকে প্রসারিত করে। ভিটেস অ্যাপ্লিকেশন স্তরে এই ধরনের একটি শার্ডিং সিস্টেমের একটি উদাহরণ। Vitess MySQL-এর জন্য অনুভূমিক শার্ডিং প্রদান করে এবং ক্লায়েন্টদের MySQL প্রোটোকলের মাধ্যমে এটির সাথে সংযোগ করার অনুমতি দেয়। সিস্টেম ডেটাকে বিভিন্ন MySQL নোডে ভাগ করে যা একে অপরের সম্পর্কে কিছুই জানে না।

স্বয়ংক্রিয় বৃদ্ধি বিপজ্জনক হতে পারে

AUTOINCREMENT প্রাথমিক কী তৈরি করার একটি সাধারণ উপায়। প্রায়শই এমন ঘটনা ঘটে যখন ডেটাবেসগুলি আইডি জেনারেটর হিসাবে ব্যবহার করা হয় এবং ডেটাবেসে শনাক্তকারী তৈরি করার জন্য ডিজাইন করা টেবিল থাকে। স্বয়ংক্রিয়-বৃদ্ধি ব্যবহার করে প্রাথমিক কীগুলি তৈরি করা আদর্শ থেকে দূরে থাকার বিভিন্ন কারণ রয়েছে:

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

একটি পদ্ধতির বিষয়ে সিদ্ধান্ত নেওয়ার আগে, ইন্ডেক্সিং, পার্টিশনিং এবং শার্ডিংয়ের উপর স্বয়ংক্রিয়-বর্ধিত ID এবং UUID-এর প্রভাব বিবেচনা করুন।

পুরানো ডেটা দরকারী হতে পারে এবং লক করার প্রয়োজন নেই৷

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

সামান্য বাসি ডেটা পড়া উপযোগী হতে পারে, উদাহরণস্বরূপ, ডেটা থেকে বিশ্লেষণ তৈরি করার সময় বা আনুমানিক সমষ্টিগত মান গণনা করার সময়।

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

অ্যাপ্লিকেশন সার্ভারটি স্থানীয় প্রতিরূপ থেকে ডেটা পড়ে যা 5 সেকেন্ডের পুরানো, এমনকি যদি সর্বশেষ সংস্করণটি প্রশান্ত মহাসাগরের অন্য দিকে উপলব্ধ থাকে

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

যে কোন সময় উৎস বিকৃতি সাপেক্ষে

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

NTP সার্ভারগুলি সিঙ্ক্রোনাইজেশনের জন্য ব্যবহার করা হয়, কিন্তু সিঙ্ক্রোনাইজেশন প্রক্রিয়া নিজেই নেটওয়ার্ক বিলম্বের বিষয়। এমনকি একই ডেটা সেন্টারে একটি NTP সার্ভারের সাথে সিঙ্ক্রোনাইজ করতে কিছু সময় লাগে। এটা স্পষ্ট যে একটি পাবলিক NTP সার্ভারের সাথে কাজ করা আরও বড় বিকৃতি হতে পারে।

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

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

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

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

স্প্যানার উপাদানগুলি TrueTime ব্যবহার করে, যেখানে TT.now() একটি ব্যবধান ফেরত দেয়, তাই স্প্যানার কেবল সেই বিন্দু পর্যন্ত ঘুমায় যেখানে এটি নিশ্চিত হতে পারে যে বর্তমান সময় একটি নির্দিষ্ট বিন্দু অতিক্রম করেছে।

বর্তমান সময় নির্ধারণে হ্রাসকৃত সঠিকতা মানে স্প্যানার অপারেশনের সময়কাল বৃদ্ধি এবং কর্মক্ষমতা হ্রাস। এই কারণেই সর্বোচ্চ সম্ভাব্য নির্ভুলতা বজায় রাখা গুরুত্বপূর্ণ যদিও এটি একটি সম্পূর্ণ নির্ভুল ঘড়ি প্রাপ্ত করা অসম্ভব।

বিলম্বের অনেক অর্থ আছে

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

কর্মক্ষমতা প্রয়োজনীয়তা একটি নির্দিষ্ট লেনদেনের জন্য মূল্যায়ন করা উচিত

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

সম্পর্কিত টেবিলে নির্দিষ্ট সীমাবদ্ধতা এবং সারি প্যাডিং সহ সারণি X (50 মিলিয়ন সারি সহ) একটি নতুন সারি সন্নিবেশ করার সময় থ্রুপুট এবং লেটেন্সি লিখুন।
বন্ধুর গড় সংখ্যা 500 হলে নির্দিষ্ট ব্যবহারকারীর বন্ধুদের বন্ধুদের প্রদর্শনে বিলম্ব।
ব্যবহারকারীর ইতিহাস থেকে শীর্ষ 100টি এন্ট্রি পুনরুদ্ধার করতে লেটেন্সি যখন ব্যবহারকারী প্রতি ঘন্টায় X এন্ট্রি সহ অন্য 500 জন ব্যবহারকারীকে অনুসরণ করে।

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

প্রতিটি অপারেশনের জন্য মেট্রিক্স সংগ্রহ করার সময় উচ্চ কার্ডিনালিটি সম্পর্কে সচেতন হন। উচ্চ-শক্তি ডিবাগিং ডেটা পেতে লগ, ইভেন্ট সংগ্রহ, বা বিতরণ ট্রেসিং ব্যবহার করুন। প্রবন্ধে "লেটেন্সি ডিবাগ করতে চান?» আপনি বিলম্ব ডিবাগিং পদ্ধতির সাথে নিজেকে পরিচিত করতে পারেন।

নেস্টেড লেনদেন বিপজ্জনক হতে পারে

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

আপনি ক্লায়েন্ট লাইব্রেরিগুলি ব্যবহার করে নেস্টেড লেনদেনগুলি এড়াতে পারেন যা সেগুলি সনাক্ত করতে এবং বাইপাস করতে পারে। যদি নেস্টেড লেনদেনগুলি পরিত্যাগ করা না যায়, তবে অপ্রত্যাশিত পরিস্থিতি এড়াতে তাদের বাস্তবায়নে বিশেষ যত্ন নিন যেখানে নেস্টেডগুলির কারণে সম্পূর্ণ লেনদেনগুলি দুর্ঘটনাক্রমে বাতিল হয়ে যায়।

বিভিন্ন স্তরে লেনদেনগুলিকে এনক্যাপসুলেট করার ফলে অপ্রত্যাশিত নেস্টেড লেনদেন হতে পারে এবং কোড পাঠযোগ্যতার দৃষ্টিকোণ থেকে, এটি লেখকের উদ্দেশ্য বোঝা কঠিন করে তুলতে পারে। নিম্নলিখিত প্রোগ্রামটি একবার দেখুন:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

উপরের কোডের আউটপুট কি হবে? এটি কি উভয় লেনদেনকে ফিরিয়ে দেবে, নাকি কেবল অভ্যন্তরীণ এক? কি হবে যদি আমরা লাইব্রেরির একাধিক স্তরের উপর নির্ভর করি যা আমাদের জন্য লেনদেন তৈরি করে? আমরা কি এই ধরনের কেস সনাক্ত করতে এবং উন্নত করতে সক্ষম হব?

একাধিক অপারেশন সহ একটি ডেটা স্তর কল্পনা করুন (যেমন newAccount) ইতিমধ্যেই নিজস্ব লেনদেনে প্রয়োগ করা হয়েছে। কি হবে যদি আপনি সেগুলিকে উচ্চ-স্তরের ব্যবসায়িক যুক্তির অংশ হিসাবে চালান যা তার নিজস্ব লেনদেনের মধ্যে চলে? এই ক্ষেত্রে বিচ্ছিন্নতা এবং ধারাবাহিকতা কি হবে?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

লেনদেন আবেদন রাষ্ট্রের সাথে আবদ্ধ করা উচিত নয়

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

ক্যোয়ারী পরিকল্পনাকারীরা আপনাকে একটি ডাটাবেস সম্পর্কে অনেক কিছু বলতে পারে

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

SELECT * FROM articles where author = "rakyll" order by title;

ফলাফল দুটি উপায়ে পুনরুদ্ধার করা যেতে পারে:

সম্পূর্ণ টেবিল স্ক্যান: আপনি টেবিলের প্রতিটি এন্ট্রি দেখতে পারেন এবং একটি মিল লেখকের নামের সাথে নিবন্ধগুলি ফেরত দিতে পারেন, এবং তারপর তাদের অর্ডার করতে পারেন।
সূচক স্ক্যান: আপনি একটি সূচী ব্যবহার করে মানানসই আইডিগুলি খুঁজে পেতে, সেই সারিগুলি পেতে এবং তারপরে তাদের অর্ডার করতে পারেন৷

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

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

অনলাইন মাইগ্রেশন কঠিন কিন্তু সম্ভব

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

বিভিন্ন অনলাইন মাইগ্রেশন মডেল আছে। এখানে তাদের মধ্যে একটি:

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

অতিরিক্ত তথ্যের জন্য, আমি যোগাযোগ করার পরামর্শ দিই প্রবন্ধ, যা এই মডেলের উপর ভিত্তি করে স্ট্রাইপের মাইগ্রেশন কৌশলের বিবরণ দেয়।

ডাটাবেসের একটি উল্লেখযোগ্য বৃদ্ধি অনির্দেশ্যতা বৃদ্ধি করে

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

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

...

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

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

উত্স: www.habr.com

আরও বিকাশকারীদের ডাটাবেস সম্পর্কে এটি জানা উচিত