কোয়েরি টিউনিং কি কার্যক্ষম বা প্রতিক্রিয়াশীল হওয়া উচিত?


23

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

তবে, অন্য যে কোনও সফ্টওয়্যার বিকাশকারীর মতোই এখানে কার্যকারিতা, বাগগুলি এবং প্রয়োজনীয় পরিবর্তনগুলি রয়েছে যা পরিবর্তিত / তৈরি ডাটাবেস অবজেক্টগুলির দাবি করে।

আমার প্রশ্ন হ'ল ক্যোরি টিউনিংটি কি কার্যক্ষম বা প্রতিক্রিয়াশীল হওয়া উচিত? অন্য কথায়, কিছু ভারী কোড / ডাটাবেস পরিবর্তনের কয়েক সপ্তাহ পরে, আমি কি কোয়েরি পারফরম্যান্স এবং তার ভিত্তিতে টিউনটি পরীক্ষা করার জন্য একটি দিন রেখেছি? মনে হচ্ছে ঠিক চলছে কিনা ?

বা আমার কি কেবল সচেতন হওয়া উচিত যে গড়-গড়ের চেয়ে কম পারফরম্যান্স একটি ডেটাবেস চেক হওয়া উচিত এবং প্রবাদ বাকরি চকবোর্ডে ফিরে যাওয়া উচিত?

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


7
অকাল অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল - ডোনাল্ডকনুথ
ড্রেসিল

@ ড্রসিল, আপনি কি দয়া করে এটি প্রসারিত করতে পারেন? খারাপ সময় নষ্ট হিসাবে?
থমাস স্ট্রিংগার

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

এছাড়াও এই বিষয়ে একটি পুরানো কোডিং হরর পোস্ট দেখুন :)
ড্রাসিল

উত্তর:


17

উভয়, কিন্তু বেশিরভাগই সক্রিয়

বাস্তববাদী ভলিউম এবং ডেটার গুণমানের বিরুদ্ধে বিকাশের সময় এটি পরীক্ষা করা গুরুত্বপূর্ণ। বিকাশকারীদের 100 বা 1000 টি সারিতে একটি ক্যোয়ারী চালানো অবিশ্বাস্যরকম সাধারণ এবং তারপরে 10 মিলিয়ন উত্পাদন সারি দিয়ে ফ্ল্যাট পড়ে।

এটি আপনাকে "সূচি এখানে সহায়তা করতে পারে" সম্পর্কে নোট তৈরি করতে দেয়। অথবা "আমাকে পুনর্বিবেচনা করুন"। অথবা "পরবর্তী ডিবি সংস্করণে নতুন বৈশিষ্ট্য xxx সহ ঠিক করবে"।

তবে কয়েকটি প্রশ্ন সময়ের পরীক্ষায় দাঁড়াবে না। ডেটা বিতরণ পরিবর্তন হয় বা এটি তাত্পর্যপূর্ণ হয় কারণ অপটিমাইজার একটি পৃথক যোগদানের ধরণ ব্যবহার করার সিদ্ধান্ত নেয়। এই ক্ষেত্রে, আপনি কেবল প্রতিক্রিয়া জানাতে পারেন।

এই বলে যে এসকিউএল সার্ভারের জন্য কমপক্ষে, বিভিন্ন "অনুপস্থিত সূচী" এবং "দীর্ঘতম কোয়েরি" ডিএমভি ক্যোয়ারী ফোন কলের আগে সমস্যার ক্ষেত্রগুলি নির্দেশ করতে পারে

সম্পাদনা করুন: স্পষ্ট করতে ...

প্র্যাকটিভ মানে এখন প্রতিটি প্রশ্নের সাথে টিউন করা উচিত নয়। এর অর্থ একটি যুক্তিসঙ্গত প্রতিক্রিয়ার সময় আপনার (ঘন ঘন চালানো) দরকার une বেশিরভাগই সাপ্তাহিক 3am রবিবার রিপোর্ট প্রশ্নের উপেক্ষা করুন।


16

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

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

যখন আপনি জানতে পারেন যে কোনও কিছু আপনার নকশার চশমাগুলি সম্পাদন করছে না, বা যদি আপনার প্রোফাইলের প্রতিক্রিয়া বারের তালিকার 10% বা 20% নীচে নেমে যাচ্ছে, তবে আপনার যা যা কিছু হোক তা টুইঙ্ক করার জন্য যে সময়টি প্রয়োজন তা বিনিয়োগ করুন ভাঙ্গা।

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


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

4
হারুন, সম্মত হয়েছেন - কখনও পারফরম্যান্স-ভিত্তিক এমন কিছু সরবরাহ করবেন না যা পারফরম্যান্স এবং স্কেলিবিলিটি সম্পর্কে কঠোর চিন্তা না করে কোনও কিছু গ্রহণ করবে না এবং তৈরি করবে না। "দু'বার পরিমাপ করুন, একবার কাটুন" প্রোগ্রামারদের বাম্পার স্টিকারগুলির উপর নির্ভর করে যতটা এটি কর্পোরদের উপর '। একই সময়ে, আমি অনুভব করেছি যে অন্যান্য উত্তরের সাধারণ টেনারটি "প্রক্রিয়াকরণ> প্রতিক্রিয়াশীল" এবং আমি অনুভব করেছি যে "বাস্তবতা == প্রতিক্রিয়াশীল" এবং তাই কীটি এত বেশি সময় নষ্ট না করার মত একটি নীচের প্রতিনিধিত্বিত মতামত রয়েছে ক্রিয়াশীল হচ্ছেন যে কঠোর, প্রায়শই অনাকাঙ্ক্ষিত বাস্তবতার সাথে মোকাবিলা করার জন্য আপনার কাছে সময় বা অর্থ অবশিষ্ট নেই।
জোয়েল ব্রাউন

15

আপনি 3 ধরণের টিউনিং, ১ টি প্রতিক্রিয়াশীল এবং ২ টি প্র্যাকটিভ করতে যাচ্ছেন।

প্রতিক্রিয়াশীল

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

প্ররোচক

প্রকার 1: রুটিন রক্ষণাবেক্ষণ

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

প্রকার 2: সঠিক নকশা

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

সুতরাং ডিবিএ জমিতে অকাল অপটিমাইজেশন হিসাবে কী যোগ্যতা অর্জন করবে? আমার তালিকার শীর্ষে কোনও প্রদর্শিত প্রয়োজন ছাড়াই স্বাভাবিককরণের ত্যাগ করতে হবে। নিশ্চিত যে আপনি সন্তানের সারি থেকে রানটাইম সময়ে এটি গণনা করার চেয়ে পিতামাতার সারিতে একটি যোগফল বজায় রাখতে পারবেন তবে আপনার কি সত্যিই প্রয়োজন? আপনি যদি টুইটার বা অ্যামাজন হন তবে কৌশলগত ডি-নরমালাইজেশন এবং প্রাক-গণনা আপনার সেরা বন্ধু হতে পারে। আপনি যদি 5 জন ব্যবহারকারীর জন্য একটু অ্যাকাউন্টিং ডেটাবেস ডিজাইন করেন তবে ডেটা অখণ্ডতার সুবিধার জন্য উপযুক্ত কাঠামোটিকে সর্বোচ্চ অগ্রাধিকার দেওয়া দরকার। অন্যান্য অকাল অপটিমাইজেশন একইভাবে অগ্রাধিকারের বিষয়। দিনে একবার চালানো হয় এবং 10 সেকেন্ড সময় নেয় এমন ক্যোয়ারী টিকেট করার জন্য ঘন্টা ব্যয় করবেন না, এমনকি যদি আপনি মনে করেন যে আপনি এটি 0.1 সেকেন্ডে কাটতে পারেন। হয়তো আপনার একটি প্রতিবেদন রয়েছে যা প্রতিদিন 6 ঘন্টা চালিত হয়, তবে এটির টিউনিংয়ে সময় বিনিয়োগের আগে এটি একটি ব্যাচের কাজ হিসাবে সময় নির্ধারণ করে। যদি আপনার উত্পাদন বোঝা কখনই 10% এর উপরে না ভরে থাকে (ধরে নিলে আপনি সুরক্ষাটি পরিচালনা করতে পারেন) কোনও পৃথক, রিয়েল-টাইম প্রতিলিপিযুক্ত প্রতিবেদনে বিনিয়োগ করবেন না।

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

(এবং আপনি যখন এটির সময়ে, পরিসংখ্যান শিখুন! )


প্রোপার ডিজাইনটি পারফরম্যান্স এবং স্কেলাবিলিটির 95%।
মার্ক স্টুয়ার্ট

6

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

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


5

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

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

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