ফিল্টারড (নন-নাল মান) সূচকগুলির সাথে সূচকগুলি প্রতিস্থাপনের প্রভাব কী?


10

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

এখন আমার এই সম্পর্কে দুটি প্রশ্ন আছে:

ক) এই ফ্যাশনে ফিল্টারড সূচকগুলি ব্যবহারের ডাউনসাইডগুলি কী কী? আমি ধরে নেব যে এটি কেবল পারফরম্যান্সের উন্নতি করবে, তবে কোনও কার্যকারিতা ঝুঁকির সাথে জড়িত রয়েছে কি?

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

কোন সাহায্যের জন্য ধন্যবাদ!

সম্পাদনা: @ থমাস কেজারের জবাবে

হাই এবং ধন্যবাদ, তবে দেখা যাচ্ছে এটি একটি বিপর্যয় ছিল। সেই সময় আমরা বেশ কয়েকটি বিষয় বুঝতে পারি নি যেমন:

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

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


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

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

উত্তর:


8

খুব আকর্ষণীয় পদ্ধতির। সৃজনশীলতার জন্য আমার উত্সাহ।

যেহেতু আপনি স্থানটি পুনরুদ্ধার করেছেন, আমি ধরে নিই যে মূল সূচীগুলি আর কোনও জায়গায় নেই? ফিল্টারড সূচকের ডাউনসাইডগুলি হ'ল:

  • তাদের মধ্যে অনেকগুলিই অপটিমাইজারের অনুসন্ধানের স্থানটি অনেক বড় হতে পারে, যার ফলে অপেক্ষাকৃত অপেক্ষাকৃত সময় কমে যাওয়ার কারণে দুর্বল ক্যোয়ারী পরিকল্পনা হতে পারে
  • এমন অনেকগুলি পরিস্থিতি রয়েছে যেখানে একটি ফিল্টার সূচকটি বিবেচনা করা হবে না, যদিও ফিল্টারবিহীন সমতুল্য হবে। উল্লেখযোগ্যভাবে, যখন আপনি সূচকযুক্ত কলামে একটি হ্যাশ যোগদান করতে পারেন বা আপনি কলামটি (ফিল্টার ছাড়াই) অর্ডার দেওয়ার চেষ্টা করেন তখন এটি ঘটতে পারে
  • ক্যোয়ারী প্যারামিটারাইজেশন ফিল্টার করা সূচকগুলি নিয়ে কাজ করে না (দেখুন: http://www.sqlservercentral.com/blogs/practicalqldba/2013/04/08/sql-server-part-9-filtered-index-a-new-way- জন্য কর্মক্ষমতা-উন্নতি / )

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


"ক্যোয়ারী প্যারামিটারাইজেশন ফিল্টার ইনডেক্সগুলির সাথে কাজ করে না"। এটি সম্ভবত বিকল্পের সাথে সংশোধন করা যেতে পারে (পুনরায়
সংযোগ

2

টমাস কেজার এই বিষয়টির উপরে ভাল উত্তর দিন

আমি কেবল 2 সেন্ট যোগ করার কথা ভেবেছিলাম

আমি কিছু ফিল্টার সূচকগুলি কেবলমাত্র ব্যবহৃত হতে দেখলাম (এক্সিকিউশন প্ল্যানে দেখানো হয়েছে) যখন আপনি আপনার ক্যোয়ারীর যেখানে ক্লিয়ার্ট ইনডেক্সে রয়েছেন সেই বিভাগের সাথে যথাযথভাবে মেলে match

আপনি কি সূচী দর্শনগুলি ব্যবহার করার চেষ্টা করেছেন ? কদাচিৎ কলামগুলি ?

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

একাধিক ভিউ থাকতে পারে। তবে অ ক্লাস্টারযুক্ত সূচকের মতোই, অনেকগুলি আপনার লেখাকে কমিয়ে দেবে।

আমার অভিজ্ঞতায় আপনার পড়াতে ভাল লাভ হবে তবে টেবিলগুলি অনুলিখনের সাথে জড়িত থাকলে বিশেষত আপনার লেখার (সন্নিবেশ এবং আপডেট) নিরীক্ষণ করতে হবে।

যাইহোক, আমি আপনার মূল উদ্বেগটি বুঝতে পেরেছি the null valuesতাই আমি আপনাকে সূচীতে স্পারস কলামগুলি প্রস্তাব করব ।

বিচ্ছিন্ন কলামগুলি ফিল্টার করা সূচকগুলির জন্য বিশেষভাবে উপযুক্ত appropriate

আমি যেমন স্পার্স কলামগুলির বিজ্ঞাপন দিয়েছি তখন আমি এর সীমাবদ্ধতাগুলি সম্পর্কেও আপনাকে না জানালে ভাল লাগবে না:

বিচ্ছিন্ন কলামগুলির সাথে সারণীগুলি নকশা করার সময়, মনে রাখবেন যে সারিটি আপডেট করার সময় টেবিলের প্রতিটি নন-নাল স্পার্স কলামের জন্য অতিরিক্ত 2 বাইট ওভারহেডের প্রয়োজন।

এই ফলে

অতিরিক্ত মেমরির প্রয়োজনীয়তা, আপডেটগুলি ত্রুটি 576 এর সাথে অপ্রত্যাশিতভাবে ব্যর্থ হতে পারে যখন এই মেমরির ওভারহেড সহ মোট সারির আকার 8019 ছাড়িয়ে যায়,

এবং কোনও কলাম সারি থেকে ঠেলা যায় না।

বিগিন্ট টাইপের 600 টি স্পার্স কলাম রয়েছে এমন একটি সারণীর উদাহরণ বিবেচনা করুন।

যদি 571 নন-নাল কলাম থাকে তবে ডিস্কে মোট আকার 571 * 12 = 6852 বাইট। অতিরিক্ত সারি ওভারহেড এবং স্পারস কলাম শিরোলেখ অন্তর্ভুক্ত করার পরে এটি প্রায় 6895 বাইটে বেড়ে যায়। পৃষ্ঠাটিতে এখনও ডিস্কে প্রায় 1124 বাইট উপলব্ধ। এটি এই ধারণাটি দিতে পারে যে অতিরিক্ত কলামগুলি সফলভাবে আপডেট করা যেতে পারে। তবে আপডেটের সময়, মেমরিতে অতিরিক্ত ওভারহেড থাকে যা 2 * হয় (নন-নাল স্পার্স কলামগুলির সংখ্যা)। এই উদাহরণস্বরূপ, অতিরিক্ত ওভারহেড সহ - 2 * 571 = 1142 বাইট - ডিস্কের উপরের সারির আকার প্রায় 8037 বাইটে বাড়িয়ে তোলে। এই আকারটি 8019 বাইটের সর্বাধিক অনুমোদিত আকারকে ছাড়িয়ে গেছে। যেহেতু সমস্ত কলাম স্থির দৈর্ঘ্যের ডেটা ধরণের, সেগুলি সারি থেকে দূরে ঠেলা যায় না। ফলস্বরূপ, আপডেটটি 576 ত্রুটির সাথে ব্যর্থ হয়।

উপরের লিঙ্কটিতে আরও বিশদ, তবে আমি এখানে এই সতর্কতাটি পোস্ট করতে পছন্দ করি:

স্পর্শ থেকে ননস্পারস বা ননস্পারসে কলাম পরিবর্তন করার জন্য কলামের স্টোরেজ বিন্যাসটি পরিবর্তন করা দরকার।

এসকিউএল সার্ভার ডেটাবেস ইঞ্জিন এই পরিবর্তনটি সম্পাদন করতে নিম্নলিখিত পদ্ধতিটি ব্যবহার করে:

1 - নতুন স্টোরেজ আকার এবং ফর্ম্যাটে টেবিলটিতে একটি নতুন কলাম যুক্ত করে।

2 - সারণীতে প্রতিটি সারির জন্য, পুরানো কলামে সঞ্চিত মানটিকে নতুন কলামে আপডেট এবং অনুলিপি করে।

3 - সারণী স্কিমা থেকে পুরানো কলামটি সরিয়ে দেয়।

4 - পুরাতন কলাম দ্বারা ব্যবহৃত স্থান পুনরায় দাবিতে টেবিলটি পুনর্নির্মাণ করে (যদি কোনও ক্লাস্টারযুক্ত সূচক না থাকে) বা ক্লাস্টারড সূচি পুনর্নির্মাণ করে।


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

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

1
এছাড়াও, কিছু ক্ষেত্রে পৃষ্ঠা সংক্ষেপণ ব্যবহার করা আরও বেশি পছন্দনীয় ছিল, তাই আমরা পরিবর্তে এটি শেষ করেছিলাম। এটি খুব সহজেই কার্যকর যেহেতু আপনি সহজেই DROP_EXISTING = চালু দিয়ে বিদ্যমান ক্লাস্টারড ইনডেক্সটি তৈরি করতে পারবেন, এটিকে দারুণ রুটে যাওয়ার চেয়ে অনেক বেশি দ্রুত, এটি করতে। বিশেষত যেহেতু এটি সূচি পুনরায় পরিচালনা সূচি এবং এফকে এর সম্পূর্ণ ঝামেলা এড়ায়।
কাহন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.