দয়া করে নোট করুন: আমি একটি এসকিউএল সার্ভারের দৃষ্টিকোণ থেকে উত্তর দিচ্ছি, তাই আমি এসকিউএল সার্ভার সম্পর্কিত নির্দিষ্ট কিছু ধারণার উল্লেখ করেছি, তবে আমি বিশ্বাস করি যে এই জাতীয় সমস্ত ধারণাগুলির অনুরূপ সুবিধাগুলি এবং সীমাবদ্ধতার সাথে অন্যান্য বড় আরডিবিএমএস প্ল্যাটফর্মগুলিতে সমতুল্য রয়েছে।
আমি অন্যান্য সম্ভাব্য উপকার / বোধ সম্পর্কে ভাবতে থাকায় আমি সম্ভবত এই উত্তরটি সম্পাদনা করা চালিয়ে যাব।
ঠিক আছে, এটি সত্যই স্কিমা, ভলিউম ইত্যাদির উপর নির্ভর করে একটি দোকান স্টোরিং ঠিক কী? এটি কীভাবে প্রায় 50,000 বিড়াল বা 50,000 পণ্য বা 50,000 ডানা বাদে ডেটা সংরক্ষণ করার থেকে আলাদা?
বিভিন্ন কারণ রয়েছে (কেবলমাত্র আকারের দিক ব্যতীত নিজেই) আপনি কেন একক ডাটাবেসে 50,000 বিভিন্ন গ্রাহকের জন্য ডেটা সংরক্ষণ করতে চান না, যদি সত্যিকার অর্থে গ্রাহক দ্বারা ডেটা সম্পূর্ণ আলাদা করা যায় (জিপকোডের মতো লুক টেবিলগুলি বা না অন্তর্ভুক্ত) অ্যাপ্লিকেশন-নির্দিষ্ট সারণী, যা একক, কেন্দ্রীয় ডাটাবেসে যেতে পারে):
যদি কোনও গ্রাহক অ্যাপ্লিকেশনটি আউটগ্রেজ করে, কেবল তাদের ডেটা বের করে নেওয়ার কোনও সহজ উপায় নেই এবং এটি অন্য কোনও উদাহরণে, সার্ভার ইত্যাদিতে সরিয়ে নেওয়া যায়, যদি না আপনি আগে থেকে পরিকল্পনা করেন এবং যেমন কিছু অংশে ভাগ না করেন CustomerIDএবং ৫০,০০০ ফাইলগোষ্ঠী (আপনি সীমাবদ্ধ থাকেন) যাইহোক, 15,000 পার্টিশন থেকে , বা আপনি যদি এসকিউএল সার্ভারের একটি পুরানো সংস্করণে রয়েছেন, এবং 1000 এর বেশি ফাইলগ্রুপ থাকা বিপর্যয়কর হতে পারে )। এছাড়াও নোট করুন যে বিভাজনের জন্য এন্টারপ্রাইজ সংস্করণ প্রয়োজন।
যদি এটির সক্রিয় হয়ে যায় যে আপনার সমস্ত গ্রাহক এই উদাহরণের জন্য খুব বড়, স্কেল আউট করার অর্থ হল নতুন হার্ডওয়্যার পাওয়া এবং সেখানে পুরো ডাটাবেস সরিয়ে নেওয়া (এবং সম্ভাব্যভাবে এটি আবার রাস্তায় নামানো)।
গ্রাহককে মুছে ফেলা সমানভাবে বেদনাদায়ক হতে পারে, কারণ আপনাকে খুব বড় টেবিল থেকে কয়েক% সারি মুছে ফেলতে হবে, এবং এটি সস্তা হবে না।
আপনার সম্ভবত গ্রাহকদের ডেটা বিস্তৃত হবে (এক বিলিয়ন সারি সহ এক গ্রাহক, ৫,০০০ সহ অন্য গ্রাহক)। এর ফলে কার্ডিনালিটি এবং পরিকল্পনার মান জড়িত প্যারামিটার স্নিফিং এবং ক্ষতিকারক পারফরম্যান্সের মতো জিনিসগুলি হতে পারে (যেহেতু আপনি সম্ভবত খুব আলাদা ডেটা সেটগুলির বিপরীতে একই প্রশ্নের জন্য একই পরিকল্পনা পুনরায় ব্যবহার করবেন)।
আপনার সমস্ত গ্রাহক একই একই এসএলএ এবং এইচএ / ডিআর পরিকল্পনার অধীন। আপনি হয় পুরো মিনিটের সাথে এন-মিনিটের লগ ব্যাকআপ সহ পুরো পুনরুদ্ধার মোডে ডেটাবেস পাবেন বা আপনি সরল এবং পুরো + ডিফ ব্যাকআপগুলিতে নির্ভর। যদি আপনার কোনও গ্রাহকের ত্রুটির কারণে ফিরে যেতে হয়, বা সময় সময়কালে ডাটাবেসটি পুনরুদ্ধার করতে হয় তবে এটি প্রতিটি গ্রাহককে প্রভাবিত করে।
যেখানে ক্লজ, উদাহরণস্বরূপ, অন্য গ্রাহকের তথ্য এইজন্য এক গ্রাহক, বা হতে পারে মধ্যে বাগ - সেখানে তথ্য আহরণ ত্রুটি জন্য সম্ভাব্য হয় সব অন্যান্য গ্রাহকদের ডেটা।
আইনী জালিয়াতি থাকতে পারে (কিছু সংস্থার কঠোর প্রয়োজনীয়তা থাকতে হবে যে আপনি তাদের ডেটা অন্য কোনও সংস্থার মতো বিশেষ ডাটাবেসে এবং বিশেষত তাদের প্রতিযোগীদের মতো রাখেন না)।
যদি কোনও কোনও গ্রাহকের ডেটার সুরক্ষা গুরুত্বপূর্ণ হয়, তবে এটি সারণীর মধ্যে বিচ্ছিন্নতার চেয়ে ডাটাবেস পৃথকীকরণ ব্যবহার করা আরও সহজ।
প্রতিটি গ্রাহককে পৃথক ডাটাবেসে থাকার কিছু সুবিধা (বা কমপক্ষে একাধিক ডাটাবেস থাকা, প্রতিটি গ্রাহকের জন্য):
- আকারের দিক থেকে, এটি ডিস্কে প্রায় একই আকার নিতে হবে।
- স্কেলিং আউট করা সহজ, যেহেতু আপনি কেবল একটি ডাটাবেস (বা অনেকগুলি) একটি অন্য সার্ভারে সরাতে পারেন।
- কোনও গ্রাহক এবং তার সমস্ত ডেটা মুছতে মোটামুটি সমান
DROP DATABASE।
- আপনি পরিকল্পনার জন্য আরও মেমোরি ব্যবহার করছেন (বা আপনার গ্রাহক প্রতি ক্যাশে কম পরিকল্পনা রয়েছে) তবে কমপক্ষে সেই পরিকল্পনাগুলি তাদের নিজ নিজ ডেটাবেজে থাকা ডেটার সাথে প্রাসঙ্গিক এবং পরিসংখ্যান / পরামিতি স্নিফিংয়ের সমস্যাগুলির জন্য কম ঝুঁকিপূর্ণ।
- আপনার সহজেই বিভিন্ন এসএলএ এবং ডিআর পরিকল্পনা থাকতে পারে, কিছু ডেটাবেস পূর্ণ এবং অন্যকে সাধারণভাবে রেখে। এছাড়াও সময়ে একটি বিন্দুতে ফিরে যাওয়া বা পুনরুদ্ধার কেবল সেই গ্রাহককেই প্রভাবিত করে।
- আপনি সহজেই I / O- তে বিভিন্ন ডেটাবেসগুলি (বলুন, আপনার উচ্চ অগ্রাধিকার গ্রাহক) সহজেই স্থাপন করতে পারেন। আপনি ফাইলগ্রুপগুলির সাথে একটি একক ডাটাবেসে এটি করতে পারেন, তবে এটি পরিচালনা করতে অনেক বেশি কৌশলযুক্ত (অন্তত আইএমএইচও)।
কিছু ত্রুটি:
- আকার একপাশে রেখে, আপনার সম্ভবত এসকিউএল সার্ভারের একক দৃষ্টিতে ৫০,০০০ ডাটাবেস থাকতে হবে না, সুতরাং এর অর্থ সম্ভবত একাধিক সার্ভারে স্কেলিং আউট হবে।
- শুরুর সময়টি উপরে যায় কারণ প্রতিটি ডাটাবেস শুরু করার ক্ষেত্রে কিছু অন্তর্নিহিত ওভারহেড থাকে।
- অ্যাপ্লিকেশনটি কিছুটা স্মার্ট হতে হবে - যেখানে কেবলমাত্র শর্তে গ্রাহকআইডি থাকার পরিবর্তে এটিকে গ্রাহকআইডির ডাটাবেসে গতিশীলভাবে সংযুক্ত করতে হবে। এটি সঠিক মাঝারি স্তরের সাথে কঠিন নয় তবে এটি একটি পরিবর্তন।
- হ্যাঁ, আপনার কাছে একই সারণী এবং পদ্ধতিগুলির অনেকগুলি অনুলিপি রয়েছে, তবে কোড এবং স্কিমা ডাটাবেসগুলিতে অভিন্ন, কেবল ডেটা আলাদা। সুতরাং কোড / স্কিমা পরিবর্তনগুলি মোতায়েন করা এখন একক প্রয়োগের পরিবর্তে কেবল একটি লুপ।
- আপনি ৫০,০০০ ডাটাবেস পরিচালনা করার সময় রক্ষণাবেক্ষণ কিছুটা আলাদা হয় - আবার সামগ্রিক আকার মোটামুটি একই তবে প্রক্রিয়াটি পরিবর্তন করতে হয় - আপনি একবারে সমস্ত 50,000 ডাটাবেসকে ডিফ্র্যাগ / রিইন্ডেক্স / ব্যাক আপ করতে পারবেন না। এই বলে যে, আমার আগের চাকরিতে আমি 500-1,000 অভিন্ন ডাটাবেসগুলির সাথে দৃষ্টান্তগুলি পরিচালনা করেছি এবং 3 টি অভিন্ন ডাটাবেস এবং 750 অভিন্ন ডাটাবেস পরিচালনার মধ্যে পার্থক্যটি কেবল সময় লাগে।