একটি সাধারণ সিসিআই রাউগ্রুপ তৈরি করতে কেন এটি 30 সেকেন্ড পর্যন্ত সময় নিতে পারে?


20

আমি সিসিআই জড়িত একটি ডেমোতে কাজ করছিলাম যখন আমি লক্ষ্য করেছি যে আমার কিছু সন্নিবেশ প্রত্যাশার চেয়ে বেশি সময় নিচ্ছে। পুনরুত্পাদন করার জন্য সারণী সংজ্ঞা:

DROP TABLE IF EXISTS dbo.STG_1048576;
CREATE TABLE dbo.STG_1048576 (ID BIGINT NOT NULL);
INSERT INTO dbo.STG_1048576
SELECT TOP (1048576) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

DROP TABLE IF EXISTS dbo.CCI_BIGINT;
CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE);

পরীক্ষার জন্য আমি স্টেজিং টেবিল থেকে সমস্ত 1048576 সারি serোকাচ্ছি। যতক্ষণ না এটি কোনও কারণে ছাঁটাই না করে ঠিক ততক্ষণ একটি সংকুচিত রাউগ্রুপ পূরণ করার জন্য এটি যথেষ্ট।

আমি যদি পূর্ণসংখ্যার মোড 17000 সন্নিবেশ করি তবে এটি একটি সেকেন্ডের চেয়ে কম সময় নেয়:

TRUNCATE TABLE dbo.CCI_BIGINT;

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT ID % 17000
FROM dbo.STG_1048576
OPTION (MAXDOP 1);

এসকিউএল সার্ভার এক্সিকিউশন টাইমস: সিপিইউ সময় = 359 এমএস, অতিবাহিত সময় = 364 এমএস।

যাইহোক, আমি যদি একই সংখ্যার 16000 মোড সন্নিবেশ করি তবে এটি মাঝে মাঝে 30 সেকেন্ডেরও বেশি সময় নেয়:

TRUNCATE TABLE dbo.CCI_BIGINT;

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT ID % 16000
FROM dbo.STG_1048576
OPTION (MAXDOP 1);

এসকিউএল সার্ভার এক্সিকিউশন টাইমস: সিপিইউ সময় = 32062 এমএস, অতিবাহিত সময় = 32511 এমএস।

এটি একটি পুনরাবৃত্তিযোগ্য পরীক্ষা যা একাধিক মেশিনে করা হয়ে থাকে। মোডের মান পরিবর্তনের সাথে সাথে বিচ্ছিন্ন সময়ে একটি স্পষ্ট নিদর্শন বলে মনে হচ্ছে:

MOD_NUM TIME_IN_MS
1000    2036
2000    3857
3000    5463
4000    6930
5000    8414
6000    10270
7000    12350
8000    13936
9000    17470
10000   19946
11000   21373
12000   24950
13000   28677
14000   31030
15000   34040
16000   37000
17000   563
18000   583
19000   576
20000   584

আপনি যদি পরীক্ষা চালাতে চান তবে নিজেকে নির্দ্বিধায় আমি যে টেস্ট কোডটি লিখেছি তা সংশোধন করতে পারেন এখানে ।

16000 inোকানোর জন্য sys.dm_os_wait_stats এ আমি আকর্ষণীয় কিছু খুঁজে পাইনি:

╔════════════════════════════════════╦══════════════╗
║             wait_type              ║ diff_wait_ms ║
╠════════════════════════════════════╬══════════════╣
║ XE_DISPATCHER_WAIT                 ║       164406 ║
║ QDS_PERSIST_TASK_MAIN_LOOP_SLEEP   ║       120002 ║
║ LAZYWRITER_SLEEP                   ║        97718 ║
║ LOGMGR_QUEUE                       ║        97298 ║
║ DIRTY_PAGE_POLL                    ║        97254 ║
║ HADR_FILESTREAM_IOMGR_IOCOMPLETION ║        97111 ║
║ SQLTRACE_INCREMENTAL_FLUSH_SLEEP   ║        96008 ║
║ REQUEST_FOR_DEADLOCK_SEARCH        ║        95001 ║
║ XE_TIMER_EVENT                     ║        94689 ║
║ SLEEP_TASK                         ║        48308 ║
║ BROKER_TO_FLUSH                    ║        48264 ║
║ CHECKPOINT_QUEUE                   ║        35589 ║
║ SOS_SCHEDULER_YIELD                ║           13 ║
╚════════════════════════════════════╩══════════════╝

সন্নিবেশের জন্য সন্নিবেশের ID % 16000তুলনায় এত বেশি সময় নেয় কেন ID % 17000?

উত্তর:


12

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

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

  • মান এনকোডিং (স্কেলিং এবং / অথবা সংখ্যার বিটগুলিতে মান মান অনুবাদ করা)
  • অভিধান এনকোডিং (অনন্য মানগুলির পূর্ণসংখ্যার রেফারেন্স)
  • দৈর্ঘ্য এনকোডিং চালান (বারবারের মানকে [মান, গণনা] জোড়া হিসাবে স্টোর করে)
  • বিট-প্যাকিং (যতটা সম্ভব বিটকে স্ট্রিমটি সঞ্চয় করা)

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

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

ডাব্লুপিএ বিশ্লেষণ

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

সর্বাধিক দীর্ঘ সময়কাল ঘটে যখন rep৪ টি পুনরাবৃত্তি সহ স্বতন্ত্র মানগুলির সর্বাধিক সংখ্যক বৃহত্তর সম্ভাব্য বিভাগে অর্থাৎ 1,048,576 সারিগুলিতে 16,384 টি মানের সাথে 64 টি এন্ট্রি সহ সেট হয় values কোডটি পরিদর্শন ব্যয়বহুল প্রক্রিয়াজাতকরণের জন্য একটি হার্ড-কোডেড সময়সীমা প্রকাশ করে। এটি অন্যান্য ভার্টিপ্যাক বাস্তবায়নের ক্ষেত্রে যেমন এসএসএএস কনফিগার করা যেতে পারে তবে এসকিউএল সার্ভারে যতদূর আমি বলতে পারি তেমন নয়।

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

আরও তথ্যের জন্য, দেখুন:


9

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

প্রথমে আমি সিসিআইতে rোকানো সারিগুলির সংখ্যা পরিবর্তনের চেষ্টা করেছি TOP। আমি ID % 16000সব পরীক্ষার জন্য ব্যবহার করেছি । নীচে সংকুচিত রাউগ্রুপ বিভাগের আকারে সজ্জিত সারিগুলির তুলনায় একটি গ্রাফ দেওয়া আছে:

শীর্ষ বনাম আকারের গ্রাফ

নীচে এমএসে সিপিইউতে সারিগুলির গ্রাফ .োকানো হয়েছে। দ্রষ্টব্য যে এক্স-অক্ষের একটি আলাদা প্রারম্ভিক বিন্দু রয়েছে:

শীর্ষ বনাম সিপিইউ

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

1024000 সারি কম সন্নিবেশ করার সময় আমি সিসিআইতে একটি খোলা সারিগ্রুপ দিয়ে শেষ করেছি। তবে, চাপ প্রয়োগ করে বাধ্য করা REORGANIZEবা REBUILDআকারের উপর কোনও প্রভাব ফেলেনি have TOPঅন্যদিকে , আমি এটি আকর্ষণীয় মনে করেছি যে যখন আমি একটি ভেরিয়েবল ব্যবহার করি তখন আমি একটি খোলা রোগ্রুপের সাথে RECOMPILEশেষ হয়ে যাই তবে আমি একটি বন্ধ সারিগোষ্ঠীর সাথে শেষ করি।

এরপরে আমি সারিগুলির সংখ্যা একই রাখার সময় মডুলাস মানকে পৃথক করে পরীক্ষা করেছি। 102400 সারি সন্নিবেশ করানোর সময় এখানে উপাত্তের একটি নমুনা দেওয়া হয়েছে:

╔═══════════╦═════════╦═══════════════╦═════════════╗
║ TOP_VALUE ║ MOD_NUM ║ SIZE_IN_BYTES ║ CPU_TIME_MS ║
╠═══════════╬═════════╬═══════════════╬═════════════╣
║    102400 ║    1580 ║         13504 ║         352 ║
║    102400 ║    1590 ║         13584 ║         316 ║
║    102400 ║    1600 ║         13664 ║         317 ║
║    102400 ║    1601 ║         19624 ║         270 ║
║    102400 ║    1602 ║         25568 ║         283 ║
║    102400 ║    1603 ║         31520 ║         286 ║
║    102400 ║    1604 ║         37464 ║         288 ║
║    102400 ║    1605 ║         43408 ║         273 ║
║    102400 ║    1606 ║         49360 ║         269 ║
║    102400 ║    1607 ║         55304 ║         265 ║
║    102400 ║    1608 ║         61256 ║         262 ║
║    102400 ║    1609 ║         67200 ║         255 ║
║    102400 ║    1610 ║         73144 ║         265 ║
║    102400 ║    1620 ║        132616 ║         132 ║
║    102400 ║    1621 ║        138568 ║         100 ║
║    102400 ║    1622 ║        144512 ║          91 ║
║    102400 ║    1623 ║        150464 ║          75 ║
║    102400 ║    1624 ║        156408 ║          60 ║
║    102400 ║    1625 ║        162352 ║          47 ║
║    102400 ║    1626 ║        164712 ║          41 ║
╚═══════════╩═════════╩═══════════════╩═════════════╝

রাউগ্রুপ বিভাগের আকারের 1600 অবধি প্রতিটি অতিরিক্ত 10 টি অনন্য মানের জন্য 80 বাইট দ্বারা রৈখিকভাবে বৃদ্ধি হয়। এটি একটি আকর্ষণীয় কাকতালীয় ঘটনা যেBIGINT traditionতিহ্যগতভাবে 8 বাইট নেয় এবং প্রতিটি অতিরিক্ত অনন্য মানের জন্য বিভাগের আকার 8 বাইট বৃদ্ধি পায়। 1600 এর অতীতের একটি আধুনিক মান সেগমেন্টের আকারটি স্থির না হওয়া পর্যন্ত দ্রুত বৃদ্ধি পায়।

মডিউলটিকে একই মান রেখে এবং সন্নিবেশ করা সারিগুলির সংখ্যা পরিবর্তন করার সময় এটি ডেটা দেখতেও সহায়ক helpful

╔═══════════╦═════════╦═══════════════╦═════════════╗
║ TOP_VALUE ║ MOD_NUM ║ SIZE_IN_BYTES ║ CPU_TIME_MS ║
╠═══════════╬═════════╬═══════════════╬═════════════╣
║    300000 ║    5000 ║        600656 ║         131 ║
║    305000 ║    5000 ║        610664 ║         124 ║
║    310000 ║    5000 ║        620672 ║         127 ║
║    315000 ║    5000 ║        630680 ║         132 ║
║    320000 ║    5000 ║         40688 ║        2344 ║
║    325000 ║    5000 ║         40696 ║        2577 ║
║    330000 ║    5000 ║         40704 ║        2589 ║
║    335000 ║    5000 ║         40712 ║        2673 ║
║    340000 ║    5000 ║         40728 ║        2715 ║
║    345000 ║    5000 ║         40736 ║        2744 ║
║    350000 ║    5000 ║         40744 ║        2157 ║
╚═══════════╩═════════╩═══════════════╩═════════════╝

দেখে মনে হচ্ছে সারিগুলির inোকানো সংখ্যা <~ 64 * অনন্য মানের সংখ্যার তুলনায় আমরা তুলনামূলকভাবে দরিদ্র সংক্ষেপণ (মোড <= 65000 এর জন্য প্রতি সারিতে 2 বাইট) এবং কম, লিনিয়ার সিপিইউ ব্যবহার দেখতে পাই। সারিগুলির numberোকানো সংখ্যা> ~ 64 * অনন্য মানের সংখ্যা যখন আমরা আরও বেশি সংকোচনের এবং উচ্চতর দেখতে পাই তবে লিনিয়ার সিপিইউ ব্যবহার। দুটি রাজ্যের মধ্যে একটি রূপান্তর রয়েছে যা মডেল করা আমার পক্ষে সহজ নয় তবে এটি গ্রাফে দেখা যায়। এটি সত্য বলে মনে হয় না যে প্রতিটি অনন্য মানের জন্য ঠিক r৪ টি সারি whenোকানোর সময় আমরা সর্বাধিক সিপিইউ ব্যবহার দেখতে পাই see পরিবর্তে, আমরা কেবলমাত্র একটি সারিগ্রুপে সর্বাধিক 1048576 সারি সন্নিবেশ করতে পারি এবং অনন্য মূল্য প্রতি r৪ টি সারি বেশি হলেই আমরা অনেক বেশি সিপিইউ ব্যবহার এবং সংক্ষেপণ দেখতে পাই।

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

কনট্যুর সিপিইউ

নীচে বিভাগটি দ্বারা ব্যবহৃত স্থানের একটি কনট্যুর প্লট রয়েছে। একটি নির্দিষ্ট বিন্দু পরে আমরা উপরে বর্ণিত হিসাবে আরও ভাল সংক্ষেপণ দেখতে শুরু:

কনট্যুর আকার

দেখে মনে হচ্ছে এখানে কমপক্ষে দুটি পৃথক সংকোচনের অ্যালগরিদম রয়েছে। উপরের দিক থেকে দেওয়া, এটি উপলব্ধি করে যে 1048576 সারি সন্নিবেশ করানোর সময় আমরা সর্বাধিক সিপিইউ ব্যবহার দেখতে পাব। এটি আরও উপলব্ধি করে যে প্রায় 16000 সারি সন্নিবেশ করার সময় আমরা সেই সময়ে সর্বাধিক সিপিইউ ব্যবহার দেখতে পাই। 1048576/64 = 16384।

কেউ এটি বিশ্লেষণ করতে চাইলে আমি আমার সমস্ত কাঁচা ডেটা এখানে আপলোড করেছি।

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

মঞ্চ টেবিলে 2097152 সারি রাখুন:

DROP TABLE IF EXISTS STG_2097152;
CREATE TABLE dbo.STG_2097152 (ID BIGINT NOT NULL);
INSERT INTO dbo.STG_2097152 WITH (TABLOCK)
SELECT TOP (2097152) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

এই সন্নিবেশটি এক সেকেন্ডেরও কম সময়ে শেষ হয়ে যায় এবং এতে কম কম্প্রেশন রয়েছে:

DROP TABLE IF EXISTS dbo.CCI_BIGINT;
CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE);

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT ID % 16000
FROM dbo.STG_2097152 
OPTION (MAXDOP 2);

ভারসাম্যহীন থ্রেডগুলির প্রভাব আমরা দেখতে পারি:

╔════════════╦════════════╦══════════════╦═══════════════╗
║ state_desc ║ total_rows ║ deleted_rows ║ size_in_bytes ║
╠════════════╬════════════╬══════════════╬═══════════════╣
║ OPEN       ║      13540 ║            0 ║        311296 ║
║ COMPRESSED ║    1048576 ║            0 ║       2095872 ║
║ COMPRESSED ║    1035036 ║            0 ║       2070784 ║
╚════════════╩════════════╩══════════════╩═══════════════╝

থ্রেডগুলিকে ভারসাম্যপূর্ণ করতে এবং সারিগুলির একই বন্টন করতে বাধ্য করতে আমরা বিভিন্ন কৌশল করতে পারি। তাদের মধ্যে একটি এখানে:

DROP TABLE IF EXISTS dbo.CCI_BIGINT;
CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE);

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT FLOOR(0.5 * ROW_NUMBER() OVER (ORDER BY (SELECT NULL)))  % 15999
FROM dbo.STG_2097152
OPTION (MAXDOP 2)

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

ভারসাম্য 1

সন্নিবেশটি প্রায় 40 সেকেন্ড সময় নেয় যা সিরিয়াল সন্নিবেশের অনুরূপ। আমরা সুন্দরভাবে সংকুচিত রো-গ্রুপগুলি পাই:

╔════════════╦════════════╦══════════════╦═══════════════╗
║ state_desc ║ total_rows ║ deleted_rows ║ size_in_bytes ║
╠════════════╬════════════╬══════════════╬═══════════════╣
║ COMPRESSED ║    1048576 ║            0 ║        128568 ║
║ COMPRESSED ║    1048576 ║            0 ║        128568 ║
╚════════════╩════════════╩══════════════╩═══════════════╝

মূল স্টেজিং টেবিল থেকে ডেটা byুকিয়ে আমরা একই ফলাফল পেতে পারি:

DROP TABLE IF EXISTS dbo.CCI_BIGINT;
CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE);

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT t.ID % 16000 ID
FROM  (
    SELECT TOP (2) ID 
    FROM (SELECT 1 ID UNION ALL SELECT 2 ) r
) s
CROSS JOIN dbo.STG_1048576 t
OPTION (MAXDOP 2, NO_PERFORMANCE_SPOOL);

এখানে উত্সযুক্ত টেবিলের জন্য গোলাকার রবিন বিতরণ ব্যবহৃত হয় sসুতরাং প্রতিটি সমান্তরাল থ্রেডে টেবিলের একটি স্ক্যান করা হয়:

সুষম 2

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


8

আমি বিশ্বাস করি, এটি একক কলামের টেবিলগুলির জন্য সংক্ষেপণের অভ্যন্তরীণ অপ্টিমাইজেশান এবং অভিধান দ্বারা অধিষ্ঠিত KB৪ কেবি এর যাদুসংখ্যার সাথে সম্পর্কযুক্ত।

উদাহরণ: আপনি এমওডিকে 16600 দিয়ে চালালে রো গ্রুপের আকারের চূড়ান্ত ফলাফল হবে 1.683 মেগাবাইট , এমওডি 17000 চালানো আপনাকে 2.001 এমবি আকারের একটি রো গ্রুপ দেবে ।

এখন, তৈরি করা অভিধানগুলি একবার দেখুন (এর জন্য আপনি আমার সিআইএসএল লাইব্রেরিটি ব্যবহার করতে পারেন , আপনাকে সিস্টোর_গেটডিকোরিয়ালগুলি করতে হবে, অথবা বিকল্পভাবে সিস্টেমে কলাম_স্টোর_ডোমরিও ডিএমভি অনুসন্ধান করতে হবে):

(মোড 16600) 61 কেবি

এখানে চিত্র বর্ণনা লিখুন

(মোড 17000) 65 কেবি

এখানে চিত্র বর্ণনা লিখুন

মজার বিষয়, আপনি যদি নিজের টেবিলে আর একটি কলাম যুক্ত করেন, এবং আসুন এটি কল করুন:

DROP TABLE IF EXISTS dbo.CCI_BIGINT;
CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, REALID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE);

MOD 16600 এর জন্য ডেটা পুনরায় লোড করুন:

TRUNCATE TABLE dbo.CCI_BIGINT;

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT ID % 16600, ID
FROM dbo.STG_1048576
OPTION (MAXDOP 1);

এবার কার্যকর করা দ্রুত হবে, কারণ অপটিমাইজার খুব বেশি বেশি কাজ করা এবং সংকোচনের সিদ্ধান্ত নেবে না:

select column_id, segment_id, cast(sum(seg.on_disk_size) / 1024. / 1024 as Decimal(8,3) ) as SizeInMB
    from sys.column_store_segments seg
        inner join sys.partitions part
            on seg.hobt_id = part.hobt_id 
    where object_id = object_id('dbo.CCI_BIGINT')
    group by column_id, segment_id;

সারি গ্রুপের আকারগুলির মধ্যে একটি সামান্য পার্থক্য থাকলেও, এটি উপেক্ষিত হবে না (2.000 (এমওডি 16600) বনাম 2.001 (এমওডি 17000))

এই দৃশ্যের জন্য, এমওডির 16000 এর জন্য অভিধানটি 1 কলাম (0.63 বনাম 0.61) সহ প্রথম দৃশ্যের চেয়ে বড় হবে।

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