মাল্টি-টেন্যান্ট এসকিউএল সার্ভার ডাটাবেসে সম্মিলিত প্রাথমিক কী

আমি এএসপি ওয়েব এপিআই, সত্তা ফ্রেমওয়ার্ক এবং এসকিউএল সার্ভার / অ্যাজুরি ডাটাবেস ব্যবহার করে একটি বহু-ভাড়াটে অ্যাপ (একক ডাটাবেস, একক স্কিমা) তৈরি করছি। এই অ্যাপ্লিকেশনটি 1000-5000 গ্রাহকরা ব্যবহার করবেন। সমস্ত TenantIdসারণীতে (গাইড / UNIQUEIDENTIFIER) ক্ষেত্র থাকবে। এখনই, আমি একক ক্ষেত্রের প্রাথমিক কী ব্যবহার করি যা আইডি (গাইড)। তবে কেবল আইডি ক্ষেত্রটি ব্যবহার করে, আমাকে যাচাই করতে হবে যে ব্যবহারকারীর সরবরাহ করা ডেটা সঠিক ভাড়াটে / থেকে এসেছে। উদাহরণস্বরূপ, আমার কাছে একটি SalesOrderটেবিল রয়েছে যার একটি CustomerIdক্ষেত্র রয়েছে। প্রতিবার ব্যবহারকারীরা যখন কোনও বিক্রয় অর্ডার পোস্ট / আপডেট করেন তখন আমাকে CustomerIdএকই ভাড়াটে থেকে এসেছে কিনা তা পরীক্ষা করে দেখতে হবে। এটি আরও খারাপ হয় কারণ প্রতিটি ভাড়াটেটির বেশ কয়েকটি আউটলেট থাকতে পারে। তারপরে আমাকে চেক করতে হবে TenantIdএবং OutletId। এটি সত্যিই রক্ষণাবেক্ষণের দুঃস্বপ্ন এবং পারফরম্যান্সের জন্য খারাপ।

আমি TenantIdপাশাপাশি প্রাইমারি কী যুক্ত করার কথা ভাবছি Id। এবং সম্ভবত যোগ করুন OutletId। তাই প্রাথমিক কী SalesOrderটেবিল হবে: Id, TenantId, এবং OutletId। এই পদ্ধতির ক্ষতি কী? কোনও যৌগিক কী ব্যবহার করে পারফরম্যান্সটি খারাপভাবে আঘাত করবে? যৌগিক কী অর্ডার বিষয়টি বিবেচনা করে? আমার সমস্যার আরও ভাল সমাধান আছে?

— Reynaldi
সূত্র

একটি বৃহত্তর স্কেল, মাল্টি-টেন্যান্ট সিস্টেমের উপর কাজ করা (18+ সার্ভার জুড়ে ছড়িয়ে থাকা গ্রাহকদের সাথে সংঘবদ্ধ পদ্ধতি, প্রতিটি সার্ভারে অভিন্ন স্কিমা রয়েছে, কেবল বিভিন্ন গ্রাহক এবং প্রতি সার্ভারে প্রতি সেকেন্ডে কয়েক হাজার লেনদেন), আমি বলতে পারি:

কিছু লোক আছে (কয়েকজন, কমপক্ষে) যারা আপনার "জিএনপি'র" টেন্যান্টআইডি "এবং যে কোনও সত্তা" আইডি "উভয়েরই আইডি হিসাবে জিইউডির পছন্দকে সম্মত করবেন। তবে না, ভাল পছন্দ নয়। অন্য সমস্ত বিবেচনা বাদ দিলে, এই পছন্দটি একাই কয়েকটি উপায়ে ক্ষতিগ্রস্থ হবে: বিভক্তকরণ শুরু করার জন্য, প্রচুর পরিমাণে অপচয়যোগ্য স্থান ( এন্টারপ্রাইজ স্টোরেজ - স্যান - বা প্রতিটি ডেটা পৃষ্ঠার কারণে বেশি সময় নিচ্ছে এমন প্রশ্নগুলি জিজ্ঞাসা করার সময় ডিস্ক সস্তা বলে বলবেন না) don't এটির সাথে INTবা এর চেয়ে কম সারি ধরে রাখা BIGINT), আরও কঠিন সমর্থন এবং রক্ষণাবেক্ষণ ইত্যাদি G. জিইউইডিগুলি বহনযোগ্যতার জন্য দুর্দান্ত। ডেটা কি কোনও সিস্টেমে উত্পন্ন হয় এবং পরে অন্যটিতে স্থানান্তরিত হয়? যদি তা না হয়, তাহলে আরো একটি কম্প্যাক্ট ডাটা টাইপ (যেমন স্যুইচ TINYINT, SMALLINT, INT, অথবা এমনকি BIGINTমাধ্যমে ক্রমানুসারে), এবং বৃদ্ধি IDENTITYবাSEQUENCE।
আইটেম 1 টি বাহিরের সাথে, আপনার কাছে প্রতিটি টেবিলে টেন্যান্টআইডি ফিল্ড থাকা দরকার যা ব্যবহারকারীর ডেটা রয়েছে। এইভাবে কোনও অতিরিক্ত যোগদানের প্রয়োজন ছাড়াই আপনি যে কোনও কিছু ফিল্টার করতে পারবেন। এর অর্থ হ'ল ক্লায়েন্ট-ডেটা সারণীর বিপরীতে সমস্ত প্রশ্নের TenantIDজওআইএন শর্ত এবং / অথবা যেখানে বিধি থাকতে হবে। এটি গ্যারান্টিটিতেও সহায়তা করে যে আপনি দুর্ঘটনাক্রমে বিভিন্ন গ্রাহকদের কাছ থেকে ডেটা মেশাবেন না, বা টেন্যান্ট বি থেকে টেন্যান্ট এ ডেটা দেখান না guarantee
আমি আইডির সাথে টেন্যান্টআইডিকে প্রাথমিক কী হিসাবে যুক্ত করার কথা ভাবছি। এবং সম্ভবত আউটলেটআইড যুক্ত করুন। সুতরাং বিক্রয় অর্ডার সারণীতে প্রাথমিক কী (গুলি) হবে আইডি, টেন্যান্টআইডি, আউটলেটআইড।

হ্যাঁ, ক্লায়েন্ট-ডেটা টেবিলগুলিতে আপনার ক্লাস্টারযুক্ত সূচিগুলি সমন্বিত কীগুলি হওয়া উচিত, সমেত TenantIDএবং ID ^** সহ । এটি TenantIDপ্রতিটি নন-ক্ল্লাস্টারড ইনডেক্সেও রয়েছে তা নিশ্চিত করে (যেহেতু ক্লাস্টারড ইনডেক্স কী (গুলি) অন্তর্ভুক্ত রয়েছে) যেহেতু ক্লায়েন্ট-ডেটা সারণীর বিরুদ্ধে 98.45% প্রশ্নের প্রয়োজন হবে TenantID(মূল ব্যতিক্রম হ'ল আবর্জনা পুরানো ডেটা সংগ্রহ করার সময়) চালু CreatedDateএবং যত্ন নেই TenantID)।

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

এছাড়াও, OutletIDটেনেন্ট বি এর আউটলেটগুলি টেনেন্ট বিয়ের সাথে মিশে না যায় তা নিশ্চিত করার জন্য পিকে যুক্ত করার দরকার নেই, যেহেতু সমস্ত ব্যবহারকারীর ডেটা টেবিলগুলি TenantIDপিকে থাকবে, তার অর্থ TenantIDএটিও এফকেতে থাকবে । উদাহরণস্বরূপ, Outletটেবিলটির একটি পিকে রয়েছে (TenantID, OutletID)এবং Orderটেবিলটির একটি পিকে রয়েছে (TenantID, OrderID) এবং একটি এফকে রয়েছে (TenantID, OutletID)যার মধ্যে Outletটেবিলের পিকে উল্লেখ করা হয় । সঠিকভাবে সংজ্ঞায়িত এফকে টেন্যান্টের ডেটা সংমিশ্রিত হতে বাধা দেবে।
যৌগিক কী অর্ডার বিষয়টি বিবেচনা করে?

ভাল, এখানে এটি মজা পায়। প্রথমে কোন ক্ষেত্রটি আসা উচিত তা নিয়ে কিছুটা বিতর্ক রয়েছে। ভাল সূচকগুলি ডিজাইনের জন্য "সাধারণ" নিয়মটি হল শীর্ষস্থানীয় ক্ষেত্র হতে সর্বাধিক নির্বাচনী ক্ষেত্র বেছে নেওয়া। TenantID, তার প্রকৃতি অনুসারে, সবচেয়ে নির্বাচনী ক্ষেত্র হবে না ; IDক্ষেত্র সবচেয়ে বাছাই ক্ষেত্র। এখানে কিছু চিন্তা আছে:
- প্রথম আইডি: এটি সর্বাধিক নির্বাচনী (অর্থাত্ অনন্য) ক্ষেত্র। তবে একটি অটো ইনক্রিমেন্ট ফিল্ড হয়ে (বা এখনও জিআইডি ব্যবহার করা থাকলে এলোমেলো) হয়ে প্রতিটি গ্রাহকের ডেটা প্রতিটি টেবিল জুড়ে ছড়িয়ে পড়ে। এর অর্থ হ'ল এমন সময় আছে যখন কোনও গ্রাহকের জন্য 100 টি সারি প্রয়োজন হয় এবং এর জন্য প্রায় 100 টি ডেটা পৃষ্ঠাগুলি ডিস্ক থেকে পড়া হয় (দ্রুত নয়) বাফার পুলটিতে (10 টি ডাটা পৃষ্ঠাগুলির চেয়ে বেশি স্থান গ্রহণ করে)। এটি ডেটা পৃষ্ঠাগুলিতে বিতর্ক বাড়িয়ে তোলে যেহেতু এটি আরও ঘন ঘন হবে যে একাধিক গ্রাহককে একই ডেটা পৃষ্ঠা আপডেট করতে হবে।
  
  তবে, আপনি সাধারণত যতটা প্যারামিটার স্নিফিং / খারাপ ক্যাশেড প্ল্যান ইস্যুগুলির মধ্যে চলে না তাই বিভিন্ন আইডি মানগুলির পরিসংখ্যান মোটামুটি সুসংগত। আপনি সর্বাধিক অনুকূল পরিকল্পনা নাও পেতে পারেন, তবে আপনি ভয়াবহ পরিকল্পনা পাওয়ার সম্ভাবনা কম পাবেন। এই পদ্ধতিটি কম ঘন ঘন সমস্যার সুবিধা পেতে সমস্ত গ্রাহকদের জুড়ে পারফরম্যান্সের (সামান্য) ত্যাগ করে।
- টেন্যান্টআইডি প্রথম:এটি মোটেই নির্বাচনী নয়। আপনার যদি 100 টি টেন্যান্টআইডি থাকে তবে 1 মিলিয়ন সারিগুলিতে খুব কম পার্থক্য থাকতে পারে। তবে এসকিউএল সার্ভার জানতে পারে যে টেন্যান্ট এ-এর জন্য একটি কোয়েরি 500,000 সারি পিছনে টেনে তুলবে তবে টেন্যান্ট বি এর জন্য একই কোয়েরিটি কেবল 50 টি সারি But এটিই মূল ব্যথা-বিন্দু। এই পদ্ধতিটি প্যারামিটার স্নিফিংয়ের সমস্যাগুলি অনেক বেড়ে যায় যেখানে কোনও সঞ্চিত প্রক্রিয়ার প্রথম চালক টেন্যান্ট এ এর জন্য হয় এবং কোয়েরি অপটিমাইজারের উপর ভিত্তি করে যথাযথভাবে কাজ করে সেই পরিসংখ্যানগুলি দেখে এবং এটি জেনে যে এটি 500k সারি পাওয়ার দক্ষ হতে হবে। কিন্তু যখন টেন্যান্ট বি, মাত্র 50 টি সারি নিয়ে চালিত হয় তখন কার্যকর করার পরিকল্পনাটি আর উপযুক্ত হয় না এবং বাস্তবে এটি বেশ অনুপযুক্ত। এবং, যেহেতু শীর্ষস্থানীয় ক্ষেত্রের ক্রমে ডেটা প্রবেশ করা হচ্ছে না,
  
  তবে, প্রথম টেন্যান্টআইডি-র একটি সঞ্চিত প্রক্রিয়া চালানোর জন্য, অন্যান্য পদ্ধতির তুলনায় পারফরম্যান্সটি আরও ভাল হওয়া উচিত যেহেতু ডেটা (কমপক্ষে সূচী রক্ষণাবেক্ষণের পরে) শারীরিক এবং যৌক্তিকভাবে এমনভাবে সংগঠিত হবে যেগুলি পূরণ করার জন্য খুব কম তথ্য পৃষ্ঠাগুলির প্রয়োজন হয় প্রশ্নের। এর অর্থ শারীরিক আই / ও, কম যুক্তিসঙ্গত পাঠ, একই ডেটা পৃষ্ঠাগুলির জন্য ভাড়াটেদের মধ্যে কম ঝগড়া, বাফার পুলে কম অপচয় করা স্থান (যার ফলে পেজ লাইফ প্রত্যাশা উন্নত) ইত্যাদি means
  
  এই উন্নত কর্মক্ষমতা পাওয়ার জন্য দুটি মূল ব্যয় রয়েছে are প্রথমটি এতটা কঠিন নয়: বর্ধিত খণ্ডকে প্রতিহত করতে আপনাকে অবশ্যই নিয়মিত সূচী রক্ষণাবেক্ষণ করতে হবে। দ্বিতীয়টি কিছুটা কম মজা।
  
  বর্ধিত প্যারামিটার স্নিফিংয়ের সমস্যাগুলির মোকাবিলা করতে আপনার ভাড়াটেদের মধ্যে কার্যকর করার পরিকল্পনাগুলি পৃথক করা দরকার। সরল পদ্ধতিটি হল WITH RECOMPILEপ্রোস বা OPTION (RECOMPILE)ক্যোয়ারির ইঙ্গিত ব্যবহার করা , তবে এটি এমন পারফরম্যান্সের উপর আঘাত যা TenantIDপ্রথমে রেখে সমস্ত লাভ মুছে ফেলতে পারে । যে পদ্ধতিটি আমি সবচেয়ে ভালভাবে কাজ করেছি তা হ'ল প্যারামিটারাইজড ডায়নামিক এসকিউএল এর মাধ্যমে ব্যবহার করা sp_executesql। ডায়নামিক এসকিউএল প্রয়োজন হওয়ার কারণ হ'ল টেন্যান্টআইডিটিকে ক্যোয়ারীর পাঠ্যর সাথে যুক্ত করার অনুমতি দেওয়া হয়, অন্যদিকে যে সমস্ত অন্যান্য পূর্বাভাস সাধারণত পরামিতি হবে তা এখনও প্যারামিটার। উদাহরণস্বরূপ, আপনি যদি একটি নির্দিষ্ট আদেশ খুঁজছেন, আপনি যেমন কিছু করতে হবে:
```
DECLARE @GetOrderSQL NVARCHAR(MAX);
SET @GetOrderSQL = N'
  SELECT ord.field1, ord.field2, etc.
  FROM   dbo.Orders ord
  WHERE  ord.TenantID = ' + CONVERT(NVARCHAR(10), @TenantID) + N'
  AND    ord.OrderID = @OrderID_dyn;
';

EXEC sp_executesql
   @GetOrderSQL,
   N'@OrderID_dyn INT',
   @OrderID_dyn = @OrderID;
```
  এর প্রভাবটি হ'ল কেবল সেই টেন্যান্টআইডি-র জন্য পুনরায় ব্যবহারযোগ্য ক্যোয়ারী পরিকল্পনা তৈরি করা যা সেই নির্দিষ্ট টেন্যান্টের ডেটা ভলিউমের সাথে মিলবে। যদি সেই একই টেন্যান্ট এ আবার অন্যটির জন্য সঞ্চিত প্রক্রিয়া চালায় @OrderIDতবে তা সেই ক্যাশেড ক্যোয়ারী প্ল্যানটিকে পুনরায় ব্যবহার করবে। একই স্টোরড পদ্ধতিতে চলমান একটি পৃথক ভাড়াটে একটি কোয়েরি পাঠ্য উত্পন্ন করবে যা কেবল টেন্যান্টআইডি'র মানেই আলাদা ছিল , তবে ক্যোয়ারী পাঠ্যের যে কোনও পার্থক্য একটি আলাদা পরিকল্পনা উত্পন্ন করতে যথেষ্ট। এবং টেন্যান্ট বি এর জন্য উত্পন্ন পরিকল্পনাটি কেবল টেন্যান্ট বি এর সাথে ডেটা ভলিউমের সাথে মেলে না তবে এটি টেন্যান্ট বি এর বিভিন্ন মানগুলির জন্য পুনরায় ব্যবহারযোগ্য হবে @OrderID(যেহেতু সেই ভবিষ্যদ্বাণীটি এখনও প্যারামিটারাইজড)।
  
  এই পদ্ধতির ডাউনসাইডগুলি হ'ল:
  - এটি কেবল একটি সাধারণ ক্যোয়ারিতে টাইপ করার চেয়ে কিছুটা বেশি কাজ (তবে সমস্ত প্রশ্নের ডায়নামিক এসকিউএল হওয়া দরকার না, কেবলমাত্র প্যারামিটার স্নিফিংয়ের সমস্যা রয়েছে)।
  - কোনও সিস্টেমে কত ভাড়াটে রয়েছে তার উপর নির্ভর করে এটি পরিকল্পনার ক্যাশের আকার বাড়ায় যেহেতু প্রতিটি প্রশ্নের জন্য এখন টেন্যান্টআইডি প্রতি 1 টি পরিকল্পনা প্রয়োজন যা এটি কল করছে। এটি কোনও সমস্যা নাও হতে পারে তবে সচেতন হওয়ার জন্য অন্তত এমন কিছু বিষয়।
  - ডায়নামিক এসকিউএল মালিকানা শৃঙ্খলা ভঙ্গ করে, যার অর্থ সারণী পদ্ধতিতে অনুমতি / লেখার মাধ্যমে টেবিলগুলিতে পঠন / লেখার অ্যাক্সেস অনুমান করা যায় না EXECUTE। সহজ তবে কম সুরক্ষিত ফিক্সটি কেবলমাত্র টেবিলগুলিতে ব্যবহারকারীকে সরাসরি অ্যাক্সেস দেওয়া। এটি অবশ্যই আদর্শ নয়, তবে এটি সাধারণত দ্রুত এবং সহজ জন্য বাণিজ্য off সার্টিফিকেট-ভিত্তিক সুরক্ষা ব্যবহার করা আরও সুরক্ষিত পদ্ধতির। অর্থ, একটি শংসাপত্র তৈরি করুন, তারপরে সেই শংসাপত্রটি থেকে একটি ব্যবহারকারী তৈরি করুন, সেই ব্যবহারকারীকে পছন্দসই অনুমতি প্রদান করুন (একটি শংসাপত্র ভিত্তিক ব্যবহারকারী বা লগইন নিজেই এসকিউএল সার্ভারের সাথে সংযোগ স্থাপন করতে পারে না) এবং তারপরে ডায়নামিক এসকিউএল ব্যবহার করে এমন সঞ্চিত পদ্ধতিতে স্বাক্ষর করুন that ADD স্বাক্ষরের মাধ্যমে একই শংসাপত্র ।
    
    মডিউল স্বাক্ষর এবং শংসাপত্রগুলি সম্পর্কে আরও তথ্যের জন্য, দয়া করে দেখুন: মডিউলসাইনিং.আইনফো
এই সিদ্ধান্তের ফলে পরিমিত পরিসংখ্যান সম্পর্কিত সমস্যাগুলি সম্পর্কিত সমস্যা সম্পর্কিত অতিরিক্ত বিষয়ের জন্য দয়া করে শেষের দিকে আপডেট বিভাগটি দেখুন ।

^** ব্যক্তিগতভাবে, আমি প্রতিটি টেবিলের পিকে ক্ষেত্রের নামের জন্য "আইডি" ব্যবহার করা সত্যিই অপছন্দ করি কারণ এটি অর্থবহ নয় এবং এটি পিকে সর্বদা "আইডি" থাকে এবং এটি শিশু টেবিলে ক্ষেত্রটি রাখতে হয় পিতামাতার সারণির নাম অন্তর্ভুক্ত করুন। যেমন: Orders.ID-> OrderItems.OrderID। আমি যে ডেটা মডেলটিতে রয়েছি সেগুলি মোকাবেলা করতে খুব সহজ মনে করি: Orders.OrderID-> OrderItems.OrderID। এটি আরও পঠনযোগ্য এবং আপনি "দ্ব্যর্থক কলাম রেফারেন্স" ত্রুটিটি পেয়ে যাবেন তার সংখ্যা হ্রাস করে :-)।

হালনাগাদ

চান OPTIMIZE FOR UNKNOWN ক্যোয়ারী ইঙ্গিত যৌগিক পি কে যেকোন ক্রম সঙ্গে (SQL সার্ভার চালু 2008) সাহায্য করেছিল?

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

এই বিকল্পটি স্থানীয় ভেরিয়েবলগুলিতে ইনপুট পরামিতিগুলি অনুলিপি করা এবং তারপরে কোয়েরিতে স্থানীয় ভেরিয়েবলগুলি ব্যবহার করার মতো একই জিনিসটি সম্পাদন করে (আমি এটি পরীক্ষা করেছি তবে এখানে এর জন্য কোনও স্থান নেই)। অতিরিক্ত তথ্য এই ব্লগ পোস্টে পাওয়া যাবে: http://www.brentozar.com/archive/2013/06/optimize-for-unعلوم-sql-server-parameter-sniffing/ । মন্তব্যগুলি পড়তে গিয়ে ড্যানিয়েল পেপারম্যানস ডায়নামিক এসকিউএল ব্যবহারের ক্ষেত্রে খনিতে অনুরূপ সিদ্ধান্তে পৌঁছেছিল যার সীমিত প্রকরণ রয়েছে।
যদি আইডি ক্লাস্টারড ইনডেক্সের শীর্ষস্থানীয় ক্ষেত্র হয় তবে এটি কি একা ভাড়াটে অনেক সারি প্রক্রিয়াজাতকরণের প্রশ্নের সঠিক পরিসংখ্যান রাখতে (টেন্যান্টআইডি, আইডি), বা কেবল (টেন্যান্টআইডি) একটি নন-ক্লাস্টারড ইনডেক্স রাখতে সহায়তা করবে?

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

যদিও এটি টেন্যান্টআইডি-ভিত্তিক প্রশ্নগুলি আরও বেশি দক্ষতার সাথে সক্ষম করার তাত্ক্ষণিক সমস্যার সমাধান করেছে, তারা এখনও ততটা দক্ষ ছিল না যদি এটি একই ক্রমযুক্ত ক্লাস্টারড সূচি হত। এবং, এখন আমাদের প্রতিটি টেবিলে আরও একটি সূচক ছিল । এটি আমরা যে SAN স্পেস ব্যবহার করছিলাম তার পরিমাণ বাড়িয়েছে, আমাদের ব্যাকআপগুলির আকার বাড়িয়েছে, ব্যাকআপগুলি সম্পূর্ণ হতে আরও বেশি সময় নিয়েছে, ব্লকিং এবং ডেডলকগুলির সম্ভাবনা বাড়িয়েছে, কার্যকারিতা হ্রাস পাবে INSERTএবং DELETEপরিচালনা করবে ইত্যাদি

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

— সলোমন রুটজকি
সূত্র

আপনি কি এই সমস্যার জায়গাতে অজানা জন্য অপ্টিমাইজটি বিবেচনা করেছেন বা পরীক্ষা করেছেন? উৎসুক.

— আরএলএফ

@ আরএলএফ হ্যাঁ, আমরা সেই বিকল্পটি নিয়ে গবেষণা করেছি এবং এটি পরিচয়ের ক্ষেত্রটি প্রথম পাওয়া থেকে আমরা যতটা অনুকূল পারফরম্যান্স পেয়েছি তার চেয়ে কম, এবং সম্ভবত সবচেয়ে খারাপ হওয়া উচিত। আমি কোথায় এটি পড়েছিলাম তা মনে নেই, তবে এটি স্থানীয় ভেরিয়েবলকে ইনপুট প্যারাম পুনরায় অর্পণ করার মতো একই "গড়" পরিসংখ্যান দেয় gives তবে এই নিবন্ধটি কেন সেই বিকল্পটিতে সত্যই সমস্যাটি সমাধান করে না: ব্রেন্টোজার / আরচাইভ / ২০১ive / ০6/ ২ মন্তব্যগুলি পড়ে ড্যানিয়েল পেপারম্যানস একইরকম সিদ্ধান্তে পৌঁছেছেন: সীমিত প্রকরণের সাথে ডায়নামিক এসকিউএল :)

— সলোমন রুটজকি

যদি ক্লাস্টার্ড সূচক চালু থাকে (ID, TenantID)এবং আপনি একটি ক্লাস্টারযুক্ত সূচকও তৈরি করেন (TenantID, ID)বা কেবল (TenantID)কোনও ভাড়াটে সবচেয়ে সারি প্রক্রিয়া করে এমন প্রশ্নের জন্য সঠিক পরিসংখ্যান রাখেন ?

— ভ্লাদিমির বারানভ

@ ভ্লাদিমিরবারানভ দুর্দান্ত প্রশ্ন। আমি উত্তরটির শেষের দিকে একটি নতুন আপডেটের অংশে এটি সম্বোধন করেছি :-)।

— সলোমন রুটজকি

প্রতিটি গ্রাহকের জন্য পরিকল্পনা উত্পন্ন করার জন্য গতিশীল এসকিএল সম্পর্কে দুর্দান্ত পয়েন্ট ।

— ম্যাক্স ভার্নন