একটি সংযোগ-সীমা সংহত ডাটাবেস উচ্চ-ফ্রিকোয়েন্সি ঘটনা সংরক্ষণ

আমরা এমন একটি পরিস্থিতি পেয়েছি যেখানে আমাদের সার্ভারে আসা ঘটনাগুলির ব্যাপক প্রবাহের সাথে মোকাবিলা করতে হবে, প্রতি সেকেন্ডে প্রায় 1000 ইভেন্টে গড় (সর্বোচ্চ ~ 2000 হতে পারে)।

সমস্যাটি

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

ঘটনাবলী ডিবি সংযোগ পুল হ্যান্ডেল করতে পারে তার চেয়ে দ্রুত আসে

সমস্যাটি we have is that events come faster than the connection pool can handle. By the time one connection has finished the network roundtrip from the server to the DB, so it can get released back to the pool, more than n additional events come in.

অবশেষে ইভেন্টগুলি স্ট্যাক হয়ে যায়, সংরক্ষণের জন্য অপেক্ষা করা হয় এবং পুলটিতে কোনও সংযোগ নেই কারণ তারা সময় শেষ হয়ে যায় এবং সমগ্র সিস্টেমটি অ-কার্যকরী হয়।

আমরা ক্লায়েন্টদের কাছ থেকে ধীরে ধীর গতিতে আপত্তিকর উচ্চ-ফ্রিকোয়েন্সি ইভেন্টগুলি নির্মূল করে জরুরী সমাধান করেছি, তবে এই উচ্চ পরিস্থিতিতে ফ্রিকোয়েন্সি ইভেন্ট পরিচালনা করার ক্ষেত্রে আমাদের এই পরিস্থিতিতে কীভাবে পরিচালনা করা যায় তা আমরা জানতে চাই।

সীমাবদ্ধতাসমূহ

অন্যান্য ক্লায়েন্ট সমানভাবে ঘটনা পড়তে চান

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

একটি ক্লায়েন্ট এপিআই/ভি 1/ইভেন্টগুলি পেতে পারেন? ক্লায়েন্ট আইডি = 1 এবং ক্লায়েন্ট 1 দ্বারা প্রেরিত সমস্ত ইভেন্ট পেতে পারেন, এমনকি যদি সেই ইভেন্টগুলি এখনও ডিবিতে সংরক্ষণ করা না হয়।

কিভাবে এই সঙ্গে মোকাবেলা করতে কোন "শ্রেণীকক্ষ" উদাহরণ আছে?

সম্ভাব্য সমাধান

আমাদের সার্ভারে ইভেন্ট এনকুয়েশন

আমরা সার্ভারে ইভেন্টগুলি সারিবদ্ধ করতে পারি (সারির সাথে 400 এর সর্বাধিক সমানতা থাকা সত্ত্বেও সংযোগ পুলটি চালানো হয় না)।

এটি খারাপ ধারণা কারণ:

  • এটি উপলব্ধ সার্ভার মেমরি খাওয়া হবে। স্ট্যাকড-আপ রিকভারি ইভেন্টগুলি প্রচুর পরিমাণে RAM ব্যবহার করবে।
  • আমাদের সার্ভার প্রতি 24 ঘন্টা একবার পুনরায় চালু করুন । এটি একটি হার্ড সীমা হেরোকু দ্বারা আরোপিত। ইভেন্টগুলি যখন রুপান্তরিত ইভেন্টগুলি হারাতে পারে তখন সার্ভারটি পুনঃসূচনা করতে পারে।
  • এটি সার্ভারে রাষ্ট্র উপস্থাপিত করে, এইভাবে স্কেলেবিলিটি ক্ষতি করে। যদি আমাদের একটি মাল্টি-সার্ভার সেটআপ থাকে এবং একটি ক্লায়েন্ট সমস্ত রক্ষিত + সংরক্ষিত ইভেন্টগুলি পড়তে চায় তবে আমরা জানি না যে কোন সার্ভারটি সংরক্ষিত ইভেন্টগুলি লাইভ।

একটি পৃথক বার্তা সারি ব্যবহার করুন

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

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

একাধিক ডাটাবেস ব্যবহার করুন, প্রতিটি তাদের পরিচালনা করার জন্য একটি কেন্দ্রীয় ডিবি-সমন্বয়কারী সার্ভারের মাধ্যমে বার্তাগুলির একটি অংশ সংরক্ষণ করে

যদিও আমরা আরেকটি সমাধান একটি কেন্দ্রীয় "ডিবি সমন্বয়কারী/লোড balancer" সঙ্গে একাধিক ডাটাবেস ব্যবহার করা হয়। এটি একটি ঘটনা গ্রহণ করার পরে এই সমন্বয়কারী বার্তাটি লিখতে ডেটাবেসে এক চয়ন করবে। এটি আমাদেরকে একাধিক হেরোকু ডেটাবেসগুলি ব্যবহার করার অনুমতি দেয় যাতে এইভাবে সংযোগের সীমাটি 500 x সংখ্যায় ডেটাবেসে আপ করা হয়।

একটি পঠিত প্রশ্নের উপর, এই সমন্বয়কারী প্রতিটি ডাটাবেসের কাছে SELECT প্রশ্নগুলি ইস্যু করতে পারে, সমস্ত ফলাফল মার্জ করে এবং পাঠ্য অনুরোধের জন্য ক্লায়েন্টকে তাদের পাঠাতে পারে।

এটি খারাপ ধারণা কারণ:

  • এই ধারণাটি শোনাচ্ছে ... আহমদ .. ওভার ইঞ্জিনিয়ারিং? পাশাপাশি পরিচালনা করতে একটি দুঃস্বপ্ন হতে হবে (ব্যাকআপ ইত্যাদি ..)। এটি নির্মাণ এবং বজায় রাখা জটিল এবং এটি একেবারে প্রয়োজনীয় না হওয়া পর্যন্ত এটি KISS লঙ্ঘনের মত শোনাচ্ছে।
  • এটি সামঞ্জস্য উত্সর্গ করে। একাধিক ডিবি এর লেনদেনগুলি যদি আমরা এই ধারণা দিয়ে যাই তবে কোনও ছাড় নেই।
12
কিছু উত্তর এটি অ্যাকাউন্টে নেয় তবে আমি জিজ্ঞাসা করব: আপনার ইভেন্টের 100% সঠিকভাবে ডাটাবেসের মধ্যে সন্নিবেশ করা হয়েছে কিনা তা অবশ্যই জরুরী, যদি তাই হয় তবে আপনার সার্ভারটি পুনরায় চালু হওয়ার সময় আপনি কীভাবে সমস্যাটি পরিচালনা করছেন?
যোগ লেখক Walfrat, উৎস
সুতরাং আপনি একটি 100% প্রাপ্যতা কিন্তু সিঙ্ক্রোনাস না চান। তারপরে আমার bet প্রথমে স্থানীয়ভাবে ঘটনাগুলি (পূর্ববর্তী: ফাইল) চালিয়ে যেতে হবে এবং নিয়মিত ফাইলগুলি রপ্তানি করতে পারে (এটি প্রতি 30 সেকেন্ডে লকগুলি এড়াতে টিএম ফাইল রোলিং হতে পারে)। যেমন সিস্টেমের বুনিয়াদি আপনি একই সময়ে সবকিছু থাকতে পারে (কোন ক্ষতি, তাত্ক্ষণিক প্রক্রিয়া, কর্মক্ষমতা রাখা)। আপনার যা দরকার তা পেতে আপনাকে কী জানাতে হবে (উদাঃ সমকালীন, বা প্রকৃত 0% ক্ষতি)। তবে এটি আপনার সিস্টেমে প্রয়োজনীয়তার উপর নির্ভর করে যা আপনি তাদের সংশোধন করতে পারেন না।
যোগ লেখক Walfrat, উৎস
আপনি এই হার শিখর বা গড় কিনা সত্যিই স্পষ্ট করা উচিত। যদি এটি শীর্ষে থাকে, প্রতিদিনের সংখ্যা কত?
যোগ লেখক JimmyJames, উৎস
"আমরা ক্লায়েন্টদের কাছ থেকে ধীরে ধীর গতিতে আপত্তিকর উচ্চ ফ্রিকোয়েন্সি ইভেন্টগুলি নির্মূল করে জরুরী সমাধান করেছি, তবে এই উচ্চ পরিস্থিতিতে ফ্রিকোয়েন্সি ইভেন্টগুলি পরিচালনা করার ক্ষেত্রে আমাদের এই পরিস্থিতিতে কীভাবে পরিচালনা করা উচিত তা জানতে চাই।" আমি এই সমস্যা সমাধান কিভাবে নিশ্চিত নই। আপনি যদি বেশি পরিমাণে হ্যান্ডেল করতে পারছেন তবে ক্লায়েন্টকে ধীর করে দিবে না মানে যে তারা ক্রমাগত ইভেন্টগুলির গভীর ব্যাকলগ তৈরি করছে যা পরিচালনা করা দরকার?
যোগ লেখক JimmyJames, উৎস
কোথায় আপনার bottleneck হয়? আপনি আপনার সংযোগ পুল উল্লেখ করা হয়, কিন্তু যে সন্নিবেশ প্রতি গতি, না সমান্তরাল প্রভাব। যদি আপনার 500 সংযোগ থাকে এবং যেমন 2000QPS, প্রতিটি ক্যোয়ারী একটি দীর্ঘ সময় যা 250ms মধ্যে সম্পন্ন হলে এই জরিমানা কাজ করা উচিত। কেন যে 15ms উপরে? এছাড়াও একটি Paas ব্যবহার করে আপনি উল্লেখযোগ্য অপ্টিমাইজেশান সুযোগগুলি যেমন ডেটাবেস হার্ডওয়্যার স্কেলিং বা পাঠ্য-প্রতিলিপিগুলি ব্যবহার করে প্রাথমিক ডেটাবেসে লোড হ্রাস করার জন্য ছেড়ে দিচ্ছেন। স্থাপনা আপনার সবচেয়ে বড় সমস্যা না হওয়া পর্যন্ত হেরোকু এর মূল্য নেই।
যোগ লেখক amon, উৎস
@ নিকোলাস কাইরাকাইডস সঠিক হার্ডওয়্যার একটি মাইক্রো-অপ্টিমাইজেশান নয়। এটি ডাটাবেস স্কেল করার প্রাথমিক উপায়। একটি ডাটা সেন্টারের মধ্যে নেটওয়ার্ক বিলম্বিতা এখানে নগণ্য, <1 মি। একটি এন্টারপ্রাইজ-গ্রেড এসএসডি লেখার এছাড়াও <1ms। 1000 লেনদেনের জন্য আপনাকে কমপক্ষে 1 কে আইওপিএস প্রয়োজন হবে, যেমন। হার্ড ডিস্কগুলি সরবরাহ করতে পারে না, যদিও RAID-0 সাহায্য করতে পারে। একটি উপযুক্ত sysadmin সঠিকভাবে এই সব কনফিগার করতে সক্ষম হওয়া উচিত। এখনো আপনি সমস্যা দেখতে। আপনি একটি সফটওয়্যার কম্পোনেন্টে একটি দৈত্য কর্মক্ষমতা সমস্যা আছে (আপনি DB এর জন্য এটি বাতিল করেছেন) অথবা আপনার পাগুলি সত্যিই সত্যিই খারাপ। মেঘ কর্মক্ষমতা জন্য sucks।
যোগ লেখক amon, উৎস
নেটওয়ার্কে তাদের পাঠানোর আগে একটি অনুরোধে কিছু ইভেন্ট প্যাকিং একটি বিকল্প না? আমি প্রতিটি ক্লায়েন্টকে একক অনুরোধে প্রদত্ত সমস্ত সময়সীমার সমস্ত প্যাকগুলি "প্যাক" করে একটি একই সমস্যা সমাধান করেছি এবং তাদের প্রতি 10 ~ 15 সেকেন্ডে পাঠানো হয়। যদি এটি একটি বিকল্প হয়, আমাকে একটি পিং দিন এবং আমি একটি সম্পূর্ণ উত্তর প্রসারিত করব।
যোগ লেখক T. Sar, উৎস
সংযোগ পুলটি কি সমস্যাটি আপনি ঠিক কিভাবে যাচাই করেছেন? @ ইমন তার হিসাবের মধ্যে সঠিক। 500 সংযোগে নুল নির্বাচন করুন প্রদান করার চেষ্টা করুন। আমি bet আপনি সংযোগ পুল সেখানে সমস্যা হবে না।
যোগ লেখক user26009, উৎস
যদি নাল নির্বাচন সমস্যাযুক্ত হয় তাহলে আপনি সম্ভবত সঠিক। যদিও সব সময় ব্যয় করা হয় যেখানে এটি আকর্ষণীয় হবে। কোন নেটওয়ার্ক যে ধীর।
যোগ লেখক user26009, উৎস
@ এমন বোতলটি আসলেই সংযোগ পুল। আমি নিজেই প্রশ্নগুলিতে ANALYZE চালাচ্ছি এবং তারা কোন সমস্যা নয়। আমি সংযোগ পুল হাইপোথিসিস পরীক্ষা করার জন্য একটি প্রোটোটাইপ তৈরি করেছি এবং যাচাই করেছি যে এটি আসলেই সমস্যা। ডেটাবেস এবং সার্ভার নিজেই বিচ্ছিন্নতা বিভিন্ন মেশিনে থাকে। এছাড়াও, আমরা একেবারে প্রয়োজন না হওয়া পর্যন্ত হেরোকুকে ছেড়ে দিতে চাই না, স্থাপনার বিষয়ে চিন্তিত হওয়া আমাদের জন্য একটি বিশাল প্লাস নয়।
যোগ লেখক Nicholas Kyriakides, উৎস
... এই দৃশ্যটি আমাদের মনে করার কারণ সৃষ্টি করেছে যে আমরা যখন এই সময়ে আমাদের পথটি "থ্রোটেলের মাধ্যমে কাজ করতে পারি", তখন খুব শীঘ্রই আমরা তা করি না।
যোগ লেখক Nicholas Kyriakides, উৎস
@ জিম্মি জেমস <�কোড> ক্লায়েন্টকে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে চলবে না এমন ইভেন্টগুলির একটি গভীর ব্যাকলগ তৈরি করবে? । এই ক্ষেত্রে না। আমরা ক্লায়েন্টদের throttled যাতে তারা কম গতিতে যে ইভেন্ট পাঠায়। সেই ঘটনার জন্য আমরা যে গতিতে প্রেরিত তথ্যটি প্রয়োজন নই তবে এটি করা ভাল হবে। ঘটনা আমরা সবসময় তাদের আছে প্রয়োজন আছে। এই মুহূর্তে আমাদের কাছে যত বেশি ব্যবহারকারী নেই তাই প্রয়োজনীয় ইভেন্ট একই সমস্যা সৃষ্টি করবে, কিন্তু আমরা যা দেখি তার থেকে শীঘ্রই তা যথেষ্ট হবে। আমি আমার বর্তমান সমস্যার জন্য ঠিক সমাধান করছি না ...
যোগ লেখক Nicholas Kyriakides, উৎস
@ ওয়ালফাত আমরা এটা পরিচালনা করিনি। আমরা সাময়িকভাবে হ'ল ঘটনাগুলিকে একটি অস্থায়ী কর্মস্থল হিসাবে নির্গমন করা গতির গতি কমানো। এছাড়াও: আপনার ইভেন্টের 100% সঠিকভাবে ডাটাবেস এ সন্নিবেশ করা আবশ্যক। হ্যা এবং না; যদি কোন ক্লায়েন্ট সার্ভারে একটি ইভেন্ট পাঠায় তবে আমি নিশ্চিত করতে চাই যে এটি অন্য ক্লায়েন্টদের দ্বারা অবিলম্বে এবং ২3 বছর পরে পড়ার জন্য উপলব্ধ হবে। এটি অবিলম্বে ডাটাবেসের মধ্যে সন্নিবেশ করাতে হবে না তবে প্রস্তাবিত সমাধানটি বিশেষত দোষ-সহনশীল হবে।
যোগ লেখক Nicholas Kyriakides, উৎস
@ জিমি জেমস এই প্রশ্নটি সম্পাদনা করেছেন, এটি গড়।
যোগ লেখক Nicholas Kyriakides, উৎস
@usr আমার পরীক্ষা জোতা 50 সংযোগে চালানো হয়েছে, 500 নয়। আমি নির্বাচন করুন চালানো করেছি এবং এটি এখনও সমস্যাযুক্ত। এছাড়াও আমি প্রশ্নগুলিতে ANALYZE চালাচ্ছি এবং তাদের সময়গুলি সূক্ষ্ম মনে হচ্ছে। যদিও আমার প্রশ্নের ধারণা এখনও দাঁড়িয়ে আছে, তবে আমি আরো সঠিক তথ্য দিয়ে এটি আপডেট করব। আমি যে তারের জুড়ে পাঠানো প্রশ্নের আকার যোগ করতে ভুলে গেছি, যা বেশ বড় (~ 5 কেবিবাইট গড়)
যোগ লেখক Nicholas Kyriakides, উৎস
বলা হচ্ছে, আমি বুঝতে পারি যে মাইক্রো-অপ্টিমাইজেশানগুলি আমি করতে পারি যা আমাকে বর্তমান সমস্যা সমাধানে সহায়তা করবে। আমার সমস্যাটির একটি স্কেলেবল স্থাপত্য সমাধান আছে কিনা আমি ভাবছি।
যোগ লেখক Nicholas Kyriakides, উৎস
সাধারণ নির্দেশিকা হিসাবে, আমি বলব: আপনি যে প্রযুক্তি ব্যবহার করছেন তার সীমাতে পৌঁছেছেন, আপনাকে অন্য প্রযুক্তিতে স্যুইচিং শুরু করতে হবে।
যোগ লেখক Dominique, উৎস

6 উত্তর

আমার অনুমান আপনি প্রত্যাখ্যান করেছেন যে একটি পদ্ধতির আরো সাবধানে অন্বেষণ করার প্রয়োজন হয়

  • আমাদের সার্ভারে ইভেন্টগুলি সন্নিবেশ করান

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

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

ঘটনাগুলি যখন রুপান্তরিত হয় তখন সার্ভারটি পুনরায় চালু হতে পারে

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

  • একাধিক ডেটাবেস ব্যবহার করুন, প্রতিটি তাদের পরিচালনা করার জন্য কেন্দ্রীয় ডিবি-সমন্বয়কারী সার্ভারের সাথে বার্তাগুলির একটি অংশ সংরক্ষণ করে

হতে পারে - ডেটা শাওয়ার করার জন্য প্রাকৃতিক জায়গা আছে কিনা তা দেখার জন্য আপনার ব্যবসার সীমার দিকে তাকানোর সম্ভাবনা বেশি।

এমন তথ্য আছে যেখানে ডেটা হারানো একটি গ্রহণযোগ্য ট্রেডফো?

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

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

See Reliable Messaging Without Distributed Transactions, by Udi Dahan (already referenced by Andy) and Polyglot Data by Greg Young.

11
যোগ
একটি বিতরিত সিস্টেমে, আমার মনে হয় আপনি খুব নিশ্চিত হতে পারেন যে বার্তাগুলি হারিয়ে যাচ্ছে । সত্যি? তথ্য হারিয়ে যেখানে একটি গ্রহণযোগ্য tradeoff আছে? আমি ছাপ অধীন ছিল যে তথ্য = ব্যর্থতা হারানো।
যোগ লেখক Nicholas Kyriakides, উৎস
@ নিকোলাস কাইরাকাইডস, এটি সাধারণত গ্রহণযোগ্য নয়, তাই OP এ ইভেন্টটি উত্থাপন করার আগে টেকসই স্টোরে লিখার সম্ভাবনা প্রস্তাব করে। এই নিবন্ধটি এবং এই ভিডিওটি উডি দাহান দ্বারা যেখানে তিনি আরো বিস্তারিতভাবে সমস্যাটির সমাধান করেন।
যোগ লেখক Andy, উৎস

ইনপুট স্ট্রিম

আপনার 1000 ইভেন্ট/সেকেন্ডের শিখরগুলি বা যদি এটি ক্রমাগত লোড হয় তবে এটি স্পষ্ট নয়:

  • এটি শীর্ষে থাকলে ডিবি সার্ভারের লোডটি দীর্ঘ সময়ের জন্য লোড ছড়িয়ে দেওয়ার জন্য আপনি একটি বার্তা সার ব্যবহার করতে পারেন; করুন
  • এটি যদি ধ্রুবক লোড হয়, তবে কেবলমাত্র বার্তাটি সারি যথেষ্ট নয়, কারণ ডিবি সার্ভার কখনও ধরতে পারবে না। তারপর আপনি একটি বিতরণ ডাটাবেস সম্পর্কে চিন্তা করতে হবে। করুন

প্রস্তাবিত সমাধান

স্বতঃস্ফূর্তভাবে, উভয় ক্ষেত্রে আমি একটি কাফকা ভিত্তিক ইভেন্টের জন্য যেতে চাই- জীবন্ত চ্যাট রুম:

  • All events are systematically published on a kafka topic
  • A consumer would subscribe to the events and store them to the database.
  • A query processor will handle the requests from the clients and query the DB.

এটি সব স্তরে অত্যন্ত মাপযোগ্য:

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

ক্লায়েন্টদের ডিবিতে এখনো লেখা নেই এমন ইভেন্টগুলি প্রদান করা

আপনি আপনার ক্লায়েন্টদের এখনও পাইপ তথ্য অ্যাক্সেস পেতে সক্ষম হতে চান এবং এখনো ডিবি লিখিত না। এটি একটু বেশি সূক্ষ্ম।

বিকল্প 1: ডিবি প্রশ্নের পরিপূরক একটি ক্যাশে ব্যবহার করে

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

নকশা তারপর দেখতে হবে:

enter image description here

এই প্রশ্নের স্তরটির স্কেলেবিলিটি আরও ক্যোয়ারী প্রসেসর যুক্ত করে অর্জন করা যেতে পারে (প্রতিটি নিজস্ব গ্রাহক গোষ্ঠীতে)।

বিকল্প 2: একটি দ্বৈত API ডিজাইন

একটি ভাল পদ্ধতি IMHO একটি দ্বৈত API প্রদান করবে (পৃথক ভোক্তা গোষ্ঠীর প্রক্রিয়াটি ব্যবহার করুন):

  • ডিবি এবং/অথবা বিশ্লেষণ তৈরি করার জন্য
  • ইভেন্টগুলির অ্যাক্সেসের জন্য একটি ক্যোয়ারী API
  • একটি স্ট্রিমিং API যা সরাসরি বার্তা থেকে সরাসরি বার্তাগুলিকে এগিয়ে দেয়

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

ভেরিয়েন্ট

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

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

8
যোগ
@ নিকোলাসকাইরিকাইডস আমি ব্যাখ্যা করেছি " অন্য ক্লায়েন্টরা নির্দিষ্ট কী দিয়ে সমস্ত ইভেন্ট পড়তে অনুরোধ করে, এমনকি যদি তারা এখনও DB এ সংরক্ষিত না হয় > "ডিবি প্রশ্ন (" সব ") তৈরি করতে এবং এটি ইনকামিং ইভেন্টগুলির সাথে একত্রিত করতে (এখানে ইনপুট থেকে সরাসরি" ক্যাশে "পরিচালিত হয়), ডাবলসকে বাদ দিয়ে। যদি "সমস্ত" আপনি কেবল "সব নতুন" বোঝাতে চান তবে আমরা সহজ করতে পারি: কোন ক্যাশে, কোন মার্জ নেই এবং ডিবি থেকে পড়তে বা নতুন ইভেন্টগুলি এগিয়ে যেতে পারেন
যোগ লেখক Christophe, উৎস
হ্যাঁ। আমার প্রথম চিন্তাভাবনাটি র্যান্ডম বিতরণের জন্য যেতে হবে না কারণ এটি প্রশ্নগুলির জন্য প্রক্রিয়াকরণ লোড বৃদ্ধি করতে পারে (যেমন বেশীরভাগ সময়ে উভয়াধিক ডিবিগুলির ক্ষেত্রে)। আপনি বিতরণ ডিবি ইঞ্জিন বিবেচনা করতে পারে (উদাঃ উজ্জ্বল?)। তবে কোনও অবগত পছন্দের জন্য ডিবি ব্যবহারের নিদর্শনগুলির ভাল বোঝার প্রয়োজন হবে (ডিবিতে আর কী আছে, কতবার জিজ্ঞাসা করা হয়, কোন ধরনের প্রশ্ন থাকে, পৃথক ইভেন্টের বাইরে লেনদেনের সীমাবদ্ধতা থাকে ... ইত্যাদি)।
যোগ লেখক Christophe, উৎস
@ নিকোলাসকাইরাকিডিস ধন্যবাদ! 1) আমি কেবল কয়েকটি স্বাধীন ডাটাবেস সার্ভারের কথা চিন্তা করেছিলাম তবে একটি পরিষ্কার বিভাজন স্কিম (কী, ভূগোল, ইত্যাদি) দিয়ে যা কমান্ডগুলি কার্যকরভাবে প্রেরণ করতে ব্যবহার করা যেতে পারে। 2) স্বচ্ছভাবে , সম্ভবত কারণ কাফকা খুব উচ্চ থ্রুপুট ক্রমাগত বার্তা সহ আপনার সার্ভারগুলিকে পুনরায় চালু করতে হবে?)। আমি নিশ্চিত যে RabbitMQ বিতরণ পরিস্থিতিতে জন্য নমনীয় নয়, এবং ক্রমাগত সারি কর্মক্ষমতা হ্রাস করুন </একটি>
যোগ লেখক Christophe, উৎস
নাক্ষত্রিক; একটি বিতরিত ডাটাবেস (উদাহরণস্বরূপ, কীগুলির গোষ্ঠী দ্বারা সার্ভারের বিশেষত্ব ব্যবহার করে) দ্বারা আপনি কী বোঝাতে চান? কেন রেফিট এমকিউ এর বদলে কাফকা? অন্য একটি উপর নির্বাচন করার জন্য একটি নির্দিষ্ট কারণ আছে?
যোগ লেখক Nicholas Kyriakides, উৎস
1 এর জন্য) সুতরাং এটি আমার <�কোড> একাধিক ডেটাবেসগুলি ধারণাটির মতোই অনুরূপ তবে আপনি বলছেন যে আমি কেবলমাত্র এলোমেলোভাবে (বা রাউন্ড-রবিন) ডেটাবেসের প্রতিটিতে বার্তা বিতরণ করি না। রাইট?
যোগ লেখক Nicholas Kyriakides, উৎস
আমি বিস্মিত, কেন স্থানীয় ক্যাশে সব প্রয়োজন? একাধিক ডাটাবেস/লেখক ব্যবহার করার পুরো ধারণা তাই ঘটনাগুলি তাত্ক্ষণিকভাবে সংরক্ষণ করা হয় এবং প্রায় একটি ব্যাকলগ হয় না। কেন শুধু ডিবি থেকে সরাসরি পড়া না?
যোগ লেখক Nicholas Kyriakides, উৎস
তারা এখনও DB তে সংরক্ষিত না থাকলেও। । আমি এখানে বোঝাতে চেয়েছি যে যদি কোনও সমাধান নির্বাচন করা হয় যেটি গ্রহণ করে তবে সেগুলি এখনও লিখিত না হওয়া ইভেন্টগুলির একটি ব্যাকলগ হতে চলেছে, তবে পাঠ্য-গ্রাহকরা ব্যাকলগ ইভেন্টগুলিও পেতে চান। মাল্টি-ডিবি ধারণাটি বেশিরভাগই কোন ব্যাকলগ মানে না (তত্ত্বের মধ্যে) = কখনও অসংরক্ষিত ডিবি ইভেন্ট = ক্যাশের জন্য কোন প্রয়োজন নেই।
যোগ লেখক Nicholas Kyriakides, উৎস
শুধু বলতে চাও যে কাফকা খুব উচ্চ থ্রুপুট দিতে পারে, তবে সম্ভবত এটি সর্বাধিক মানুষের প্রয়োজনের বাইরে। আমি দেখেছি যে কাফকা এবং তার এপিআইয়ের সাথে ডিল করা আমাদের জন্য একটি বড় ভুল ছিল। RabbitMQ কোন slouch এবং এটি একটি MQ থেকে আপনি আশা করতে হবে যে ইন্টারফেস আছে
যোগ লেখক Ankit, উৎস

যদি আমি সঠিকভাবে বুঝতে পারি বর্তমান প্রবাহটি হল:

  1. গ্রহণ এবং ইভেন্ট (আমি HTTP এর মাধ্যমে অনুমান করি?)
  2. পুল থেকে একটি সংযোগের অনুরোধ করুন।
  3. ইভেন্টটিকে ডিবিতে ঢোকান
  4. পুলের সংযোগটি ছেড়ে দিন।

যদি তাই হয় তবে আমার মনে হয় ডিজাইনের প্রথম পরিবর্তনটি প্রতি ইভেন্টে পুল এমনকি আপনার কোডিং কোড রিটার্ন সংযোগগুলি বন্ধ করা বন্ধ করবে। এর পরিবর্তে ডিবি সংযোগগুলির সংখ্যা সহ 1-থেকে -1 নম্বর সন্নিবেশ থ্রেড/প্রক্রিয়াগুলির একটি পুল তৈরি করুন। এই প্রতিটি একটি ডেডিকেটেড ডিবি সংযোগ রাখা হবে।

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

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

6
যোগ

অনুমিতি

আমি অনুমান করতে যাচ্ছি আপনি যে লোডটি বর্ণনা করেছেন তা ধ্রুবক, কারণ এটি সমাধানের জন্য আরও কঠিন দৃশ্যকল্প।

আমি আপনাকে আপনার ওয়েব অ্যাপ্লিকেশন প্রক্রিয়া বাইরে ট্রিগার, দীর্ঘ চলমান workloads চলমান কিছু উপায় আছে অনুমান করতে যাচ্ছি।

সমাধান

Assuming that you have correctly identified your bottleneck - latency between your process and the Postgres database - that is the primary problem to solve for. The সমাধান needs to account for your consistency বাধ্যতা with other clients wanting to read the events as soon as practicable after they are received.

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

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

This SO answer describes the fastest way to flush data in Postgres - although it would require your batching store the queue on disk, and there is likely a problem to be solved there when your disk disappears upon reboot in Heroku.

বাধ্যতা

Another answer has already mentioned CQRS, and that is the correct approach to solve for the বাধ্যতা. You want to hydrate read models as each event is processed - a Mediator pattern can help encapsulate an event and distribute it to multiple handlers in-process. So one handler may add the event to your read model that is in-memory that clients can query, and another handler can be responsible for queuing the event for its eventual batched write.

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

5
যোগ

ডিবি সংযোগ পুল হ্যান্ডেল করতে পারার চেয়ে ইভেন্টগুলি দ্রুততর হয়

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

মেসেজের সারিটি সেই নকশাটির সাথে ব্যবহার করা যেতে পারে, আপনাকে বার্তা প্রযোজক (গুলি) যা বার্তা সারিতে ইভেন্টগুলিকে push করে এবং শ্রমিক (ভোক্তাদের) সারি থেকে বার্তাগুলি প্রক্রিয়া করতে হয়।

অন্যান্য ক্লায়েন্ট ঘটনাগুলি একযোগে পড়তে চাইতে পারে

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

ক্লায়েন্টরা কাঁচা ইভেন্ট অনুসন্ধান করতে চাইলে আমি ইলাস্টিক অনুসন্ধানের মত সার্চ ইঞ্জিন ব্যবহার করে পরামর্শ দেব। এমনকি আপনি বিনামূল্যে জন্য অনুসন্ধান/অনুসন্ধান API পাবেন।

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

স্কেলিং ইলাস্টিক অনুসন্ধান সহজ, কিন্তু এমনকি মৌলিক কনফিগারেশন সঙ্গে এটি বেশ উচ্চ পারফরম্যান্স।

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

3
যোগ

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

গুড লাক

1
যোগ