একটি ইন-মেমরি টেবিলের কার্যকারিতা ডিস্ক-ভিত্তিক টেবিলের চেয়ে খারাপ

Question

এসকিউএল সার্ভারে আমার একটি টেবিল রয়েছে 2014 যা নিম্নলিখিতগুলির মতো দেখাচ্ছে:

CREATE TABLE dbo.MyTable
(
[id1] [bigint] NOT NULL,
[id2] [bigint] NOT NULL,
[col1] [int] NOT NULL default(0),
[col2] [int] NOT NULL default(0)
)

(আইডি 1, আইডি 2) পিকে থাকার সাথে। মূলত, আইডি 1 হ'ল ফলাফলের সেট (আইডি 2, কল 1, কল 2) এর গোষ্ঠী করার জন্য একটি সনাক্তকারী, যার পিকে আইডি 2।

আমি একটি বিদ্যমান ডিস্ক-ভিত্তিক টেবিল যা আমার বাধা eck এটি থেকে মুক্তি পেতে একটি ইন-মেমরি টেবিলটি ব্যবহার করার চেষ্টা করছি।

• সারণীতে থাকা ডেটাগুলি -> পড়ুন -> একবারে মুছে ফেলা হয়।
• প্রতিটি আইডি 1 মানটি কয়েক হাজার (দশক / শত) হাজার হাজার আইডি 2 রয়েছে।
• ডেটা টেবিলে খুব অল্প সময়ের জন্য সঞ্চয় করা হয়, যেমন 20 সেকেন্ড।

এই টেবিলে করা প্রশ্নগুলি নিম্নলিখিত:

-- INSERT (can vary from 10s to 10,000s of records):
INSERT INTO MyTable
  SELECT @fixedValue, id2, col1, col2 FROM AnotherTable

-- READ:
SELECT id2, col1
FROM MyTable INNER JOIN OtherTbl ON MyTable.id2 = OtherTbl.pk
WHERE id1 = @value
ORDER BY col1

-- DELETE:
DELETE FROM MyTable WHERE id1 = @value

আমি এখানে টেবিলের জন্য বর্তমান সংজ্ঞাটি ব্যবহার করেছি:

CREATE TABLE dbo.SearchItems
(
  [id1] [bigint] NOT NULL,
  [id2] [bigint] NOT NULL,
  [col1] [int] NOT NULL default(0),
  [col2] [int] NOT NULL default(0)

  CONSTRAINT PK_Mem PRIMARY KEY NONCLUSTERED (id1,id2),
  INDEX idx_Mem HASH (id1,id2) WITH (BUCKET_COUNT = 131072)
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)

দুর্ভাগ্যক্রমে, এই সংজ্ঞাটি ডিস্ক-ভিত্তিক টেবিলের সাথে পূর্ববর্তী পরিস্থিতিতে শ্রদ্ধার সাথে কর্মক্ষমতা একটি অবনতির ফলাফল করে। মাত্রার ক্রমটি কম বেশি 10% বেশি (কিছু ক্ষেত্রে এটি 100% পৌঁছে যায়, তাই দ্বিগুণ সময়)।

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

প্রশ্নাবলী:

• সঠিক BUCKET_COUNT কী সেট করতে হবে?
• আমার কোন ধরণের সূচক ব্যবহার করা উচিত?
• ডিস্ক-ভিত্তিক টেবিলের চেয়ে কর্মক্ষমতা কেন খারাপ?

Sys.dm_db_xtp_hash_index_stats এর একটি কোয়েরি ফিরে আসে:

total_bucket_count = 131072
empty_bucket_count = 0
avg_chain_len = 873
max_chain_length = 1009

আমি বালতি গণনা পরিবর্তন করেছি তাই sys.dm_db_xtp_hash_index_stats থেকে আউটপুটটি হ'ল:

total_bucket_count = 134217728
empty_bucket_count = 131664087
avg_chain_len = 1
max_chain_length = 3

তবুও, ফলাফলগুলি আরও খারাপ না হলে প্রায় একই রকম।

Comments

আপনি কি নিশ্চিত যে আপনি প্যারামিটার স্নিফিংয়ে চলেছেন না? আপনি কি OPTION(OPTIMIZE FOR UNKNOWN)( টেবিলের ইঙ্গিতগুলি দেখুন ) দিয়ে ক্যুরিগুলি চালানোর চেষ্টা করেছেন ?

— টিটি।

আমার ধারণা আপনি সারি চেইনের সমস্যা নিয়ে চলেছেন। আপনি আমাদের আউটপুট দিতে পারেন select * from sys.dm_db_xtp_hash_index_stats ? : এছাড়াও, এই লিঙ্কটি সবচেয়ে / আপনার সব প্রশ্নের উত্তর দিতে হবে msdn.microsoft.com/en-us/library/...

— শন Gallardy

হ্যাশ সূচক কেবলমাত্র উভয় অন্তর্ভুক্ত কলামে পূর্বাভাসের জন্য দরকারী। আপনি কি টেবিলে হ্যাশ সূচক ছাড়া চেষ্টা করেছেন?

— মিকেল এরিকসন

আমি খুঁজে পেয়েছি যে ইন-মেমরি প্রযুক্তির সাথে সর্বোত্তম পারফরম্যান্সের উন্নতি কেবল দেশীয় সংকলিত সঞ্চিত পদ্ধতি ব্যবহার করেই অর্জন করা যায় ।

— ড্যানিয়েল হুটমাচার

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

— অ্যারন বারট্র্যান্ড

Answer 1

তথ্যের অভাবের কারণে এই পোস্টটি সম্পূর্ণ উত্তর হবে না, তবে এটি আপনাকে সঠিক দিকে নির্দেশ করতে বা অন্যথায় অন্তর্দৃষ্টি অর্জন করতে সক্ষম হবে যা আপনি পরে সম্প্রদায়ের সাথে ভাগ করতে পারেন can

দুর্ভাগ্যক্রমে, এই সংজ্ঞাটি ডিস্ক-ভিত্তিক টেবিলের সাথে পূর্ববর্তী পরিস্থিতিতে শ্রদ্ধার সাথে কর্মক্ষমতা একটি অবনতির ফলাফল করে। মাত্রার ক্রমটি কম বেশি 10% বেশি (কিছু ক্ষেত্রে এটি 100% পৌঁছে যায়, তাই দ্বিগুণ সময়)।

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

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

মূলত আমি এ সম্পর্কিত আপনার প্রশ্নগুলি সম্পর্কে খুব সংকীর্ণ ভাবছিলাম:

প্রশ্নাবলী:

• সঠিক BUCKET_COUNT কী সেট করতে হবে?
• আমার কোন ধরণের সূচক ব্যবহার করা উচিত?
• ডিস্ক-ভিত্তিক টেবিলের চেয়ে কর্মক্ষমতা কেন খারাপ?

প্রাথমিকভাবে আমি বিশ্বাস করি মেমরি টেবিল এবং সূচকগুলি যথাযথ না হওয়াতে আসল একটি সমস্যা আছে। যদিও মেমরি অপটিমাইজড হ্যাশ সূচক সংজ্ঞা নিয়ে কিছু সমস্যা রয়েছে আমি বিশ্বাস করি আসল সমস্যাটি ব্যবহৃত প্রশ্নের সাথে থাকবে।

-- INSERT (can vary from 10s to 10,000s of records):
INSERT INTO MyTable
  SELECT @fixedValue, id2, col1, col2 FROM AnotherTable

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

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

নির্বাচন জিজ্ঞাসা সহ:

SELECT id2, col1
FROM MyTable INNER JOIN OtherTbl ON MyTable.id2 = OtherTbl.pk
WHERE id1 = @value
ORDER BY col1

আবার, আমরা ইন্টারপ + ডিস্ক ভিত্তিক টেবিলের কার্য সম্পাদনের করুণায় আছি। অতিরিক্তভাবে, HASH সূচকগুলিতে বাছাইগুলি সস্তা নয় এবং একটি অবিচ্ছিন্ন সূচক ব্যবহার করা উচিত। আমি মন্তব্যগুলিতে লিঙ্কযুক্ত সূচক নির্দেশিকাতে এটি আউট বলা হয় ।

কিছু বাস্তব গবেষণা ভিত্তিক তথ্য দেওয়ার জন্য, আমি SearchItemsএর মেমরি টেবিলটি 10 ​​মিলিয়ন সারি দিয়ে এবং AnotherTable100,000 দিয়ে লোড করেছি কারণ এর প্রকৃত আকার বা পরিসংখ্যান আমি জানি না। তারপরে আমি এক্সিকিউট করতে উপরের সিলেক্ট ক্যোয়ারীটি ব্যবহার করেছি। অতিরিক্তভাবে আমি ওয়েট_ কমপ্লিটে একটি বর্ধিত ইভেন্ট সেশন তৈরি করেছি এবং এটিকে একটি রিং বাফারে রেখেছি। এটি প্রতিটি রান করার পরে পরিষ্কার করা হয়েছিল। আমি এমন DBCC DROPCLEANBUFFERSপরিবেশের অনুকরণ করতে দৌড়ে গিয়েছিলাম যেখানে সমস্ত ডেটা মেমরির বাসিন্দা নাও হতে পারে।

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

ফলাফলটি কেবলমাত্র ইন-মেমরি ভিত্তিক টেবিলটিতে (জয়েন্টটি সরিয়ে ফেলুন এবং কোনও সাব-কোয়েরি নেই) কোয়েরীর 5 রান করার পরে কোনও ওয়েট তথ্য ছাড়াই এসেছিল। এটি প্রত্যাশার চেয়েও অনেক বেশি।

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

এই ক্ষেত্রে, আবারও, সময়ের উল্লেখযোগ্য অংশটি ডিস্ক ভিত্তিক টেবিলে ব্যয় করা হয়েছিল।

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

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

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

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

ফলো-আপ:

1. অপেক্ষা_ কমপ্লিট করার জন্য একটি বর্ধিত ইভেন্ট সেশন তৈরি করুন এবং আপনার পরিচিত একটি এসপিআইডি নির্দিষ্ট করুন। কোয়েরি চালান এবং আমাদের আউটপুট দিন বা এটি অভ্যন্তরীণভাবে গ্রাস করুন।

2. আমাদের # 1 থেকে আউটপুট সম্পর্কে একটি আপডেট দিন।

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