তথ্য স্থানের চেয়ে সূচী স্থান বড় হওয়া কি খারাপ?


22

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

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

আমি মনে করি না যে তাঁর দর্শন সঠিক, তবে আমি তাকে চ্যালেঞ্জ জানাতে পারি না কারণ তিনি নেতৃত্বের ডিবিএ এবং আমি একজন বিকাশকারী। আমার মনে হয় যদি কোনও ক্যোয়ারির কোনও সূচকের প্রয়োজন হয় তবে "ওয়ার্কআরাউন্ডস" সন্ধানের পরিবর্তে সূচিটি কেবল তৈরি করা উচিত যা কেবল অপঠনযোগ্য এবং অবিস্মরণীয় এসপি তৈরি করে।

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

ডিবিএ আমাকে সূচকের পরিসংখ্যান দেখিয়েছে। সেই টেবিলে প্রায় 10 টি সূচক ছিল, যার মধ্যে কেবল 6 টি ব্যবহার করা হয়েছিল (পরিসংখ্যানগুলি 4 টির কাছে শূন্য হিট দেখিয়েছিল)। এটি একটি বৃহত সিস্টেম যা 20 টিরও বেশি বিকাশকারী অংশগ্রহণ করে। সূচকগুলি যে কোনও কারণেই তৈরি করা হয়েছিল এবং সম্ভবত আর ব্যবহৃত হয়নি।

আমাদের এসকিউএল সার্ভার 2008 সমর্থন করা প্রয়োজন, যেহেতু টেস্টিং ডিবিগুলি চালিত হয়। তবে ক্লায়েন্টগুলি সমস্ত 2014 এবং 2016 এ রয়েছে।

উত্তর:


34

স্লাইডিং সুইচের মতো সূচি নকশার কথা ভাবেন। আপনি যে রেখাটি চান তার সাথে আপনি এই লাল ত্রিভুজ স্যুইচ নকটি যে কোনও জায়গায় সরিয়ে নিতে পারেন:

সূচী ডিজাইনের সিদ্ধান্ত

আমি সাধারণত আকারের ক্ষেত্রে এটি পরিমাপ করি না - আমি সাধারণত সূচির পরিমাণের দিক দিয়ে এটি ভাবি, তবে আকারটিও ভাল হবে।

মনে হচ্ছে আপনার ডিবিএ মনে করে স্যুইচটি ডানদিকে অনেক বেশি চলে গেছে - যে আপনি অনেকগুলি সূচী যুক্ত করেছেন এবং মুছে ফেলা / আপডেটগুলি / সন্নিবেশগুলি খুব ধীরে চলছে performing

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

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

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

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


4

এছাড়াও কোনও টেবিলে "দি ওজার 5" এর বেশি সূচী রাখার আকাঙ্ক্ষা সম্ভবত ইঙ্গিত দেয় যে টেবিলে আপনার কাছে প্রচুর ধরণের পঠন-ভারী প্রশ্ন রয়েছে।

যা সম্ভবত ইঙ্গিত দেয় যে আপনি টেবিলের ক্লাস্টারযুক্ত বা নন-ক্লাস্টারযুক্ত কলামস্টোর সূচী থেকে উপকৃত হতে পারেন ।

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

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


3

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

আপনার কোম্পানির ডিবিএ অবস্থান যদি এই বিষয়টির 'দায়িত্বে' থাকে তবে তারা আপনার প্রশ্নের বিশ্লেষণ করতে পারে এবং আরও ভাল কোয়েরি ডিজাইনের বিষয়ে পরামর্শ দিতে পারে বা পারফরম্যান্সের জন্য উত্তর দিতে পারে।

যদি লক্ষ্যটি অর্জনের জন্য যদি ক্যোয়ারী এবং / বা ডেটা কাঠামো পরিবর্তন করা যায় না তবে আমি মনে করি এটি তিনটি পছন্দ থেকে নেমে আসে।

  1. ধীরে ধীরে তথ্য পুনরুদ্ধার
  2. ধীরে ধীরে ডেটা আপডেট করা
  3. আরও হার্ডওয়ার রিসোর্স $$$$

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


0

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

তবে অনেকগুলি বিষয় বিবেচনা করতে হবে:

  • প্রচুর সূচক সন্নিবেশ / আপডেট / মুছে ফেলা করে। সুতরাং যদি আপনার টেবিলটি অনেক পরিবর্তন হয় তবে সেগুলি খুব বেশি তৈরি না করার বিষয়ে সতর্ক হন।
  • স্থানও সমস্যা হতে পারে। শুধু গিগাবাাইটের জন্য অর্থ ব্যয় করা হয়নি (আজকাল খুব বেশি নয়), তবে ব্যাকআপটি ধীরে ধীরে হবে (ব্যাকআপ কীভাবে হয় তার উপর নির্ভর করে)।
  • সর্বাধিক গুরুতর ডাটাবেসগুলি এমন সূচিপত্রগুলি অনুসন্ধান করতে পর্যবেক্ষণ করা যেতে পারে যা খুব কমই বা কখনও ব্যবহৃত হয় না। তাদের মধ্যে কিছু বাদ দেওয়ার বিষয়টি বিবেচনা করুন।
  • কখনও কখনও আপনি ভাবেন যে আপনার একটি সূচি প্রয়োজন, তবে আপনি যখন আপনার ক্যোয়ারিকে আরও ঘনিষ্ঠভাবে পরীক্ষা করেন তখন এটি একই ফলাফলের সাথে এবং সূচকের প্রয়োজন ছাড়াই আলাদা করে আবার সুর করা যায়। সূচকটি ব্যবহৃত হয়েছে কি না তা দেখার জন্য ব্যাখ্যা পরিকল্পনাটি ব্যবহার করুন।
  • কখনও কখনও শেষ কলামটি গুলি একটি বহু-কলাম সূচী থেকে অনেকগুলি পারফরম্যান্স হিট ছাড়াই বাদ দেওয়া যেতে পারে। এবং কখনও কখনও এটি এমনকি আরও দ্রুততর প্রশ্নগুলি তৈরি করতে পারে কারণ সূচক স্টোরেজ স্পেসটি কম এবং সূচকের বেশিরভাগটি নির্দিষ্ট সময়ে মেমরিতে রাখা / ক্যাশে থাকবে।
  • ফাংশন ভিত্তিক সূচকগুলি আরও স্থান বাঁচাতে সাধারণগুলি প্রতিস্থাপন করতে পারে। উদাহরণ: পূর্ণরূপের জন্য জিজ্ঞাসা না করে প্রথম দুটি বর্ণের জন্যও জিজ্ঞাসা ( where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) এবং create index i on customers(substr(surname,1,2))। এটি যথেষ্ট দ্রুত এবং আপনার সূচকটি আরও কম হবে।
  • ডাটাবেসগুলি বিভিন্ন ধরণের সূচকে সমর্থন করে। কিছু ধরণের অন্যের চেয়ে কম স্থান ব্যবহার করে। হতে পারে আপনার কিছু সূচকে কম স্থান গ্রহণের ধরণে রূপান্তর করা যেতে পারে? প্রথমে সূচকের বিভিন্ন প্রকারগুলি এবং কোন পরিস্থিতিতে তারা ভাল এবং খারাপ understand তা বুঝতে প্রথমে নিশ্চিত হন।
  • যদি খুব কম সময়ের ব্যাচের কাজটিই কেবলমাত্র একটি নির্দিষ্ট সূচকের প্রয়োজন হয় তবে কেবলমাত্র সেই ব্যাচের কাজের জন্য সেই সূচীটি তৈরি করে বিবেচনা করুন এবং পরে এটি ফেলে দিন।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.