বার্তা সারি। ডেটাবেস বনাম ডেডিকেটেড এমকিউ


17

আমি বার্তা সন্ধানের বিষয়ে পরামর্শের পরে রয়েছি। আমাদের "চাকরিগুলি" একটি বার্তার কাতারে পোস্ট করার প্রয়োজনীয়তা রয়েছে।

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

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

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

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

আমি কোনও সমাধানে বিক্রি হয়নি, আমি ভাবছি কারও কাছে আমার কিছু বিবেচনা করা উচিত বা পরামর্শ দেওয়া উচিত কিনা।


1
এই 'চাকরিগুলি' কী 'আগুন এবং ভুলে যান' বা সার্ভারকে সেই কাজের স্থিতি জানাতে প্রক্রিয়াটি ঘরে ফিরতে হবে?
সি_মেকার

এটি কতটা স্কেলেবল হওয়া দরকার? আপনি কি এর মাধ্যমে দিনে কয়েক লক্ষ বার্তা চালিয়ে যাচ্ছেন বা কয়েক বিলিয়ন?
ব্লারফ্ল

মন্তব্যের জন্য ধন্যবাদ: কাজটি অসম্পূর্ণ হিসাবে চিহ্নিত করার প্রয়োজন রয়েছে (অসম্পূর্ণ / ব্যর্থ হিসাবে চিহ্নিত না হলে এগুলি সম্পূর্ণ হিসাবে বিবেচিত হবে)। আমি ভাবি যে দিনে 20,000 এর বেশি বার্তা নেই। সম্ভবত কয়েক হাজার।
ব্যবহারকারী1653400

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

এখানে কিছু ভাল পয়েন্টার রয়েছে: rusanu.com/2010/03/26/ using
মাইকেল গ্রিন

উত্তর:


18

আমি ইন্টারনেটে যা কিছু পড়েছি তা থেকে বোঝা যায় যে একটি বার্তা কাতারের জন্য একটি ডেটাবেস ব্যবহার করা কোনও স্কেলযোগ্য সমাধান নয়।

" এক্স ব্যবহার করবেন না কারণ এটি স্কেল করে না " দ্বারা বাস্তবতাটি প্রায়শই উপেক্ষা করা হয়েছে (লিঙ্কটিতে এমন কিছু ভাষা রয়েছে যার মধ্যে কিছু আপত্তিজনক হতে পারে) জনতা যে স্কেলটি সবসময় গুরুত্বপূর্ণ নয়। আমি এতদূর যেতে পেরেছি যে আপনি যদি গ্রহের মুখের প্রতিটি প্রয়োগকে সামগ্রিকভাবে দেখেন তবে স্কেল খুব কমই গুরুত্বপূর্ণ।

আপনার মন্তব্যে দৈনিক ২০,০০০ বার্তার হার উল্লেখ করা হয়েছে, যার অর্থ আপনি প্রতি সেকেন্ডে গড়ে 0.23 বার্তা (প্রতি 4.3 সেকেন্ডের মধ্যে একটি) রেট সমর্থন করার প্রয়োজনটি খুঁজছেন। যদি আপনার প্রকল্পটি প্রত্যাশার চেয়ে মাত্রার দুটি ক্রম হিসাবে সফল হয়, তবে আপনার প্রয়োজনীয়তাগুলি প্রতি সেকেন্ডে 23 টি বার্তা প্রক্রিয়াকরণে চলে যায়, এটি এমন একটি কাজ যা আমি আমার চার বছরের পুরানো মোবাইল ফোন বা রাস্পবেরি দিতে খুব স্বাচ্ছন্দ্য বোধ করি পাই। আপনি যদি উপরে শীর্ষে আরও কয়েক দশকের অর্ডার টেক করেন তবে এটি এখনও উচ্চ-স্কেল অ্যাপ্লিকেশন নয়।

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

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


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

@ ময়ূররথোদ topic বিষয়টি একটি পৃথক প্রশ্নের চরের মতো বলে মনে হচ্ছে। এটিকে সাবধানে কথা বলুন, কারণ নির্দিষ্ট সরঞ্জাম বা সংস্থানগুলির জন্য একটি অনুরোধ অফ-টপিক হিসাবে বন্ধ হয়ে যাবে।
blrfl

9

বার্তা সারিগুলি সত্যই তাদের নিজের মধ্যে আসে যখন আপনার অনেকগুলি থাকে এবং তাদের মধ্যে বার্তাগুলি রুট করে, একাধিক গ্রাহকের কাছে ফ্যানআউট ইত্যাদি etc.

আপনার যদি কেবল 'অফ লাইন' প্রসেস করতে চান এমন সামগ্রীর একক 'জব সারি' থাকে তবে একটি এসকিউএল টেবিল ঠিক ঠিক করবে।

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


5

অন্যান্য যেমন স্কেল উল্লেখ করেছেন এখানে সম্ভবত গুরুত্বপূর্ণ নয়। দুটি পৃথক স্টোরেজ মেকানিজম ব্যবহার করে সমস্যা হ'ল লেনদেনের স্বতন্ত্রতা।

যদি কোনও ডেডিকেটেড মেসেজ কাতারে যেতে হয় তবে ব্যর্থতার ক্ষেত্রে আপনাকে নিম্নলিখিতগুলির মধ্যে একটি চয়ন করতে হবে।

  1. সেই ডেটা এমবিতে থাকতে পারে তবে ডিবিতে নয়
  2. সেই ডেটা ডিবিতে থাকতে পারে তবে এমবিতে নয় All
  3. দুই পর্বের কমিট সেট করুন বা ডিবি এমকিউর মধ্যে বিতরণ লেনদেন যা জটিল হতে পারে

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


4

ব্যবহারিকতার জন্য, আমার বার্তার সারিটি ব্যবহারের প্রধান কারণগুলি হ'ল:

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

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


1

আমি একটি এমএসকিউএল বার্তা সারি সমাধান তৈরি করেছি যা প্রতি সেকেন্ডে 20 কে অপারেশন পরিচালনা করতে পারে এবং পারফরম্যান্স টেস্ট অনুযায়ী আমাদের 10 / সেকেন্ড বেশিরভাগ সময় প্রয়োজন। আমি মনে করি যে আপনি বাস্তবে অন্তর্নিহিত থাকতে পারেন এমন একটি বৈশিষ্ট্য যা উত্সর্গীকৃত বার্তাটির সারির অভাব রয়েছে। এবং এটি আমার ক্ষেত্রে একটি প্রধান প্রয়োজন ছিল।

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