কোন মুহুর্তে ক্লায়েন্টের জন্য একটি ডাটাবেস অপ্রাপ্ত হতে পারে?


31

আমাদের সিস্টেমে একের জন্য, আমাদের কাছে সংবেদনশীল ক্লায়েন্টের ডেটা রয়েছে এবং প্রতিটি ক্লায়েন্টের ডেটা আলাদা ডাটাবেসে সংরক্ষণ করে। আমাদের সেই সিস্টেমের জন্য প্রায় 10-15 ক্লায়েন্ট রয়েছে।

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

এই সম্পর্কে কোন চিন্তা?


আমি সার্ভারে একাধিক ডাটাবেস থাকার উপকারিতা জানি না ( এটির সাথে আমার কোনও সমস্যা হয়নি) তবে একই ডাটাবেসের মধ্যে অনেক স্কীম ধারণা টেকনিকেট.মাইক্রোসফট.ইন.ইউএস / লিবারি / ডিডি 207005.aspx , উভয়ই উপলব্ধ করে বিচ্ছিন্নতা এবং সুরক্ষা। সুতরাং, আপনি এই আর্কিটেকচারটিও চেষ্টা করে দেখতে পারেন।
আলেকজান্দ্রোস

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

4
আমি একক সার্ভারে 3,000+ ডাটাবেস (প্রতি ক্লায়েন্ট 1 জন) সহ সিস্টেমগুলি দেখেছি। আমি খুব বেশি চিন্তা করব না - ক্লায়েন্টের গণনা বাড়ার সাথে সাথে আপনি যথাযথভাবে সংস্থানগুলি পরিকল্পনা করার বিষয়টি নিশ্চিত করুন এবং ব্যবহারের উপর নজর রাখুন।
সর্বাধিক ভার্নন

আপনি এই পড়া পারে, বিশেষভাবে তারিখ ও অপস মন্তব্য নোট: stackoverflow.com/questions/5596755/...
NotMe

উত্তর:


48

১০০ বা ৫০০ টি ডাটাবেস পরিচালনা করা 5 বা 10 পরিচালনার চেয়ে সব থেকে আলাদা নয় - আপনাকে কেবল অটোমেশনকে আলিঙ্গন করতে হবে এবং তার জায়গায় একটি স্কেলিবিলিটি পরিকল্পনা থাকতে হবে (এবং সমস্ত ক্ষেত্রে মিররিংয়ের মতো উচ্চ-ব্যয়-প্রতি-ডাটাবেস বৈশিষ্ট্যগুলি ব্যবহার করার পরিকল্পনা করবেন না) ক্লায়েন্ট)।

আমার আগের চাকরিতে আমরা এই আর্কিটেকচারটি ব্যবহার করেছিলাম এবং দু'টি ক্লায়েন্টকে একক ডাটাবেসে মার্জ করার কথা আমি কখনও ভাবিনি, যদিও কিছু চ্যালেঞ্জ "কঠিন" হতে পারে।

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

আমি এই পোস্টগুলিতে বেশ কয়েকটি আপত্তি এবং / অথবা সমস্যাগুলির কাছে কীভাবে সম্বোধন করব তা সম্বোধন করেছি:

এগুলি সমস্তই বলেছিল, আমি মনে করি না যে আমাদের মধ্যে কেউ আপনাকে সেই বিন্দুটি বলতে পারে যেটির জন্য পরিচালন আপনার পক্ষে অযৌক্তিক হয়ে ওঠে - কেবলমাত্র জেনে নিন যে আপনি যে নির্দিষ্ট চ্যালেঞ্জগুলি পারাপার করেন না কেন আপনি পৃথকভাবে সেই সমস্যাগুলি সম্পর্কে জিজ্ঞাসা করতে পারেন।


6
ধারাবাহিকভাবে প্রয়োগ করা আপনার একটি ভাল নামকরণের কনভেনশনও প্রয়োজন।
গ্রিনস্টোন ওয়াকার

ধন্যবাদ কিছু দুর্দান্ত লিঙ্ক। এটি আসলে কোনও ম্যানেজমেন্ট সমস্যা নয় (এই মুহুর্তে), আমি কেবল উদ্বিগ্ন বিষয়গুলি বন্ধ হয়ে যেতে পারে। তবে মনে হচ্ছে যে আমার এটি নিয়ে চিন্তা করা উচিত নয় এবং আমি নিশ্চিত করেছিলাম যে আমি এটি সব পরিচালনা করতে পারি। সূতরাং ধন্যবাদ!
নিবল্বিপিগ

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

15

আমি আপনাকে মাল্টি-টেন্যান্ট ডেটা আর্কিটেকচার পড়ার পরামর্শ দিচ্ছি , একটি সাদা কাগজ যা আপনার কাছে থাকা বিকল্পগুলি এবং উপকারিতা এবং কনসগুলি নিয়ে আলোচনা করে। সংক্ষিপ্তসার হিসাবে, এটি তিনটি বিকল্প দেয়:

  • পৃথক ডিবি
  • পৃথক স্কিমা
  • ভাগ করা স্কিমা

আপনি এখন পৃথক ডিবি পর্যায়ে আছেন, যা সেরা বিচ্ছেদ (ভাড়াটেদের মধ্যে বিচ্ছিন্নতা) দেয় তবে পরিচালনা করা সবচেয়ে কঠিন is আপনি শত শত ভাড়াটে হয়ে উঠলে আপনি বুঝতে পারবেন যে 100 এর দশকের ডিবি প্রশাসনের রসদ অপ্রয়োজনীয় from ব্যাকআপ-পুনরুদ্ধার (ব্যাকআপ করা ফাইল, কাজ, সময়সূচী ইত্যাদির অবস্থান) ভাবুন। কীভাবে আপনি শত শত ডিবি জুড়ে ফাইল বরাদ্দ, ডিস্ক স্পেস ব্যবহৃত এবং ডাটাবেস বৃদ্ধি পর্যবেক্ষণ ও পরিচালনা করবেন Think ভাবুন 1000 টেন্যান্ট সহ অদূর ভবিষ্যতে আপনার উচ্চ-প্রাপ্যতা / দুর্যোগ-পুনরুদ্ধারের দৃশ্যপটটি কী হবে? 1000 মিররড ডিবি, 1000 লগ শিপিং সেশন? কী ভাবেন যদি 6 মাসের মধ্যে আপনার দেব দলটি আপনার কাছে আসে এবং বলে "আমি জানি আমাদের পণ্যটিতে এই দুর্দান্ত বৈশিষ্ট্যটি কীভাবে দেওয়া হয়, আমরা লেনদেনের প্রতিরূপ ব্যবহার করব!", আপনি কী বলবেন? "অবশ্যই, আমাকে 500 জন প্রকাশক স্থাপন করতে দিন,"! কয়েকশো ডিবি পরিচালনা করা অসম্ভব না, তবে আপনি যদি পরিকল্পনা করে থাকেন তবে আপনি নিজের পাওয়ার শেল দক্ষতা ভালভাবে পোলিশ করুন এবং এই মুহুর্তে ইউআই পরিচালন সরঞ্জামগুলি ব্যবহার বন্ধ করুন ।

অতিরিক্ত হিসাবে আপনি বিবেচনা করতে হবে যে একাধিক (শত) ডিবি কর্মক্ষমতা এবং ব্যয় উপর পরিমাপযোগ্য প্রভাব আছে:

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

বিচ্ছিন্ন ডিবি কিছু সুবিধা নিয়ে আসে যদিও বিচ্ছিন্নতার কারণে, মূল সুবিধাটি স্বাধীন ব্যাকআপ / পুনরুদ্ধার।

আপনার মতো পরিস্থিতি এসকিউএল অ্যাজুরি ডাটাবেসের জন্য নিখুঁত প্রার্থী । ডিস্ক স্পেসের কোনও প্রশাসন, এইচএ / ডিআর সরবরাহ করার দরকার নেই, কয়েকশো / হাজার হাজার ডিবি বৃদ্ধি পাবে ইত্যাদি etc.


ধন্যবাদ এটি কিছু ভাল পরামর্শ, বিশেষত সম্ভবত একটি মেঘের মডেলটিতে স্যুইচ করা। আমি কীভাবে ব্যাক আপগুলি পরিচালনা করব সে সম্পর্কে আমাকে কিছু গুরুত্ব সহকারে চিন্তা করতে হবে।
নিবল্বিপিগ

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

2

আমার আগের চাকরিতে, আমরা প্রতি ক্লায়েন্টের জন্য কেবল একটি ডাটাবেস হোস্ট করেছিলাম না - বেশিরভাগ ক্ষেত্রে, এটি এর চেয়ে বেশি ছিল! আমি চলে যাবার সাথে সাথে একটি মারিয়াডিবি ক্লাস্টারে 4,500 এরও বেশি ডাটাবেস চলছিল, প্রায় 7,000 অপরটি (হাস্যকরভাবে ছোট) ক্লাস্টারে এবং 4 টি "শারড" (সম্পূর্ণ পৃথক, স্বতন্ত্র ওয়েব এবং ডাটাবেস সার্ভার এমনকি পুরো পৃথক ডেটা সেন্টারেও) প্রতিটি হোস্টিং ছিল একটি একক মাইএসকিউএল সার্ভারে 200-500 ডাটাবেস। এবং সেই সংস্থাটি এখনও একটি ভাল ক্লিপে বাড়ছে।

দীর্ঘ এবং সংক্ষিপ্তটি হ'ল সেই সংস্থার সাফল্য প্রমাণ করে যে এই জাতীয় আর্কিটেকচারটি সত্যই সম্ভাব্য। (সতর্কতা: পৃথক ডাটাবেস ব্যবহার করে বিচ্ছিন্নভাবে আপাত লাভের বিপরীতে, সমস্ত ডাটা একইভাবে ডাটাবেস ব্যবহারকারী / পাস ব্যবহার করে এমন শক্তভাবে সংযুক্ত অ্যাপ্লিকেশনগুলির একটি ত্রয়ীর মাধ্যমে অ্যাক্সেস করা হয়েছিল! আমি সন্দেহ করি যে প্রতিটি ক্লায়েন্ট যদি পারফরম্যান্সে কিছুটা সামান্য ক্ষতি করতে পারে একটি পৃথক ব্যবহারকারী / পাস ছিল - তবে কেবল সামান্য।)

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.