সূচকের স্বতন্ত্রতা ওভারহেড

Question

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

পটভূমি

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

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

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

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

প্রশ্ন

স্বতন্ত্রতার কোনও Insertঅনন্য-অনন্য সূচক বজায় রাখার ব্যয়ের তুলনায় ব্যাক-এন্ডের অতিরিক্ত মূল্য রয়েছে ? দ্বিতীয়ত, স্বতন্ত্রতা নিশ্চিত করতে কোনও সূচকের শেষে টেবিলের প্রাথমিক কী সংযোজনে কোন সমস্যা?

উদাহরণ সারণী সংজ্ঞা

create table #test_index
    (
    id int not null identity(1, 1),
    dt datetime not null default(current_timestamp),
    val varchar(100) not null,
    is_deleted bit not null default(0),
    primary key nonclustered(id desc),
    unique clustered(dt desc, id desc)
    );

create index
    [nonunique_nonclustered_example]
on #test_index
    (is_deleted)
include
    (val);

create unique index
    [unique_nonclustered_example]
on #test_index
    (is_deleted, dt desc, id desc)
include
    (val);

উদাহরণ

আমি কেন Uniqueসূচকের শেষে কীটি যুক্ত করব তার একটি উদাহরণ আমাদের ফ্যাক্ট সারণীতে রয়েছে। একটা হল Primary Keyএকটি যে Identityকলাম। তবে এর Clustered Indexপরিবর্তে পার্টিশন স্কিম কলামটি রয়েছে, তারপরে তিনটি বিদেশী কী মাত্রা রয়েছে যার কোনও স্বাতন্ত্র্য নেই। এই টেবিলটিতে নির্বাচন কর্মক্ষমতা অস্বাভাবিক, এবং আমি প্রায়শই Primary Keyকোনও চাবি অনুসন্ধানের সাথে আরও ভাল ব্যবহারের পরিবর্তে ব্যবহার করার চেয়ে আরও ভাল সময় পাওয়ার চেষ্টা করি Clustered Index। অন্যান্য টেবিলগুলি একই ধরণের নকশা অনুসরণ Primary Keyকরে তবে শেষ পর্যন্ত যুক্ত হয়েছে আরও ভাল পারফরম্যান্স।

-- date_int is equivalent to convert(int, convert(varchar, current_timestamp, 112))
if not exists(select * from sys.partition_functions where [name] = N'pf_date_int')
    create partition function 
        pf_date_int (int) 
    as range right for values 
        (19000101, 20180101, 20180401, 20180701, 20181001, 20190101, 20190401, 20190701);
go

if not exists(select * from sys.partition_schemes where [name] = N'ps_date_int')
    create partition scheme 
        ps_date_int
    as partition 
        pf_date_int all 
    to 
        ([PRIMARY]);
go

if not exists(select * from sys.objects where [object_id] = OBJECT_ID(N'dbo.bad_fact_table'))
    create table dbo.bad_fact_table
        (
        id int not null, -- Identity implemented elsewhere, and CDC populates
        date_int int not null,
        dt date not null,
        group_id int not null,
        group_entity_id int not null, -- member of group
        fk_id int not null,
        -- tons of other columns
        primary key nonclustered(id, date_int),
        index [ci_bad_fact_table] clustered (date_int, group_id, group_entity_id, fk_id)
        )
    on ps_date_int(date_int);
go

if not exists(select * from sys.objects where [object_id] = OBJECT_ID(N'dbo.better_fact_table'))
    create table dbo.better_fact_table
        (
        id int not null, -- Identity implemented elsewhere, and CDC populates
        date_int int not null,
        dt date not null,
        group_id int not null,
        group_entity_id int not null, -- member of group
        -- tons of other columns
        primary key nonclustered(id, date_int),
        index [ci_better_fact_table] clustered(date_int, group_id, group_entity_id, id)
        )
    on ps_date_int(date_int);
go

Answer 1

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

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

স্বতন্ত্রতার কোনও Insertঅনন্য-অনন্য সূচক বজায় রাখার ব্যয়ের তুলনায় ব্যাক-এন্ডের অতিরিক্ত মূল্য রয়েছে ? দ্বিতীয়ত, স্বতন্ত্রতা নিশ্চিত করতে কোনও সূচকের শেষে টেবিলের প্রাথমিক কী সংযোজনে কোন সমস্যা?

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

এমনকি যদি আপনার অনুমান যে প্রয়োগ স্বতন্ত্রতা কোনো অতিরিক্ত ওভারহেড যোগ না সঠিক (যা এটা নয় নির্দিষ্ট ক্ষেত্রে জন্য), আপনি কি অযথা সূচক জটিল দ্বারা সমাধানে হয়?

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

যেমন ডেভিড ব্রাউন একটি মন্তব্যে উল্লেখ করেছেন:

যেহেতু প্রতিটি অবিবাহিত সূচক অনন্য সূচক হিসাবে সংরক্ষণ করা হয়, তাই অনন্য সূচীতে প্রবেশের জন্য কোনও অতিরিক্ত ব্যয় হয় না। প্রকৃতপক্ষে কেবলমাত্র অতিরিক্ত ব্যয় প্রার্থীর কীকে অনন্য সূচক হিসাবে ঘোষণা করতে ব্যর্থ হতে পারে, যার ফলে ক্লাস্টারযুক্ত সূচি কীগুলি সূচক কীগুলিতে সংযুক্ত হবে।

নিম্নলিখিত সর্বনিম্ন সম্পূর্ণ এবং যাচাইযোগ্য উদাহরণ নিন :

USE tempdb;

DROP TABLE IF EXISTS dbo.IndexTest;
CREATE TABLE dbo.IndexTest
(
    id int NOT NULL
        CONSTRAINT IndexTest_pk
        PRIMARY KEY
        CLUSTERED
        IDENTITY(1,1)
    , rowDate datetime NOT NULL
);

আমি দুটি সূচক যুক্ত করব যা দ্বিতীয় সূচকের মূল সংজ্ঞাটির লেজ শেষে প্রাথমিক কী সংযোজন ব্যতীত অভিন্ন হয়:

CREATE INDEX IndexTest_rowDate_ix01
ON dbo.IndexTest(rowDate);

CREATE UNIQUE INDEX IndexTest_rowDate_ix02
ON dbo.IndexTest(rowDate, id);

এরপরে, আমরা টেবিলে কয়েকটি সারি করব:

INSERT INTO dbo.IndexTest (rowDate)
VALUES (DATEADD(SECOND, 0, GETDATE()))
     , (DATEADD(SECOND, 0, GETDATE()))
     , (DATEADD(SECOND, 0, GETDATE()))
     , (DATEADD(SECOND, 1, GETDATE()))
     , (DATEADD(SECOND, 2, GETDATE()));

আপনি উপরে দেখতে পারেন যে তিনটি সারিতে rowDateকলামের জন্য একই মান রয়েছে এবং দুটি সারিতে স্বতন্ত্র মান রয়েছে।

এরপরে, আমরা প্রতিটি সূচকের জন্য ফিজিকাল পৃষ্ঠার কাঠামোটি অননুমোদিত DBCC PAGEকমান্ডটি ব্যবহার করে দেখব :

DECLARE @dbid int = DB_ID();
DECLARE @fileid int;
DECLARE @pageid int;
DECLARE @indexid int;

SELECT @fileid = ddpa.allocated_page_file_id
    , @pageid = ddpa.allocated_page_page_id
FROM sys.indexes i 
CROSS APPLY sys.dm_db_database_page_allocations(DB_ID(), i.object_id, i.index_id, NULL, 'LIMITED') ddpa
WHERE i.name = N'IndexTest_rowDate_ix01'
    AND ddpa.is_allocated = 1
    AND ddpa.is_iam_page = 0;

PRINT N'*************************************** IndexTest_rowDate_ix01 *****************************************';
DBCC TRACEON(3604);
DBCC PAGE (@dbid, @fileid, @pageid, 1);
DBCC TRACEON(3604);
PRINT N'*************************************** IndexTest_rowDate_ix01 *****************************************';

SELECT @fileid = ddpa.allocated_page_file_id
    , @pageid = ddpa.allocated_page_page_id
FROM sys.indexes i 
CROSS APPLY sys.dm_db_database_page_allocations(DB_ID(), i.object_id, i.index_id, NULL, 'LIMITED') ddpa
WHERE i.name = N'IndexTest_rowDate_ix02'
    AND ddpa.is_allocated = 1
    AND ddpa.is_iam_page = 0;

PRINT N'*************************************** IndexTest_rowDate_ix02 *****************************************';
DBCC TRACEON(3604);
DBCC PAGE (@dbid, @fileid, @pageid, 1);
DBCC TRACEON(3604);
PRINT N'*************************************** IndexTest_rowDate_ix02 *****************************************';

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

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

এই বিষয়টি সম্পর্কে ইন্টারভেবিজে বেশ কয়েকটি দুর্দান্ত সংস্থান রয়েছে যার মধ্যে রয়েছে:

• যেখানে ক্লাস্টার্ড সূচকগুলি সাহস করে
• এসকিউএল সার্ভার এবং বাইনারি অনুসন্ধান
• অনন্য সূচকের পারফরম্যান্স বেনিফিট

এফওয়াইআই, কেবল একটি identityকলামের উপস্থিতি স্বতন্ত্রতার গ্যারান্টি দেয় না । সেই কলামে সঞ্চিত মানগুলি সত্যই অনন্য কিনা তা নিশ্চিত করার জন্য আপনাকে কলামটিকে প্রাথমিক কী হিসাবে বা একটি অনন্য বাধা দিয়ে সংজ্ঞায়িত করতে হবে । SET IDENTITY_INSERT schema.table ON;এ বক্তব্যে আপনি কি একটি কলাম হিসাবে সংজ্ঞায়িত মধ্যে অ অনন্য মান সন্নিবেশ করতে অনুমতি দেবে identity।

Answer 2

ম্যাক্সের দুর্দান্ত উত্তরে কেবল একটি অ্যাড-অন ।

যখন এটি কোনও অনন্য ক্লাস্টারযুক্ত সূচক তৈরির কথা আসে, এসকিউএল সার্ভার Uniquifierযেভাবেই পটভূমিতে একটি বলে একটি কিছু তৈরি করে ।

এটি Uniquifierআপনার প্ল্যাটফর্মে প্রচুর সিআরইউডি অপারেশন থাকলে ভবিষ্যতে এটি সম্ভাব্য সমস্যা সৃষ্টি করতে পারে, কারণ Uniquifierএটি কেবল 4 বাইট বিগ (একটি বেসিক 32 বিট পূর্ণসংখ্যা)। সুতরাং, যদি আপনার সিস্টেমে প্রচুর CRUD অপারেশন থাকে তবে আপনি সমস্ত উপলব্ধ অনন্য নম্বর ব্যবহার করতে পারবেন এবং হঠাৎ করেই আপনি একটি ত্রুটি পাবেন এবং এটি আপনাকে আপনার টেবিলগুলিতে আর ডেটা toোকাতে দেবে না (কারণ এটি হবে আপনার নতুন সন্নিবেশ করা সারিগুলিকে নির্ধারণের জন্য আর কোনও অনন্য মান নেই)।

যখন এটি ঘটে, আপনি এই ত্রুটিটি পাবেন:

The maximum system-generated unique value for a duplicate group 
was exceeded for index with partition ID (someID). 

Dropping and re-creating the index may resolve this;
otherwise, use another clustering key.

ত্রুটি 6 666 (উপরের ত্রুটি) তখন ঘটে যখন uniquifierএকক অ-অনন্য কীগুলির একক সেট 2,147,483,647 সারি বেশি ব্যবহার করে।

সুতরাং, আপনার একক কী মানের জন্য 2 বিলিয়ন ডলার সারি থাকা দরকার, অথবা এই ত্রুটিটি দেখতে আপনার একক কী মান ~ 2 বিলিয়ন বার সংশোধন করতে হবে। যেমন, এটি সম্ভবত আপনি এই সীমাবদ্ধতার মধ্যে চলে যাবেন না সম্ভবত not

Comments

আমার কোনও ধারণা ছিল না যে লুকানো ইউনিফাইফায়ার কী স্থানটি ছাড়ে, তবে আমি অনুমান করি যে কোনও কোনও ক্ষেত্রে সমস্ত কিছু সীমাবদ্ধ। অনেকগুলি কীভাবে Caseএবং Ifকাঠামোগুলি 10 টি স্তরের মধ্যে সীমাবদ্ধ, এটি বোধগম্য হয় যে অ-অনন্য অস্তিত্বগুলি সমাধান করারও সীমা রয়েছে। আপনার বক্তব্য অনুসারে, এই শব্দগুলি শোনাতে কেবল তখনই প্রযোজ্য যখন ক্লাস্টারিং কীটি অনন্য is এটি কি Nonclustered Indexকোনওর জন্য সমস্যা বা ক্লাস্টারিং কীটি থাকলে সূচকগুলির Uniqueজন্য কোনও সমস্যা নেই Nonclustered?

— সলোনোটিক্স

একটি অনন্য সূচক কলামের ধরণের আকারের দ্বারা সীমাবদ্ধ (যতদূর আমি জানি) (সুতরাং এটি যদি বিগিন্ট টাইপ হয় তবে আপনার সাথে কাজ করার জন্য 8 বাইট রয়েছে)। এছাড়াও, মাইক্রোসফ্টের অফিশিয়াল ডকুমেন্টেশন অনুসারে, একটি ক্লাস্টারড ইনডেক্সের জন্য সর্বাধিক 900 বিট এবং নন ক্লাস্টারযুক্ত জন্য 1700 বাইট অনুমোদিত (যেহেতু আপনার প্রতি টেবিলে একাধিক নন-ক্লাস্টারড ইনডেক্স এবং কেবল 1 টি ক্লাস্টার ইনডেক্স থাকতে পারে)। ডকস.মাইক্রোসফট.ইন- ইউএস

— এসকিএল-

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

— ম্যাক্স ভার্নন

Answer 3

কোনও সূচকটি অনন্য হওয়া উচিত কিনা এবং এই পদ্ধতির আরও কোনও উপায়ে আছে কিনা তা নিয়ে আমি বিবেচনা করতে যাচ্ছি না। তবে বেশ কয়েকটি জিনিস আপনার সাধারণ নকশায় আমাকে বিরক্ত করেছিল

1. ডিটি ডেটটাইম নাল ডিফল্ট নয় (কারেন্ট_টাইমস্ট্যাম্প)। ডেটটাইম একটি পুরানো ফর্ম বা এটি এবং আপনি ডেটটাইম 2 () এবং সিসডেটটাইম () ব্যবহার করে কমপক্ষে কিছু স্থান সাশ্রয় করতে সক্ষম হতে পারেন।
2. # টেস্ট_ইনডেক্সে (ননুউনিক_নক্লাস্টার্ড_একটি নমুনা) তৈরি করুন (ভাল) অন্তর্ভুক্ত (ভাল)। এটা আমাকে বিরক্ত করে। কীভাবে ডেটা অ্যাক্সেস করতে হবে তা একবার দেখুন (আমি এর চেয়ে আরও বেশি বাজি ধরছি WHERE is_deleted = 0) এবং ফিল্টারড সূচক ব্যবহার করে দেখুন। আমি এমনকি 2 টি ফিল্টার সূচকগুলি ব্যবহার করার বিষয়ে বিবেচনা করব, একটির জন্য where is_deleted = 0এবং অন্যটির জন্যwhere is_deleted = 1

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

Comments

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

— সোনোনটিক্স

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

— টবি

Answer 4

দেখে মনে হচ্ছে বিকল্প, ছোট সূচি তৈরি করতে আপনার কেবল পিকে ব্যবহার হচ্ছে। সুতরাং, এটিতে পারফরম্যান্স দ্রুত হয় faster

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

তবে, একটি গ্রুপের সেই সূচকের কয়েকটি অংশের প্রয়োজন হতে পারে অন্য গ্রুপের অন্যান্য অংশের প্রয়োজন হতে পারে .. সুতরাং সূচকের নীচে প্রতিটি কলামে "পারফরম্যান্স অনুকূলকরণ করতে" সূচি কেবল সত্যই সহায়তা করে না।

এদিকে, একাধিক, ছোট, লক্ষ্যবস্তু সূচকগুলি তৈরি করতে এটি ভেঙে ফেলা প্রায়শই সমস্যার সমাধান করে।

এবং এটি মনে হচ্ছে আপনি যা করছেন। আপনার কাছে দুর্দান্ত পারফরম্যান্স সহ এই বিশাল ক্লাস্টার ইনডেক্স রয়েছে, তারপরে আপনি কম কলাম সহ আরও একটি সূচক তৈরি করতে পিকে ব্যবহার করছেন যা (কোনও আশ্চর্যজনক) উন্নত পারফরম্যান্স নেই।

সুতরাং, কেবল একটি বিশ্লেষণ করুন এবং সুনির্দিষ্ট কাজের প্রয়োজন এমন একক ক্লাস্টারড সূচকটি এটিকে ছোট এবং লক্ষ্যবস্তু সূচকগুলিতে ভেঙে ফেলতে পারেন কিনা তা নির্ধারণ করুন।

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

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

সুতরাং, আপনাকে শেষ-থেকে-শেষের বিশ্লেষণ করতে হবে .. এটি কেবল আপনার নিজের বিশ্বকে কীভাবে প্রভাবিত করে তা নয়, এটি কীভাবে শেষ ব্যবহারকারীদের উপর প্রভাব ফেলে।

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

সুতরাং, একটি পিকে তৈরি করে যা কেবলমাত্র একটি সূচকগুলির মতো কাজ করে .. আপনি আপনার পিকে ব্যবহার করছেন, যা পরে যদি ভূমিকাটির ক্ষেত্রে টেবিলটি প্রসারিত করা হয় তবে প্রয়োজন হতে পারে।

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

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