কোনও সুস্পষ্ট সমাধান নেই কারণ এটি পুরোপুরি আপনার প্রসঙ্গে নির্ভর করে - বিশেষত, আপনার সিস্টেমটি কোন মাত্রার সাথে স্কেল করার কথা বলেছে এবং আপনার আসল সমস্যাগুলি কী। ডাটাবেস কি আসলেই আপনার বাধা?
এই (দুর্ভাগ্যক্রমে বরং দীর্ঘতর) উত্তরটি কিছুটা পড়বে যেমন "মাইক্রোসার্ভিসেসগুলি খারাপ, জীবনের এককথায়!", তবে এটি আমার উদ্দেশ্য নয়। আমার বক্তব্যটি হ'ল মাইক্রোসার্ভেসিস এবং বিতরণ করা ডাটাবেসগুলি বিভিন্ন সমস্যার সমাধান করতে পারে তবে তাদের নিজস্ব কিছু সমস্যা ছাড়াই নয়। আপনার আর্কিটেকচারের জন্য দৃ to় যুক্তি তৈরি করার জন্য, আপনাকে অবশ্যই দেখাতে হবে যে এই সমস্যাগুলি প্রযোজ্য নয়, প্রশমিত হতে পারে এবং আপনার ব্যবসায়ের প্রয়োজনের জন্য এই আর্কিটেকচারটি সেরা পছন্দ।
বিতরণ করা ডেটা কঠিন।
আরও ভাল স্কেলিং সক্ষম করে এমন একই নমনীয়তা হ'ল দুর্বল গ্যারান্টিগুলির ফ্লিপ দিক। উল্লেখযোগ্যভাবে, বিতরণ সিস্টেমগুলি সম্পর্কে বিতর্ক করা অনেক কঠিন।
পারমাণবিক আপডেট, লেনদেন, ধারাবাহিকতা / রেফারেনশিয়াল অখণ্ডতা এবং স্থায়িত্ব অত্যন্ত মূল্যবান এবং খুব তাড়াতাড়ি ছাড় দেওয়া উচিত নয়। এটি অসম্পূর্ণ, পুরানো, অথবা একেবারে ভুল হলে ডেটা রাখার খুব একটা বিন্দু নেই। আপনার যখন ব্যবসায়ের প্রয়োজনীয়তা হিসাবে এসিডি থাকে তবে এটি এমন ডেটাবেস প্রযুক্তি ব্যবহার করে যা এটিকে বাক্সের বাইরে সরবরাহ করতে পারে না (উদাঃ অনেক নোএসকিউএল ডাটাবেস, বা একটি ডিবি-প্রতি-মাইক্রো সার্ভিস আর্কিটেকচার), তারপরে আপনার অ্যাপ্লিকেশনটিকে অবশ্যই শূন্যস্থান পূরণ করতে হবে এবং সেই নিশ্চয়তাগুলি সরবরাহ করতে হবে।
এটি করা অসম্ভব নয়, তবে সঠিক হওয়ার জন্য কৌশলটি জটিল। খুব কৌতুকময়। বিশেষত এমন একটি বিতরণ সেটিংয়ে যেখানে প্রতিটি ডাটাবেসে একাধিক লেখক থাকে। এই অসুবিধাটি সম্ভবত বাদ পড়া ডেটা, অসঙ্গতিযুক্ত ডেটা এবং আরও অনেকগুলি বাগের উচ্চ সম্ভাবনায় অনুবাদ করে।
উদাহরণস্বরূপ, জ্যাপসেন সুপরিচিত বিতরণকৃত ডাটাবেস সিস্টেমগুলির বিশ্লেষণগুলি পড়ার বিষয়ে বিবেচনা করুন , সম্ভবত ক্যাসান্দ্রার বিশ্লেষণ দিয়ে শুরু করুন । আমি এই বিশ্লেষণের অর্ধেকটি বুঝতে পারি না, তবে টিএল; ডিআর হ'ল বিতরণকারী সিস্টেমগুলি এতটাই কঠিন যে এমনকি শিল্প-শীর্ষস্থানীয় প্রকল্পগুলি কখনও কখনও সেগুলিকে ভুল করে দেয়, যেগুলি অন্ধকারে স্পষ্ট বলে মনে হয়।
বিতরণ সিস্টেমগুলি বৃহত্তর বিকাশের প্রচেষ্টা বোঝায়। একটি নির্দিষ্ট ডিগ্রীতে, বিকাশকারী হার্ডওয়্যারে বিকাশের ব্যয় বা অর্থ নেমে যাওয়ার মধ্যে সরাসরি বাণিজ্য বন্ধ রয়েছে।
উদাহরণ: ঝুলন্ত রেফারেন্স
অনুশীলনে, আপনার কম্পিউটার বিজ্ঞানের দিকে নজর দেওয়া উচিত নয় তবে এসিআইডি শিথিল করা যায় কিনা তা দেখার জন্য আপনার ব্যবসায়ের প্রয়োজনীয়তার দিকে নজর দেওয়া উচিত নয়। উদাহরণস্বরূপ অনেক বিদেশী-কী সম্পর্ক তাদের মনে হয় ততটা গুরুত্বপূর্ণ হতে পারে না। একটি পণ্য - বিভাগ এন: মি সম্পর্ক বিবেচনা করুন। আরডিবিএমএসে আমরা একটি বিদেশী-কী বাধা ব্যবহার করতে পারি যাতে কেবল বিদ্যমান পণ্য এবং বিদ্যমান বিভাগগুলিই সেই সম্পর্কের অংশ হতে পারে। যদি আমরা পৃথক পণ্য এবং বিভাগ পরিষেবাদি চালু করি এবং একটি পণ্য বা বিভাগ মুছে ফেলা হয় তবে কী হবে?
এই ক্ষেত্রে, এটি কোনও বড় সমস্যা নাও হতে পারে এবং আমরা আমাদের অ্যাপ্লিকেশনটি লিখতে পারি যাতে এটি এমন কোনও পণ্য বা বিভাগগুলিকে ফিল্টার করে যার অস্তিত্ব নেই। তবে ট্রেড অফস আছে!
নোট করুন যে এর জন্য JOINএকাধিক ডাটাবেস / মাইক্রোসার্ভেসিসের উপরে অ্যাপ্লিকেশন-স্তরের প্রয়োজন হতে পারে , যা কেবল আপনার অ্যাপ্লিকেশনটিতে ডাটাবেস সার্ভার থেকে প্রক্রিয়াকরণ সরিয়ে দেয়। এটি মোট বোঝা বাড়ে এবং নেটওয়ার্কের মাধ্যমে অতিরিক্ত ডেটা সরাতে হয়।
এটি পৃষ্ঠাবদ্ধতার সাথে জগাখিচুড়ি করতে পারে। যেমন আপনি কোনও বিভাগ থেকে পরবর্তী 25 পণ্যগুলির জন্য অনুরোধ করুন এবং সেই প্রতিক্রিয়া থেকে অনুপলব্ধ পণ্যগুলি ফিল্টার আউট করুন। এখন আপনার অ্যাপ্লিকেশন 23 পণ্য প্রদর্শন করে। তত্ত্ব অনুসারে, শূন্য পণ্য সহ একটি পৃষ্ঠাও সম্ভব হবে!
আপনি প্রতিটি প্রাসঙ্গিক পরিবর্তনের পরে বা নিয়মিত বিরতিতে ড্যাংলিং রেফারেন্সগুলি পরিষ্কার করে এমন স্ক্রিপ্টটি মাঝে মাঝে চালাতে চাইবেন। মনে রাখবেন যে এই ধরনের স্ক্রিপ্টগুলি মোটামুটি ব্যয়বহুল কারণ তাদের এখনও প্রতিটি পণ্য / বিভাগের ব্যাকিং ডাটাবেস / মাইক্রোসার্চিস থেকে অনুরোধ করতে হবে এটি এখনও বিদ্যমান কিনা তা দেখার জন্য।
এটি সুস্পষ্ট হওয়া উচিত, তবে স্পষ্টতার জন্য: আইডি পুনরায় ব্যবহার করবেন না। স্বতঃআগ্রহ-স্টাইল আইডিগুলি ভাল হতে পারে বা নাও পারে। জিইউইডি বা হ্যাশগুলি আপনাকে আরও নমনীয়তা দেয়, যেমন আইটেমটি কোনও ডাটাবেসে প্রবেশের আগে আইডি নির্ধারণ করতে সক্ষম হয়ে।
উদাহরণ: সমবর্তী আদেশগুলি
পরিবর্তে এখন পণ্য - অর্ডার সম্পর্ক বিবেচনা করুন। কোনও পণ্য মুছে ফেলা বা পরিবর্তিত হলে কোনও অর্ডারের কী হবে? ঠিক আছে, আমরা সহজভাবে প্রাসঙ্গিক পণ্য ডেটা উপলব্ধ রাখতে অর্ডার এন্টিতে অনুলিপি করতে পারি - সরলতার জন্য ট্রেডিং ডিস্কের স্থান। তবে কী যদি পণ্যের দাম পরিবর্তিত হয় বা পণ্যটি কোনও পণ্য অর্ডার দেওয়ার ঠিক আগে পাওয়া যায় না? বিতরণ ব্যবস্থায়, প্রভাবগুলি প্রচার করতে সময় নেয় এবং আদেশটি সম্ভবত পুরানো ডেটা দিয়ে যাবে।
আবার, কীভাবে এটি পৌঁছানো যায় তা আপনার ব্যবসায়ের প্রয়োজনীয়তার উপর নির্ভর করে। সম্ভবত পুরানো অর্ডার গ্রহণযোগ্য এবং আপনি যদি পরে আদেশটি পূরণ না করে তবে এটি বাতিল করতে পারেন।
তবে সম্ভবত এটি কোনও বিকল্প নয়, উদাহরণস্বরূপ অত্যন্ত সামঞ্জস্যপূর্ণ সেটিংসের জন্য। প্রথম 10 সেকেন্ডের মধ্যে কনসার্টের টিকিট কিনতে ছুটে আসা 3000 লোক বিবেচনা করুন এবং ধরে নেওয়া যাক প্রাপ্যতার পরিবর্তনের জন্য প্রচার করতে 10 মিমি প্রয়োজন হবে। একাধিক লোকের কাছে শেষ টিকিট বিক্রির সম্ভাবনা কত? এই সংঘর্ষগুলি কীভাবে পরিচালনা করা হয় তার উপর নির্ভর করে, তবে একটি পোইসন বিতরণ ব্যবহার করে λ = 3000 / (10s / 10ms) = 3আমরা P(k > 1) = 1 - P(k = 0) - P(k = 1) = 80%10 মিটার বিরতিতে সংঘর্ষের সুযোগ পাই । আপনার অর্ডারগুলির বেশিরভাগ বিক্রয় এবং পরে বাতিল করা প্রতারণা না করেই সম্ভব কিনা তা আপনার আইনি বিভাগের সাথে একটি আকর্ষণীয় কথোপকথনের কারণ হতে পারে।
বাস্তববাদ মানে চেরি-সেরা বৈশিষ্ট্যগুলি বাছাই।
সুসংবাদটি হ'ল আপনাকে বিতরণ করা ডাটাবেস মডেলটিতে যেতে হবে না, যদি অন্যথায় এটির প্রয়োজন না হয়। আপনি যদি মাইক্রোসার্ভিসেসগুলি "সঠিকভাবে" না করেন তবে কেউ আপনার মাইক্রোসার্চিস ক্লাবের সদস্যপদ প্রত্যাহার করবে না, কারণ এরকম কোনও ক্লাব নেই - এবং মাইক্রোসার্চেসগুলি তৈরির সত্যিকারের কোনও উপায় নেই।
বাস্তববাদ প্রতিবারই জিততে পারে, তাই আপনার সমস্যাটি সমাধান করার সাথে সাথে বিভিন্ন পদ্ধতির সাথে মেশান এবং মেলাও। এটি এমনকি কেন্দ্রীয়ীকৃত ডেটাবেসযুক্ত মাইক্রোসার্ভেসিকে বোঝাতে পারে। সত্যিই, বিতরণ করা ডাটাবেসের ব্যথাটি অতিক্রম করবেন না যদি আপনার না হয়।
আপনি মাইক্রোসার্ভিসেস ছাড়াই স্কেল করতে পারেন।
মাইক্রোসার্ভেসিসের দুটি প্রধান সুবিধা রয়েছে:
- সাংগঠনিক সুবিধা যা তাদের আলাদা দল দ্বারা স্বতন্ত্রভাবে বিকাশ ও মোতায়েন করা যায় (যার পরিবর্তে পরিষেবাগুলি স্থিতিশীল ইন্টারফেস দেওয়ার প্রয়োজন হয়)।
- অপারেশনাল বেনিফিট যা প্রতিটি মাইক্রোসার্ভিস স্বাধীনভাবে মাপা যায় ।
যদি স্বাধীন স্কেলিংয়ের প্রয়োজন হয় না, মাইক্রোসার্ভেসিসগুলি অনেক কম আকর্ষণীয়।
একটি ডাটাবেস সার্ভার ইতিমধ্যে এক ধরণের পরিষেবা যা আপনি স্বতন্ত্রভাবে (কিছুটা) স্কেল করতে পারবেন, যেমন পড়ার প্রতিরূপ যুক্ত করে। আপনি সঞ্চিত পদ্ধতি উল্লেখ করেন। এগুলি হ্রাস করার ফলে এত বড় প্রভাব থাকতে পারে যে অন্য কোনও স্কেলাবিলিটি আলোচনা মোটা হয়ে গেছে।
এবং কোনও স্কেলেবল মনোলিথ থাকা পুরোপুরি সম্ভব যার মধ্যে সমস্ত পরিষেবা লাইব্রেরি হিসাবে অন্তর্ভুক্ত রয়েছে। এরপরে আপনি একঘেয়েমিটির আরও কয়েকটি উদাহরণ চালু করে স্কেল করতে পারেন, যা অবশ্যই প্রতিটি উদাহরণকে রাষ্ট্রহীন হতে হবে।
একচেটিয়া যুক্তিসঙ্গতভাবে মোতায়েনের জন্য খুব বড় না হওয়া পর্যন্ত এটি ভাল কাজ করতে ঝোঁক পড়েছে বা কিছু পরিষেবাদির যদি বিশেষ সংস্থান প্রয়োজন হয় যাতে আপনি সেগুলি স্বাধীনভাবে স্কেল করতে চাইতে পারেন। অতিরিক্ত সংস্থানগুলিতে জড়িত সমস্যা ডোমেনগুলিতে একটি পৃথক ডেটা মডেল না জড়িত।
আপনার কি শক্ত ব্যবসায়ের মামলা আছে?
আপনি আপনার প্রতিষ্ঠানের ব্যবসায়ের প্রয়োজনীয়তা সম্পর্কে অবগত আছেন এবং তাই বিশ্লেষণের ভিত্তিতে প্রতি মাইক্রো সার্ভিসেস আর্কিটেকচারের জন্য একটি যুক্তি তৈরি করতে পারেন:
- যে একটি নির্দিষ্ট স্কেল প্রয়োজন, এবং এই আর্কিটেকচার হল এই স্কেলিবিলিটিটি অর্জনের জন্য সর্বাধিক ব্যয়বহুল পদ্ধতি, এমন একটি সেটআপ এবং বিকল্প সমাধানের জন্য বর্ধিত বিকাশের প্রচেষ্টা বিবেচনা করে; এবং
- আপনার ব্যবসায়ের প্রয়োজনীয়তাগুলি উপরে বর্ণিত সমস্যাগুলির মতো বিভিন্ন সমস্যার মুখোমুখি না হয়ে প্রাসঙ্গিক এসিডি গ্যারান্টি শিথিল করার অনুমতি দেয়।
বিপরীতভাবে, আপনি যদি এটি প্রদর্শন করতে অক্ষম হন, বিশেষত যদি বর্তমান ডাটাবেস ডিজাইন ভবিষ্যতে পর্যাপ্ত পরিমাণকে সমর্থন করতে সক্ষম হয় (যেমনটি আপনার সহকর্মীরা বিশ্বাস করে বলে মনে করেন), তবে আপনার উত্তরও রয়েছে।
স্কেলিবিলিটির জন্য একটি বড় YAGNI উপাদান রয়েছে। অনিশ্চয়তার মুখোমুখি হয়ে ওঠার জন্য, এটি এখন স্কেলিবিলিটির জন্য বিল্ডিংয়ের কৌশলগত ব্যবসায়িক সিদ্ধান্ত (মোট মোট ব্যয় কম, তবে সুযোগ ব্যয় জড়িত এবং প্রয়োজন হতে পারে না) স্কেলাবিলিটি সম্পর্কিত কিছু কাজ পিছিয়ে দেওয়া (প্রয়োজনে উচ্চতর মোট ব্যয়, তবে আপনার আরও ভাল আছে) প্রকৃত স্কেল ধারণা)। এটি প্রাথমিকভাবে কোনও প্রযুক্তিগত সিদ্ধান্ত নয়।