ডাটাবেস কিউ হিসাবে এত খারাপ? [বন্ধ]


33

আমি কেবল এই নিবন্ধটি পড়েছি , এবং আমি বিভ্রান্ত হয়ে পড়েছি।

আসুন 1 ওয়েব্যাপ এবং 1 স্বতন্ত্র অ্যাপ্লিকেশনটি "কর্মী" হিসাবে অভিনয় করে উভয় একই ডাটাবেস ভাগ করে নেওয়ার কল্পনা করি ।

ওহ, আমি "ভাগ করে নেওয়ার" বলেছিলাম .. তবে নিবন্ধটি কী সম্পর্কে সতর্ক করে? :

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

=> একমত না কিছু ক্ষেত্রে রয়েছে যেখানে পৃথক অ্যাপ্লিকেশনগুলি এখনও একই ইউনিটের অংশ, এবং সুতরাং, "কাপলিং ইস্যু" ধারণাটি এই ক্ষেত্রে কোনও ধারণা রাখে না।

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

এই পয়েন্ট টি:

কর্মীদের কাছে ইভেন্টগুলির ডেটা কীভাবে প্রেরণ করা উচিত?

পঠিত নিবন্ধটি প্রচার করার সাথে সাথে প্রথম সমাধানটি হ'ল রাব্বিটএমকিউ ব্যবহার করা হবে, এটি একটি দুর্দান্ত বার্তা-ভিত্তিক মিডলওয়্যার।

কর্মপ্রবাহ সহজ হবে:

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

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

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

তবে ওয়েব অ্যাপের পাশাপাশি এবং উপায়ের জন্য অতিরিক্ত শিডিয়ুলারের প্রয়োজন কেন: এই ক্ষেত্রে রাব্বিটএমকিউয়ের প্রয়োজন কেন?

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

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

নিবন্ধের অংশ:

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

এবং তাত্ক্ষণিক ধারাবাহিকতা, উপেক্ষা?

সংক্ষেপে, এটি সত্যিই মনে হয় কেস যাই হোক না কেন, অর্থাত্ ডাটাবেস ভাগ করে নেওয়া বা না, আমাদের ডাটাবেস পোলিংয়ের দরকার ।

আমি কিছু সমালোচনামূলক ধারণা মিস করেছি?

ধন্যবাদ


2
পোলিং একটি লাল হেরিংয়ের ধরণ, কারণ প্রায় সমস্ত প্রধান ডাটাবেসে অবিচ্ছিন্নভাবে কিছু অন্যান্য প্রক্রিয়া অবহিত করার জন্য কিছু ব্যবস্থা থাকে যে সময়টি কোনও টেবিলের বাইরে টান দেওয়ার সময় এসেছে।
ব্ল্রফ্ল

উত্তর:


28

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

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

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

আরেকটি বিষয় বিবেচনা করার বিষয় হ'ল বেশিরভাগ কিউ সিস্টেমগুলি সাধারণত কোনও পোলিং কৌশল ব্যবহার করে না (কেউ কেউ এইচটিটিপিকে অনুমতি দেয় তবে গ্রহণকারী পক্ষের জন্য ব্যবহার এড়াতে পরামর্শ দেয়)। RabbitMq বিশেষভাবে যেমন বার্তা বাস জন্য ডিজাইন করা নেটওয়ার্ক প্রোটোকল ব্যবহার AMPQ

সম্পাদনা করুন: ব্যবহারের কেস যুক্ত করা হচ্ছে।

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


এই ক্ষেত্রে আপনি কীভাবে তাত্ক্ষণিকভাবে অবস্থান গ্রহণ করতে পারেন? যদি প্রকাশনাটি তৈরি করা হয় তবে ঠিক পরে, ডোমেন মডেল রোলব্যাকগুলি আপডেট করার জন্য দায়ী লেনদেন ... মিডওয়্যারটি সম্পূর্ণ অজানা এবং ইভেন্টটি প্রক্রিয়া করবে।
মিক 378

আপনি লিখেছেন: "এটি লক নিয়ে বিরক্ত করার প্রয়োজন নেই"। তবে রাউটেড ইভেন্টগুলির (কর্মীর দিকে) আরোহী আদেশ (সময়ের সাথে সাথে) নিশ্চিত করার জন্য অবশ্যই এক ধরণের লক রয়েছে, না?
মিক 378

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

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

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