এটি এর কাজের চাপ বিচ্ছিন্ন করার ক্ষমতাগুলির একটি গভীর ভূমিকা। কিন্তু প্রথমত, কেন এবং কখন আপনার কাজের চাপ বিচ্ছিন্নতা প্রয়োজন? আপনি যদি নিম্নলিখিত পরিস্থিতিগুলির সাথে সম্পর্কিত হন তবে পড়ুন এবং আপনি একটি সমাধান পাবেন: Apache Doris- আপনার বিভিন্ন ব্যবসায়িক বিভাগ বা ভাড়াটেরা একই ক্লাস্টার ভাগ করে নিয়েছে এবং আপনি কাজের চাপে হস্তক্ষেপ রোধ করতে চান। আপনার কাছে বিভিন্ন অগ্রাধিকার স্তরের ক্যোয়ারী কাজ রয়েছে এবং আপনি সম্পদ এবং সম্পাদনের ক্ষেত্রে আপনার গুরুত্বপূর্ণ কাজগুলিকে (যেমন রিয়েল-টাইম ডেটা বিশ্লেষণ এবং অনলাইন লেনদেন) অগ্রাধিকার দিতে চান। আপনার কাজের চাপের বিচ্ছিন্নতা প্রয়োজন তবে উচ্চ ব্যয়-কার্যকারিতা এবং সম্পদ ব্যবহারের হারও চাই। Apache Doris রিসোর্স ট্যাগ এবং ওয়ার্কলোড গ্রুপের উপর ভিত্তি করে কাজের চাপ বিচ্ছিন্নতা সমর্থন করে। রিসোর্স ট্যাগ ব্যাকএন্ড নোডের স্তরে বিভিন্ন ওয়ার্কলোডের জন্য CPU এবং মেমরি সংস্থানগুলিকে বিচ্ছিন্ন করে, যখন ওয়ার্কলোড গ্রুপ মেকানিজম উচ্চতর সম্পদ ব্যবহারের জন্য একটি ব্যাকএন্ড নোডের মধ্যে সংস্থানগুলিকে আরও বিভক্ত করতে পারে। https://www.youtube.com/watch?v=Wd3l5C4k8Ok&embedable=true রিসোর্স ট্যাগের উপর ভিত্তি করে রিসোর্স আইসোলেশন অ্যাপাচি ডরিসের স্থাপত্য দিয়ে শুরু করা যাক। ডরিসের দুটি রয়েছে: ফ্রন্টএন্ড (এফই) এবং ব্যাকএন্ড (বিই)। FE নোডগুলি মেটাডেটা সঞ্চয় করে, ক্লাস্টারগুলি পরিচালনা করে, ব্যবহারকারীর অনুরোধগুলি প্রক্রিয়া করে এবং ক্যোয়ারী প্ল্যানগুলি পার্স করে, যখন BE নোডগুলি গণনা এবং ডেটা স্টোরেজের জন্য দায়ী৷ সুতরাং, BE নোড হল প্রধান সম্পদ গ্রাহক। ধরণের নোড একটি রিসোর্স ট্যাগ-ভিত্তিক বিচ্ছিন্নতা সমাধানের মূল ধারণা হল একটি ক্লাস্টারে BE নোডগুলিতে ট্যাগগুলি বরাদ্দ করে কম্পিউটিং সংস্থানগুলিকে গ্রুপগুলিতে ভাগ করা, যেখানে একই ট্যাগের BE নোডগুলি একটি রিসোর্স গ্রুপ গঠন করে। একটি রিসোর্স গ্রুপকে ডেটা স্টোরেজ এবং গণনার জন্য একটি ইউনিট হিসাবে গণ্য করা যেতে পারে। ডরিসে ঢোকানো ডেটার জন্য, সিস্টেম কনফিগারেশন অনুযায়ী বিভিন্ন রিসোর্স গ্রুপে ডেটা প্রতিলিপি লিখবে। এক্সিকিউশনের জন্য তাদের সংশ্লিষ্ট প্রশ্নগুলি বরাদ্দ করা হবে। রিসোর্স গ্রুপগুলিতেও উদাহরণস্বরূপ, আপনি যদি একটি 3-BE ক্লাস্টারে পড়া এবং লেখার কাজের চাপ আলাদা করতে চান, আপনি এই পদক্ষেপগুলি অনুসরণ করতে পারেন: : "রিড" ট্যাগের সাথে 2টি BE এবং "লিখুন" ট্যাগের সাথে 1টি BE বাঁধুন৷ BE নোডগুলিতে রিসোর্স ট্যাগগুলি বরাদ্দ করুন : ধরে নিই যে টেবিল 1-এ 3টি প্রতিলিপি রয়েছে, তাদের মধ্যে 2টি "পড়ুন" ট্যাগের সাথে এবং 1টিকে "লিখুন" ট্যাগের সাথে আবদ্ধ করুন। রেপ্লিকা 3 তে লেখা ডেটা রেপ্লিকা 1 এবং রেপ্লিকা 2 এর সাথে সিঙ্ক্রোনাইজ করা হবে এবং ডেটা সিঙ্ক্রোনাইজেশন প্রক্রিয়া BE 1 এবং BE2 এর কিছু সংস্থান গ্রহণ করে। ডেটা প্রতিলিপিগুলিতে রিসোর্স ট্যাগগুলি বরাদ্দ করুন : যে প্রশ্নগুলি তাদের SQL এ "পড়ুন" ট্যাগ অন্তর্ভুক্ত করে সেগুলি স্বয়ংক্রিয়ভাবে "পড়ুন" ট্যাগ করা নোডগুলিতে রুট করা হবে (এই ক্ষেত্রে, BE 1 এবং BE 2)। ডেটা লেখার কাজগুলির জন্য, আপনাকে তাদের "লিখুন" ট্যাগ দিয়ে বরাদ্দ করতে হবে যাতে সেগুলি সংশ্লিষ্ট নোডে (BE 3) রাউট করা যায়। এইভাবে, রেপ্লিকা 3 থেকে রেপ্লিকা 1 এবং 2 পর্যন্ত ডেটা সিঙ্ক্রোনাইজেশন ওভারহেডগুলি ব্যতীত ওয়ার্কলোড পড়া এবং লেখার মধ্যে কোনও সংস্থান বিরোধ থাকবে না। রিসোর্স ট্যাগগুলিতে ওয়ার্কলোড গ্রুপগুলি বরাদ্দ করুন রিসোর্স ট্যাগ Apache Doris-এ সক্ষম করে। উদাহরণস্বরূপ, "ব্যবহারকারী A" এর সাথে ট্যাগ করা কম্পিউটিং এবং স্টোরেজ সংস্থানগুলি শুধুমাত্র ব্যবহারকারী A এর জন্য, যখন "ব্যবহারকারী B" এর সাথে ট্যাগ করা হয়েছে সেগুলি ব্যবহারকারী B এর জন্য একচেটিয়া। এভাবেই ডরিস BE পাশের রিসোর্স ট্যাগগুলির সাথে মাল্টি-টেন্যান্ট রিসোর্স আইসোলেশন প্রয়োগ করে . মাল্টি-টেনেন্সিও BE নোডগুলিকে গ্রুপে বিভক্ত করা নিশ্চিত করে: উচ্চ স্তরের বিচ্ছিন্নতা বিভিন্ন ভাড়াটেদের CPU, মেমরি এবং I/O শারীরিকভাবে বিচ্ছিন্ন। একজন ভাড়াটে অন্য ভাড়াটেদের ব্যর্থতা (যেমন প্রক্রিয়া ক্র্যাশ) দ্বারা প্রভাবিত হবে না। তবে এর কয়েকটি খারাপ দিক রয়েছে: রিড-রাইট সেপারেশনে, ডাটা লেখা বন্ধ হয়ে গেলে, "লিখুন" দিয়ে ট্যাগ করা BE নোডগুলি নিষ্ক্রিয় হয়ে যায়। এটি সামগ্রিক ক্লাস্টার ব্যবহার হ্রাস করে। মাল্টি-টেন্যান্সির অধীনে, আপনি যদি একই ভাড়াটেদের প্রত্যেকের জন্য আলাদা আলাদা BE নোড বরাদ্দ করে বিভিন্ন কাজের চাপকে আরও আলাদা করতে চান, তাহলে আপনাকে উল্লেখযোগ্য খরচ এবং কম সম্পদের ব্যবহার সহ্য করতে হবে। ভাড়াটেদের সংখ্যা ডেটা প্রতিলিপির সংখ্যার সাথে আবদ্ধ। সুতরাং, আপনার যদি 5 জন ভাড়াটে থাকে, আপনার 5টি ডেটা রেপ্লিকা প্রয়োজন হবে। যে বিশাল স্টোরেজ রিডানডেন্সি. এটির উন্নতি করতে, আমরা Apache Doris 2.0.0-এ Workload Group-এর উপর ভিত্তি করে একটি ওয়ার্কলোড আইসোলেশন সমাধান প্রদান করি এবং -এ এটিকে উন্নত করেছি। Apache Doris 2.1.0 ওয়ার্কলোড গ্রুপের উপর ভিত্তি করে ওয়ার্কলোড আইসোলেশন -ভিত্তিক সমাধান সম্পদের আরও দানাদার বিভাজন উপলব্ধি করে। এটি BE নোডের প্রক্রিয়াগুলির মধ্যে CPU এবং মেমরি সংস্থানগুলিকে আরও বিভক্ত করে, যার অর্থ একটি BE নোডের প্রশ্নগুলি একে অপরের থেকে কিছুটা আলাদা করা যেতে পারে। এটি BE প্রক্রিয়ার মধ্যে সম্পদ প্রতিযোগিতা এড়ায় এবং সম্পদের ব্যবহার অপ্টিমাইজ করে। ওয়ার্কলোড গ্রুপ ব্যবহারকারীরা ওয়ার্কলোড গ্রুপের সাথে প্রশ্নগুলিকে যুক্ত করতে পারে, এইভাবে একটি ক্যোয়ারী ব্যবহার করতে পারে এমন CPU এবং মেমরি সংস্থানগুলির শতাংশ সীমিত করে। উচ্চ ক্লাস্টার লোডের অধীনে, ডরিস স্বয়ংক্রিয়ভাবে একটি ওয়ার্কলোড গ্রুপে সর্বাধিক সম্পদ-ব্যবহারকারী প্রশ্নগুলিকে মেরে ফেলতে পারে। কম ক্লাস্টার লোডের অধীনে, ডরিস একাধিক ওয়ার্কলোড গ্রুপকে নিষ্ক্রিয় সম্পদ ভাগ করার অনুমতি দিতে পারে। ডরিস CPU সফট লিমিট এবং CPU হার্ড লিমিট উভয়কেই সমর্থন করে। নরম সীমা ওয়ার্কলোড গ্রুপগুলিকে সীমা ভঙ্গ করতে এবং নিষ্ক্রিয় সংস্থানগুলি ব্যবহার করতে দেয়, আরও দক্ষ ব্যবহার সক্ষম করে। হার্ড লিমিট স্থিতিশীল কর্মক্ষমতার একটি কঠিন গ্যারান্টি কারণ এটি ওয়ার্কলোড গ্রুপগুলির পারস্পরিক প্রভাবকে বাধা দেয়। (সিপিইউ সফ্ট লিমিট এবং সিপিইউ হার্ড লিমিট একে অপরের সাথে পরস্পরবিরোধী। আপনি আপনার নিজের ব্যবহারের ক্ষেত্রে তাদের মধ্যে বেছে নিতে পারেন।) রিসোর্স ট্যাগ-ভিত্তিক সমাধান থেকে এর পার্থক্যগুলির মধ্যে রয়েছে: কাজের চাপ গ্রুপ প্রক্রিয়ার মধ্যে গঠিত হয়. একাধিক ওয়ার্কলোড গ্রুপ একই BE নোডের মধ্যে সংস্থানগুলির জন্য প্রতিযোগিতা করে। ডেটা রেপ্লিকা ডিস্ট্রিবিউশনের বিবেচনা ছবির বাইরে কারণ ওয়ার্কলোড গ্রুপ শুধুমাত্র সম্পদ ব্যবস্থাপনার একটি উপায়। CPU নরম সীমা CPU সফট লিমিট প্যারামিটার দ্বারা প্রয়োগ করা হয়, যা ধারণাগতভাবে ওজনের অনুরূপ। উচ্চতর সহ ওয়ার্কলোড গ্রুপগুলিকে একটি টাইম স্লটের সময় বেশি CPU সময় বরাদ্দ করা হবে। cpu_share cpu_share উদাহরণস্বরূপ, যদি গ্রুপ A-কে 1 এবং গ্রুপ B-এর একটি দিয়ে কনফিগার করা হয়, 9. 10 সেকেন্ডের একটি টাইম স্লটে, যখন গ্রুপ A এবং গ্রুপ B উভয়ই সম্পূর্ণরূপে লোড হয়ে যায়, তখন গ্রুপ A এবং গ্রুপ B 1 সেকেন্ড ব্যবহার করতে সক্ষম হবে এবং যথাক্রমে CPU সময়ের 9s। cpu_share বাস্তব-বিশ্বের ক্ষেত্রে যা ঘটে তা হল ক্লাস্টারের সমস্ত কাজের চাপ পূর্ণ ক্ষমতায় চলে না। নরম সীমার অধীনে, যদি গ্রুপ B-এর কাজের চাপ কম বা শূন্য থাকে, তাহলে গ্রুপ A সমস্ত CPU সময় ব্যবহার করতে সক্ষম হবে, এইভাবে ক্লাস্টারে সামগ্রিক CPU ব্যবহার বৃদ্ধি পাবে। একটি নরম সীমা নমনীয়তা এবং একটি উচ্চ সম্পদ ব্যবহারের হার নিয়ে আসে। বিপরীত দিকে, এটি কর্মক্ষমতা ওঠানামা হতে পারে। CPU হার্ড লিমিট Apache Doris 2.1.0-এ CPU হার্ড লিমিট এমন ব্যবহারকারীদের জন্য ডিজাইন করা হয়েছে যাদের স্থিতিশীল কর্মক্ষমতা প্রয়োজন। সহজ ভাষায়, CPU হার্ড লিমিট সংজ্ঞায়িত করে যে একটি ওয়ার্কলোড গ্রুপ তার সীমার চেয়ে বেশি CPU রিসোর্স ব্যবহার করতে পারে না, সিপিইউ রিসোর্স নিষ্ক্রিয় থাকুক বা না থাকুক। এটা এভাবে কাজ করে: ধরুন যে গ্রুপ A সেট করা হয়েছে এবং গ্রুপ B-এর সাথে । যদি গ্রুপ A এবং গ্রুপ B উভয়ই সম্পূর্ণ লোডে চলে তবে গ্রুপ A এবং গ্রুপ B যথাক্রমে সামগ্রিক CPU সময়ের 10% এবং 90% ব্যবহার করবে। গ্রুপ B-এর কাজের চাপ কমে গেলে পার্থক্য থাকে। এই ধরনের ক্ষেত্রে, গ্রুপ A-এর ক্যোয়ারী লোড যতই বেশি হোক না কেন, এটিতে বরাদ্দকৃত 10% CPU সম্পদের বেশি ব্যবহার করা উচিত নয়। cpu_hard_limit=10% cpu_hard_limit=90% একটি নরম সীমার বিপরীতে, একটি হার্ড সীমা নমনীয়তার খরচে এবং উচ্চ সম্পদ ব্যবহারের হারের সম্ভাবনার জন্য স্থিতিশীল সিস্টেমের কার্যকারিতার গ্যারান্টি দেয়। মেমরি সম্পদ সীমা একটি BE নোডের মেমরি নিম্নলিখিত অংশগুলি নিয়ে গঠিত: অপারেটিং সিস্টেমের জন্য সংরক্ষিত মেমরি। মেমরি নন-কোয়েরি দ্বারা গ্রাস করা হয়, যা ওয়ার্কলোড গ্রুপের মেমরি পরিসংখ্যানে বিবেচনা করা হয় না। মেমরি ডেটা লেখা সহ প্রশ্নের দ্বারা গ্রাস করা হয়। এটি ওয়ার্কলোড গ্রুপ দ্বারা ট্র্যাক এবং নিয়ন্ত্রণ করা যেতে পারে। প্যারামিটারটি BE প্রক্রিয়ার মধ্যে একটি ওয়ার্কলোড গ্রুপের জন্য উপলব্ধ সর্বাধিক (%) মেমরি সংজ্ঞায়িত করে। এটি রিসোর্স গ্রুপের অগ্রাধিকারকেও প্রভাবিত করে। memory_limit প্রাথমিক অবস্থার অধীনে, একটি উচ্চ-অগ্রাধিকার সংস্থান গোষ্ঠীকে আরও মেমরি বরাদ্দ করা হবে। সেট করে, আপনি যখন নিষ্ক্রিয় স্থান থাকে তখন সীমার চেয়ে বেশি মেমরি দখল করতে রিসোর্স গ্রুপগুলিকে অনুমতি দিতে পারেন। যখন মেমরি শক্ত হয়, তখন ডরিস তাদের প্রতিশ্রুতিবদ্ধ মেমরি সংস্থানগুলি পুনরুদ্ধার করার জন্য কাজগুলি বাতিল করবে। এই ক্ষেত্রে, সিস্টেম উচ্চ-অগ্রাধিকার সংস্থান গোষ্ঠীগুলির জন্য যতটা সম্ভব মেমরির সম্পদ ধরে রাখবে। enable_memory_overcommit ক্যোয়ারী সারি এটা ঘটছে যে ক্লাস্টার এটি পরিচালনা করতে পারে তার চেয়ে বেশি লোড গ্রহণ করছে। এই ক্ষেত্রে, নতুন ক্যোয়ারী অনুরোধ জমা দেওয়া শুধুমাত্র নিষ্ফলই হবে না বরং প্রগতিশীল প্রশ্নগুলিতে বাধা সৃষ্টি করবে। এটির উন্নতি করতে, Apache Doris মেকানিজম প্রদান করে। ব্যবহারকারীরা ক্লাস্টারে একসাথে চলতে পারে এমন প্রশ্নের সংখ্যার একটি সীমাবদ্ধ করতে পারেন। একটি ক্যোয়ারী প্রত্যাখ্যান করা হবে যখন ক্যোয়ারী সারি পূর্ণ হয় বা অপেক্ষার সময় শেষ হওয়ার পরে, এইভাবে উচ্চ লোডের অধীনে সিস্টেমের স্থিতিশীলতা নিশ্চিত করা হয়। ক্যোয়ারী সারি ক্যোয়ারী সারি মেকানিজম তিনটি প্যারামিটার জড়িত: , , এবং । max_concurrency max_queue_size queue_timeout টেস্ট CPU নরম সীমা এবং হার্ড সীমার কার্যকারিতা প্রদর্শনের জন্য, আমরা কয়েকটি পরীক্ষা করেছি। পরিবেশ: একক মেশিন, 16 কোর, 64 জিবি স্থাপনা: 1 FE + 1 BE ডেটাসেট: ক্লিকবেঞ্চ, টিপিসি-এইচ লোড টেস্টিং টুল: Apache JMeter CPU নরম সীমা পরীক্ষা দুটি ক্লায়েন্ট শুরু করুন এবং যথাক্রমে ওয়ার্কলোড গ্রুপগুলি ব্যবহার না করে এবং ক্রমাগত প্রশ্ন জমা দিন (ক্লিকবেঞ্চ Q23)। মনে রাখবেন যে পৃষ্ঠা ক্যাশে পরীক্ষার ফলাফলগুলিকে প্রভাবিত করা থেকে বিরত রাখতে এটি নিষ্ক্রিয় করা উচিত। উভয় পরীক্ষায় দুটি ক্লায়েন্টের থ্রুপুট তুলনা করে, এটি উপসংহারে আসা যেতে পারে যে: , দুটি ক্লায়েন্ট সমান ভিত্তিতে CPU সংস্থানগুলি ব্যবহার করে। ওয়ার্কলোড গ্রুপগুলি কনফিগার না করে এবং 2:1 সেট করা, দুটি ক্লায়েন্টের থ্রুপুট অনুপাত হল 2:1। উচ্চতর এর সাথে, ক্লায়েন্ট 1-কে CPU সম্পদের উচ্চতর অংশ প্রদান করা হয় এবং এটি একটি উচ্চতর থ্রুপুট প্রদান করে। ওয়ার্কলোড গ্রুপ কনফিগার করা cpu_share cpu_share CPU হার্ড লিমিট পরীক্ষা একটি ক্লায়েন্ট শুরু করুন, ওয়ার্কলোড গ্রুপের জন্য সেট করুন, এবং যথাক্রমে 1, 2, এবং 4 এর সমগতি স্তরের অধীনে 5 মিনিটের জন্য ClickBench Q23 চালান। cpu_hard_limit=50% ক্যোয়ারী কনকারেন্সি বাড়ার সাথে সাথে, CPU ব্যবহারের হার প্রায় 800% থেকে যায়, যার মানে 8টি কোর ব্যবহার করা হয়। একটি 16-কোর মেশিনে, এটি , যা প্রত্যাশিত। উপরন্তু, যেহেতু CPU হার্ড লিমিট আরোপ করা হয়েছে, তাই TP99 লেটেন্সি বৃদ্ধির সাথে সাথে কনকারেন্সি বেড়ে যাওয়াও একটি প্রত্যাশিত ফলাফল। 50% ব্যবহার সিমুলেটেড উত্পাদন পরিবেশে পরীক্ষা বাস্তব-বিশ্বের ব্যবহারে, ব্যবহারকারীরা বিশেষ করে কোয়েরি থ্রুপুটের পরিবর্তে কোয়েরি লেটেন্সি সম্পর্কে উদ্বিগ্ন কারণ ব্যবহারকারীর অভিজ্ঞতায় লেটেন্সি আরও সহজে বোধগম্য। এই কারণেই আমরা একটি সিমুলেটেড উত্পাদন পরিবেশে ওয়ার্কলোড গ্রুপের কার্যকারিতা যাচাই করার সিদ্ধান্ত নিয়েছি। আমরা একক-টেবিল একত্রীকরণ এবং যোগদানের প্রশ্নগুলি সহ 1s (ClickBench Q15, Q17, Q23 এবং TPC-H Q3, Q7, Q19) এর মধ্যে সমাপ্ত হওয়া উচিত এমন প্রশ্নের সমন্বয়ে একটি SQL সেট বেছে নিয়েছি। TPC-H ডেটাসেটের আকার হল 100GB৷ একইভাবে, আমরা ওয়ার্কলোড গ্রুপগুলি কনফিগার না করে পরীক্ষা পরিচালনা করি। ফলাফল দেখায় হিসাবে: (পরীক্ষা 1 এবং 2 তুলনা করা): যখন ক্লায়েন্ট 2-এর কনকারেন্সি ডায়াল করার সময়, উভয় ক্লায়েন্ট ক্যোয়ারী লেটেন্সিতে 2~3-বার বৃদ্ধি অনুভব করে। ওয়ার্কলোড গ্রুপ ছাড়া (পরীক্ষা 3 এবং 4 এর তুলনা করা): ক্লায়েন্ট 2-এর সামঞ্জস্য বৃদ্ধির সাথে সাথে ক্লায়েন্ট 1-এর কর্মক্ষমতা ওঠানামা অনেক ছোট, যা কাজের চাপ বিচ্ছিন্নতার দ্বারা কার্যকরভাবে সুরক্ষিত কিভাবে তার প্রমাণ। ওয়ার্কলোড গ্রুপ কনফিগার করা সুপারিশ এবং পরিকল্পনা রিসোর্স ট্যাগ-ভিত্তিক সমাধান হল একটি পুঙ্খানুপুঙ্খ কাজের চাপ বিচ্ছিন্নকরণ পরিকল্পনা। ওয়ার্কলোড গ্রুপ-ভিত্তিক সমাধানটি সম্পদ বিচ্ছিন্নতা এবং ব্যবহারের মধ্যে একটি ভাল ভারসাম্য উপলব্ধি করে এবং এটি স্থিতিশীলতার গ্যারান্টির জন্য ক্যোয়ারী কিউ প্রক্রিয়া দ্বারা পরিপূরক। সুতরাং, আপনার ব্যবহারের ক্ষেত্রে কোনটি বেছে নেওয়া উচিত? এখানে আমাদের সুপারিশ: : ব্যবহারের ক্ষেত্রে যেখানে বিভাগের বিভিন্ন ব্যবসায়িক লাইন একই ক্লাস্টার ভাগ করে, তাই বিভিন্ন ভাড়াটেদের জন্য সম্পদ এবং ডেটা শারীরিকভাবে বিচ্ছিন্ন করা হয়। রিসোর্স ট্যাগ : ব্যবহারের ক্ষেত্রে যেখানে একটি ক্লাস্টার নমনীয় সম্পদ বরাদ্দের জন্য বিভিন্ন কোয়েরি ওয়ার্কলোড গ্রহণ করে। ওয়ার্কলোড গ্রুপ ভবিষ্যতের রিলিজে, আমরা ওয়ার্কলোড গ্রুপের ব্যবহারকারীর অভিজ্ঞতা এবং ক্যোয়ারী সারি বৈশিষ্ট্যগুলিকে উন্নত করতে থাকব: প্রশ্ন বাতিল করে মেমরির জায়গা খালি করা একটি নৃশংস পদ্ধতি। আমরা ডিস্ক স্পিলিং দ্বারা এটি বাস্তবায়ন করার পরিকল্পনা করি, যা ক্যোয়ারী কর্মক্ষমতা উচ্চতর স্থিতিশীলতা আনবে। যেহেতু BE-তে নন-কোয়েরি দ্বারা ব্যবহৃত মেমরি ওয়ার্কলোড গ্রুপের মেমরি পরিসংখ্যানে অন্তর্ভুক্ত নয়, ব্যবহারকারীরা BE প্রক্রিয়া মেমরি ব্যবহার এবং ওয়ার্কলোড গ্রুপ মেমরি ব্যবহারের মধ্যে একটি বৈষম্য লক্ষ্য করতে পারে। বিভ্রান্তি এড়াতে আমরা এই সমস্যাটি সমাধান করব। ক্যোয়ারী সারি মেকানিজমের মধ্যে, ক্লাস্টার লোড সর্বাধিক ক্যোয়ারী কনকারেন্সি সেট করে নিয়ন্ত্রিত হয়। আমরা BE-তে রিসোর্সের প্রাপ্যতার উপর ভিত্তি করে গতিশীল সর্বোচ্চ ক্যোয়ারী কনকারেন্সি সক্ষম করার পরিকল্পনা করছি। এটি ক্লায়েন্টের দিকে ব্যাকপ্রেশার তৈরি করে এবং এইভাবে ডরিসের প্রাপ্যতা উন্নত করে যখন ক্লায়েন্টরা উচ্চ লোড জমা দিতে থাকে। রিসোর্স ট্যাগের মূল ধারণা হল BE নোডগুলিকে গ্রুপ করা, যখন ওয়ার্কলোড গ্রুপের হল একটি একক BE নোডের সংস্থানগুলিকে আরও বিভক্ত করা। এই ধারণাগুলি উপলব্ধি করার জন্য, ব্যবহারকারীদের প্রথমে ডরিসে BE নোডের ধারণা সম্পর্কে জানতে হবে। যাইহোক, একটি অপারেশনাল দৃষ্টিকোণ থেকে, ব্যবহারকারীদের শুধুমাত্র তাদের প্রতিটি কাজের লোডের রিসোর্স খরচ শতাংশ এবং ক্লাস্টার লোড স্যাচুরেটেড হলে তাদের কী অগ্রাধিকার থাকা উচিত তা বুঝতে হবে। সুতরাং, আমরা ব্যবহারকারীদের জন্য শেখার বক্ররেখা সমতল করার একটি উপায় বের করার চেষ্টা করব, যেমন ব্ল্যাক বক্সে BE নোডের ধারণাটি রাখা। Apache Doris-এ কাজের চাপ বিচ্ছিন্নতার বিষয়ে আরও সহায়তার জন্য, যোগ দিন। Apache Doris সম্প্রদায়ে
