কমপ্লেক্সের মানদণ্ডের সাথে সূচকের পাঠকে ছোট করা

Question

আমি কাজের টিকিটের একটি ফায়ার বার্ড 2.5 ডাটাবেস অনুকূল করে তুলছি। এগুলি হিসাবে ঘোষিত একটি সারণীতে সংরক্ষণ করা হয়েছে:

CREATE TABLE TICKETS (
  TICKET_ID id PRIMARY KEY,
  JOB_ID id,
  ACTION_ID id,
  STATUS str256 DEFAULT 'Pending'
);

আমি সাধারণত প্রথম টিকিটটি সন্ধান করতে চাই যা প্রক্রিয়াজাত হয়নি এবং Pendingস্থিতিতে রয়েছে।

আমার প্রসেসিং লুপটি হ'ল:

1. যেখানে 1 ম টিকিট পুনরুদ্ধার করুন Pending
2. টিকিট নিয়ে কাজ করুন।
3. টিকিটের স্থিতি => আপডেট করুন Complete
4. পদ্ধতি পুনরাবৃত্তি করুন।

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

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

- মন্তব্যের জন্য সম্পাদনা -

ফায়ারবার্ডে আপনি সারি পুনরুদ্ধারটিকে সীমাবদ্ধ করেছেন:

Select First 1
  Job_ID, Ticket_Id
From
  Tickets
Where
  Status = 'Pending'

সুতরাং যখন আমি "প্রথম" বলি, আমি কেবল এটির সীমাবদ্ধ রেকর্ডের জন্য জিজ্ঞাসা করি Status = 'Pending'।

Comments

"প্রথম" টিকিটটি 'পেন্ডিং' যেখানে "পুনরুদ্ধার করুন " এর মধ্যে "প্রথম" দিয়ে আপনি কী বোঝাতে চাইছেন ?

— ypercubeᵀᴹ

যদি "প্রথম " ticket_idটির অর্থ ক্ষুদ্রতম হয় তবে আপনার সম্ভাব্যতার উপর একটি সূচি দরকার(status, ticket_id)

— ypercubeᵀᴹ

এবং আপনি কতটা নিশ্চিত যে পারফরম্যান্স অবক্ষয় এই প্রক্রিয়া দ্বারা এবং অন্যান্য অনুসন্ধান / বিবৃতি দ্বারা নয়?

— ypercubeᵀᴹ

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

— gddc

Is id(ডাটা টাইপ) একটি ডোমেইন আপনি সংজ্ঞায়িত?

— a_horse_with_no_name

Answer 1

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

এসকিউএল সার্ভারে (এবং সম্ভবত অন্য আরডিবিএমএস এর?), ফিল্টার সূচকগুলি ব্যবহার করে এটি প্রায় কাজ করা যেতে পারে। এসকিউএল সার্ভারে আপনি আপনার সূচক সংজ্ঞাটির শেষে একটি শর্ত যুক্ত করবেন "এই স্ট্যাটাসটি <> 'সম্পূর্ণ' রেকর্ডে কেবল এই সূচিটি প্রয়োগ করুন। তারপরে এই প্রাকটিকেট ব্যবহার করে যে কোনও ক্যোয়ারী সম্ভবত 'সম্পূর্ণ' তে সেট করা হয়নি এমন স্বল্প পরিমাণের রেকর্ডে সূচক ব্যবহার করবে। তবে এখানে ডকুমেন্টেশনের ভিত্তিতে: http://www.firebirdsql.org/refdocs/langrefupd25-ddl-index.html , এটি ফায়ারবার্ড ফিল্টারড সূচকগুলিকে সমর্থন করে বলে মনে হচ্ছে না।

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

আপনার উত্পাদনটি কয়েক হাজার সারিতে যেতে চাইলে আপনার এই সম্পর্কে উদ্বিগ্ন হওয়া উচিত। পারফরম্যান্স সময়ের সাথে সাথে হ্রাস পাবে এবং আপনার ব্যবহারকারীর অভিজ্ঞতার উপর নেতিবাচক প্রভাব ফেলবে।

Answer 2

পারফরম্যান্সে প্রভাবিত কিনা বা না তা হ'ল ডেটা ভলিউম এবং মেশিনের ক্ষমতা। আধুনিক হার্ডওয়্যারটির সক্ষমতা দেওয়া, টিকিট বিক্রয় ভলিউমটি কল্পনা করা আপনার পক্ষে নকশাকৃত নকশার দ্বারা পরিচালনা করা যায় না imagine তবে, এমন কিছু পরিবর্তন রয়েছে যা আমি শুদ্ধতার জন্য সুপারিশ করব এবং এটি গৌণ সুবিধা হিসাবে কর্মক্ষমতা উন্নত করতে পারে।

আপনার প্রাপ্ত প্রথম মুলতুবি ক্যোয়ারী অ-নিরস্তক is প্রথমে কোন আদেশ অনুসারে? একটি এসকিউএল টেবিলের কোনও অভ্যন্তরীণ ক্রম নেই; First 1হ্যাক শুধু আপনার দিচ্ছেন কিছু নির্বিচারে প্রথম এক। এটিকে নির্বিচারে তৈরি করতে, চাকরি_আইডি ক্রমে মুলতুবি কাজগুলিকে কেন প্রক্রিয়া করবেন না?

আপনার যদি দুটি সূচক থাকে {জব_আইডি} এবং {স্থিতি, জব_আইডি}, এই ক্যোয়ারিতে একটি সারিতে পূর্বাভাস এবং দক্ষতার সাথে ফিরে আসবে:

Select Job_ID, Ticket_Id
From   Tickets
Where Job_ID = ( 
  select min(Job_ID) from Tickets 
  where Status = 'Pending'
);

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

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

CREATE TABLE TICKETS (
  TICKET_ID id PRIMARY KEY,
  JOB_ID id,
  ACTION_ID id,
  STATUS char(1) not NULL 
     DEFAULT 'P'
     CHECK( STATUS in ('P', 'C', 'X') ) -- whatever the domain is
);

অবশ্যই, আপনি স্থিতির জন্য ক্যানোনিকাল স্ট্রিং সরবরাহ করতে একটি দর্শন (বা সম্ভবত কোনও উত্পন্ন কলাম) ব্যবহার করতে পারেন।