সূচী তৈরির পরিবর্তে কখন স্ট্যাটিক্স তৈরি করা ভাল?


38

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

@ জোনাথনফাইট একটি মন্তব্যে সূচী এবং পরিসংখ্যানের মধ্যে পার্থক্য উল্লেখ করেছে:

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

এটি দুর্দান্ত তথ্য, বেশিরভাগ কারণ এটি আমাকে আমার প্রশ্নটি পরিষ্কার করতে সহায়তা করে:

কিভাবে এই বুদ্ধিমান নেই (অথবা অন্য কোন প্রযুক্তিগত তথ্য কি s এবং কিভাবে আচরণ এবং প্রকৃতির সাথে সম্পর্কিত র STATISTICS) সাহায্যের নির্ধারণ যখন নির্বাচন করতে CREATE STATISTICSউপর CREATE INDEXএকটি সূচক তৈরি করা সংশ্লিষ্ট তৈরি করবে, বিশেষ করে STATISTICSবস্তু? কেবলমাত্র পরিসংখ্যান সম্পর্কিত তথ্য এবং সূচকটি না রেখে কোন পরিস্থিতি আরও ভাল পরিবেশিত হবে ?

এটি সুপার-ডুপার সহায়ক, যদি সম্ভব হয় তবে এমন দৃশ্যের একটি কার্যকারী উদাহরণ থাকতে হবে যেখানে STATISTICSবস্তুর চেয়ে একটি ভাল ফিট INDEX


যেহেতু আমি একজন ভিজ্যুয়াল লার্নার / চিন্তাবিদ, আমি ভেবেছিলাম যে এটি আরও ভাল পছন্দ কখন হয় তা নির্ধারণে সহায়তা করার একটি সম্ভাব্য উপায় হিসাবে পাশাপাশি STATISTICSএবং এর মধ্যে পার্থক্যগুলি দেখতে পারে ।INDEXSTATISTICS

Thingy           PROs                             CONs
-------          ----------                       -------------------
INDEX            * Can help sorts.                * Takes up space.
                 * Contains data (can             * Needs to be maintained (extra I/O).
                   "cover" a query).              * More chances for blocking / dead-locks.

STATISTICS       * Takes up very little space.    * Cannot help sorts.
                 * Lighter maintenance / won't    * Cannot "cover" queries.
                   slow down DML operations.
                 * Does not increase chances
                   of blocking / dead-locks.

নীচে এমন কিছু সংস্থান রয়েছে যা আমি এটি অনুসন্ধান করার সময় পেয়েছি, এমন একটি যা এমনকি এই একই প্রশ্নটি করে, তবে এর উত্তর দেওয়া হয়নি:

এসকিউএল সার্ভার সূচক বনাম পরিসংখ্যান

এসকিউএল সার্ভারের পরিসংখ্যান প্রশ্নাবলী আমরা জিজ্ঞাসা করতে খুব লজ্জা পেয়েছিলাম

পরিসংখ্যান। মাল্টিকালম হিস্টোগ্রামগুলি কি সম্ভব?

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


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

@ জোনাথানফাইট এই মন্তব্যের জন্য আপনাকে ধন্যবাদ। আমি এটিকে আমার প্রশ্নে অন্তর্ভুক্ত করেছি :)।
সলোমন রুটজকি

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

উত্তর:


19

আপনার প্রশ্নটি ঘুরে দেখা যায় - কখন তৈরি সূচক বনাম পরিসংখ্যান তৈরি করা ভাল জিনিস (যা পরিসংখ্যান তৈরি করে)।

আমার এসকিউএল সার্ভার ইন্টার্নাল নোটগুলি থেকে (এসকিউএলস্কিলস ক্লাস- আইআই 1 এবং আই 2) এবং এসকিউএল সার্ভার ইন্টার্নাল বইটি নীচে আমার সীমিত বোঝার জন্য:

এসকিউএল সার্ভারের পরিসংখ্যানগুলি সিস্টেম অবজেক্টগুলি ছাড়া কিছুই নয় যা ইনডেক্স কী মান এবং নিয়মিত কলাম মান সম্পর্কে গুরুত্বপূর্ণ তথ্য ধারণ করে।

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

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

পরিসংখ্যান সম্পর্কে 2 টি গুরুত্বপূর্ণ বিষয় রয়েছে:

  1. হিস্টগ্রাম কেবলমাত্র বামতম পরিসংখ্যান (সূচি) কলামের জন্য ডেটা বিতরণ সম্পর্কিত তথ্য সঞ্চয় করে। এটি মূল মানগুলির একাধিক কলামের ঘনত্ব সম্পর্কে তথ্য সঞ্চয় করে। সুতরাং মূলত, হিস্টগ্রাম কেবল বামতম পরিসংখ্যান কলামের জন্য ডেটা বিতরণ সঞ্চয় করে।

  2. এসকিউএল সার্ভার সারণী আকার নির্বিশেষে হিস্টোগ্রামে প্রায় 200 টি পদক্ষেপ বজায় রাখবে। প্রতিটি হিস্টগ্রাম ধাপে অন্তর অন্তরগুলি টেবিল বাড়ার সাথে সাথে বৃদ্ধি পায় যা বড় টেবিলগুলির জন্য "কম নির্ভুল" পরিসংখ্যান নিয়ে যায়।

    মনে রাখবেন যে সূচী বাছাইটি একটি মেট্রিক যা ঘনত্বের সাথে বিপরীতভাবে সমানুপাতিক অর্থাৎ একটি কলামের যত বেশি অনন্য মান রয়েছে তত বেশি তার নির্বাচনকেন্দ্রিকতা।

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

তথ্যসূত্র:

দ্রষ্টব্য: পল হোয়াইট বা অ্যারন বার্ট্র্যান্ডের মতো কেউ আপনার ভাল প্রশ্নের আরও রঙ সরবরাহ করতে চিম ইন করতে পারে ।


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

8

আমি বলব যখন আপনাকে ক্ষেত্রের উপর ভিত্তি করে দ্রুত ডেটা পরিমাণ সীমাবদ্ধ করতে / সঠিক ডেটাতে সীমাবদ্ধ করতে সক্ষম হতে হবে তখন আপনাকে একটি সূচি দরকার।

আপনার সম্ভাব্য পরিসংখ্যানগুলি দরকার যখন আপনার সর্বোত্তম উপায়ে অপারেশনগুলি সম্পাদন করতে সক্ষম হওয়ার জন্য ডেটার প্রকৃতিটি বোঝার জন্য অপ্টিমাইজারের প্রয়োজন হয়।

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


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

উদাহরণস্বরূপ, আপনি পোস্টের টেবিলটিতে ব্যবহারকারীর নামের উপর ফিল্টারড সূচক তৈরি করতে পারবেন না কারণ এটি উপস্থিত নেই। আপনি এটি ব্যবহারকারীর আইডির উপর ভিত্তি করে তৈরি করতে পারেন, তবে এটি যেখানে ধারাটিতে নেই not
জেমস জেড

তবে UserIDজিন শর্তে থাকবেনা, এমনকি না থাকলেও WHERE? এবং ফিল্টার ইনডেক্স বাছাই করা কি যথেষ্ট ভাল হবে না?
সলোমন রুটজকি

@ শ্রুতজকি সম্ভবত বর্তমান সংস্করণগুলিতে আরও বেশি সম্ভাবনা রয়েছে তবে সাধারণভাবে আমি তার উপর নির্ভর করব না ... বেশিরভাগ ক্ষেত্রেই পূর্বাভাসগুলি হুবহু মিলে যায়। আমি ভুলে গিয়েছি তারা যদি এটি স্থির করে তবে একটি সময়ে WHERE BitColumn = 0একটি সাধারণ ক্যোয়ারির জন্য একটি ফিল্টারড সূচক নির্বাচন করা হবে না WHERE BitColumn <> 1। (এবং স্পষ্ট করে বললে, বিট কলামটি ন্যায্য ছিল না)) আমি মনে করি মিল IntColumn > 10না করার মতো একই রকম ঘটনাও ছিল IntColumn >= 11
অ্যারন বারট্র্যান্ড

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

4

ইটজিক বেন-গানের 70-461 প্রশিক্ষণ বইটি থেকে

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


এই পোস্ট করার জন্য ধন্যবাদ। এটি আমার প্রশ্নের অংশের উত্তর দেয় তবে এখনও এই প্রশ্নটি খোলে: আমার যদি বহু-কলামের পরিসংখ্যানের প্রয়োজন হয় তবে কেন আমি সূচির পরিবর্তে কেবল সংখ্যাসমূহ তৈরি করব, যাতে সংস্থাগুলি যোগ করবে এবং অতিরিক্ত তথ্য যা ক্যোয়ারিকে আরও সহায়তা করতে পারে ( ies এর)?
সলোমন রুটজকি

1
আমি মনে করি কিনের ব্যাখ্যাটি আপনার পরে কী তা আরও ব্যাখ্যা করবে। সম্ভবত একটি গাদা যা প্রায়শই sertedোকানো হয়, তবে খুব কমই জিজ্ঞাসা করা হয়?
কেন্টারো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.