এসকিউএল সার্ভার দুটি সমতুল্য বিভাজনযুক্ত টেবিলগুলিতে সমান্তরাল মার্জ জোড়কে অনুকূলিত করে না


21

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

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

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

এই সমস্যাটি পুনরুত্পাদন করতে একটি সরলিকৃত ডেটা সেট আপ করতে এসকিউএল এখানে রয়েছে:

/* Create the first test data table */
CREATE TABLE test_transaction_properties 
    ( transactionID INT NOT NULL IDENTITY(1,1)
    , prop1 INT NULL
    , prop2 FLOAT NULL
    )

/* Populate table with pseudo-random data (the specific data doesn't matter too much for this example) */
;WITH E1(N) AS (
    SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 
    UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
)
, E2(N) AS (SELECT 1 FROM E1 a CROSS JOIN E1 b)
, E4(N) AS (SELECT 1 FROM E2 a CROSS JOIN E2 b)
, E8(N) AS (SELECT 1 FROM E4 a CROSS JOIN E4 b)
INSERT INTO test_transaction_properties WITH (TABLOCK) (prop1, prop2)
SELECT TOP 10000000 (ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) % 5) + 1 AS prop1
                , ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) * rand() AS prop2
FROM E8

/* Create the second test data table */
CREATE TABLE test_transaction_item_detail
    ( transactionID INT NOT NULL
    , productID INT NOT NULL
    , sales FLOAT NULL
    , units INT NULL
    )

 /* Populate the second table such that each transaction has one or more items
     (again, the specific data doesn't matter too much for this example) */
INSERT INTO test_transaction_item_detail WITH (TABLOCK) (transactionID, productID, sales, units)
SELECT t.transactionID, p.productID, 100 AS sales, 1 AS units
FROM test_transaction_properties t
JOIN (
    SELECT 1 as productRank, 1 as productId
    UNION ALL SELECT 2 as productRank, 12 as productId
    UNION ALL SELECT 3 as productRank, 123 as productId
    UNION ALL SELECT 4 as productRank, 1234 as productId
    UNION ALL SELECT 5 as productRank, 12345 as productId
) p
    ON p.productRank <= t.prop1

/* Divides the transactions evenly into 10 partitions */
CREATE PARTITION FUNCTION [pf_test_transactionId] (INT)
AS RANGE RIGHT
FOR VALUES
(1,1000001,2000001,3000001,4000001,5000001,6000001,7000001,8000001,9000001)

CREATE PARTITION SCHEME [ps_test_transactionId]
AS PARTITION [pf_test_transactionId]
ALL TO ( [PRIMARY] )

/* Apply the same partition scheme to both test data tables */
ALTER TABLE test_transaction_properties
ADD CONSTRAINT PK_test_transaction_properties
PRIMARY KEY (transactionID)
ON ps_test_transactionId (transactionID)

ALTER TABLE test_transaction_item_detail
ADD CONSTRAINT PK_test_transaction_item_detail
PRIMARY KEY (transactionID, productID)
ON ps_test_transactionId (transactionID)

এখন আমরা অবশেষে উপ-অনুকূল কোয়েরিটি পুনরুত্পাদন করতে প্রস্তুত!

/* This query produces a HASH JOIN using 20 threads without the MAXDOP hint,
    and the same behavior holds in that case.
    For simplicity here, I have limited it to 10 threads. */
SELECT COUNT(*)
FROM test_transaction_item_detail i
JOIN test_transaction_properties t
    ON t.transactionID = i.transactionID
OPTION (MAXDOP 10)

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

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

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

SELECT COUNT(*)
FROM test_transaction_item_detail i
INNER MERGE JOIN test_transaction_properties t
    ON t.transactionID = i.transactionID
WHERE t.transactionID BETWEEN 1 AND 1000000
OPTION (MAXDOP 1)

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

উত্তর:


18

আপনি ঠিক বলেছেন যে এসকিউএল সার্ভার অপ্টিমাইজার সমান্তরাল MERGEযোগদানের পরিকল্পনাগুলি উত্পন্ন না করা পছন্দ করে (এটি বিকল্পটির জন্য বেশ উচ্চতর ব্যয় করে)। সমান্তরালে MERGEসর্বদা উভয় যোগদানের ইনপুটগুলিতে পুনরায় বিভাজন বিনিময় প্রয়োজন এবং আরও গুরুত্বপূর্ণ এটির জন্য সারি ক্রমটি সেই এক্সচেঞ্জগুলিতে সংরক্ষণ করা দরকার requires

সমান্তরালতা সবচেয়ে কার্যকর যখন প্রতিটি থ্রেড স্বতন্ত্রভাবে চলতে পারে; অর্ডার সংরক্ষণের ফলে প্রায়শই প্রায়শই সিঙ্ক্রোনাইজেশন অপেক্ষার দিকে পরিচালিত হয় এবং অবশেষে tempdbএকটি আন্তঃ-কোয়েরি অচলাবস্থার পরিস্থিতি সমাধান করতে এক্সচেঞ্জগুলি ছড়িয়ে দিতে পারে।

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

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

মেটাডেটা থেকে পার্টিশন নম্বর প্রাপ্তি যথেষ্ট সহজ:

DECLARE @P AS TABLE
(
    partition_number integer PRIMARY KEY
);

INSERT @P (partition_number)
SELECT
    p.partition_number
FROM sys.partitions AS p 
WHERE 
    p.[object_id] = OBJECT_ID(N'test_transaction_properties', N'U')
    AND p.index_id = 1;

তারপরে আমরা এই সংখ্যাগুলি একটি সংযুক্ত জোড় ( APPLY) চালানোর জন্য এবং $PARTITIONপ্রতিটি থ্রেড বর্তমান পার্টিশন সংখ্যায় সীমাবদ্ধ করতে ব্যবহার করি:

SELECT
    row_count = SUM(Subtotals.cnt)
FROM @P AS p
CROSS APPLY
(
    SELECT
        cnt = COUNT_BIG(*)
    FROM dbo.test_transaction_item_detail AS i
    JOIN dbo.test_transaction_properties AS t ON
        t.transactionID = i.transactionID
    WHERE 
        $PARTITION.pf_test_transactionId(t.transactionID) = p.partition_number
        AND $PARTITION.pf_test_transactionId(i.transactionID) = p.partition_number
) AS SubTotals;

ক্যোয়ারী পরিকল্পনাটি MERGEসারণীতে প্রতিটি সারির জন্য একটি যোগদানের দেখায় @P। ক্লাস্টারড ইনডেক্স স্ক্যান বৈশিষ্ট্যগুলি নিশ্চিত করে যে প্রতিটি পুনরাবৃত্তিতে কেবলমাত্র একটি একক পার্টিশন প্রক্রিয়া করা হয়:

সিরিয়াল পরিকল্পনা প্রয়োগ করুন

দুর্ভাগ্যক্রমে, এটি কেবলমাত্র পার্টিশনের ক্রমিক ক্রিয়াকলাপের ফলাফল। আপনার সরবরাহিত ডেটা সেটটিতে, আমার 4-কোর (হাইপারথ্রেডেড 8 এ) ল্যাপটপ মেমরির সমস্ত ডেটা সহ 7 সেকেন্ডে সঠিক ফলাফলটি দেয় ।

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

SELECT
    row_count = SUM(Subtotals.cnt)
FROM @P AS p
CROSS APPLY
(
    SELECT
        cnt = COUNT_BIG(*)
    FROM dbo.test_transaction_item_detail AS i
    JOIN dbo.test_transaction_properties AS t ON
        t.transactionID = i.transactionID
    WHERE 
        $PARTITION.pf_test_transactionId(t.transactionID) = p.partition_number
        AND $PARTITION.pf_test_transactionId(i.transactionID) = p.partition_number
) AS SubTotals
OPTION (QUERYTRACEON 8649);

এখন ক্যোয়ারী প্ল্যানটি @Pবৃত্তাকার নম্বরগুলি রাউন্ড-রবিন ভিত্তিতে থ্রেডগুলির মধ্যে বিতরণ করা থেকে দেখায় । প্রতিটি থ্রেড একক পার্টিশনের জন্য নেস্টেড লুপগুলির অভ্যন্তরীণ দিকটি চালায়, একই সাথে ডেটা বিচ্ছিন্ন করার প্রক্রিয়া করার আমাদের লক্ষ্য অর্জন করে। একই সাথে এখন আমার 8 টি হাইপার কোরগুলিতে 3 সেকেন্ডে ফিরে আসবে , সমস্ত আটটিতে 100% ব্যবহার রয়েছে।

সমান্তরাল আবেদন

আমি আপনাকে এই কৌশলটি প্রয়োজনীয়ভাবে ব্যবহার করার পরামর্শ দিচ্ছি না - আমার আগের সতর্কতাগুলি দেখুন - তবে এটি আপনার প্রশ্নের সমাধান করে।

পার্টিশনযুক্ত টেবিলটি উন্নত করার জন্য আমার নিবন্ধটি দেখুন আরও তথ্যের জন্য পারফরম্যান্সে যোগদান করুন।

Columnstore

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

CREATE NONCLUSTERED COLUMNSTORE INDEX cs 
ON dbo.test_transaction_properties (transactionID);

CREATE NONCLUSTERED COLUMNSTORE INDEX cs 
ON dbo.test_transaction_item_detail (transactionID);

এই সূচীগুলি কোয়েরিতে রাখুন ...

SELECT
    COUNT_BIG(*)
FROM dbo.test_transaction_properties AS ttp
JOIN dbo.test_transaction_item_detail AS ttid ON
    ttid.transactionID = ttp.transactionID;

... কোনও চালাকি ছাড়াই অপ্টিমাইজার থেকে নিম্নলিখিত সম্পাদন পরিকল্পনার ফলাফল:

কলামস্টোর প্ল্যান 1

2 সেকেন্ডের মধ্যে সঠিক ফলাফল , তবে স্কেলার সমষ্টিতে সারি-মোড প্রসেসিং অপসারণ আরও আরও সহায়তা করে:

SELECT
    COUNT_BIG(*)
FROM dbo.test_transaction_properties AS ttp
JOIN dbo.test_transaction_item_detail AS ttid ON
    ttid.transactionID = ttp.transactionID
GROUP BY
    ttp.transactionID % 1;

অনুকূল কলাম স্টোর

অনুকূলিত কলাম-স্টোর ক্যোয়ারী 851 মিমিগুলিতে চলে

জেফ প্যাটারসন পার্টিশন ওয়াইজ যোগ দিয়ে বাগ রিপোর্ট তৈরি করেছিলেন তবে এটি উইন্ট ফিক্স হিসাবে বন্ধ হয়ে গিয়েছিল।


5
এখানে দুর্দান্ত শেখার অভিজ্ঞতা। ধন্যবাদ. +1
এডওয়ার্ড ডর্টল্যান্ড

1
ধন্যবাদ পল! এখানে দুর্দান্ত তথ্য, এবং এটি অবশ্যই বিস্তারিতভাবে প্রশ্নের সমাধান করে।
জেফ প্যাটারসন

2
ধন্যবাদ পল! এখানে দুর্দান্ত তথ্য, এবং এটি অবশ্যই বিস্তারিতভাবে প্রশ্নের সমাধান করে। আমরা একটি মিশ্র এসকিউএল ২০০৮ / ২০১২ পরিবেশে আছি, তবে ভবিষ্যতের জন্য আমি কলাম-স্টোর অন্বেষণের বিষয়টি বিবেচনা করব। অবশ্যই, আমি এখনও চাই যে এসকিউএল সার্ভার কার্যকরভাবে একটি সমান্তরাল মার্জ জোনের সুবিধা অর্জন করতে পারে - এবং এটির ব্যবহারের ক্ষেত্রে খুব কম মেমরির প্রয়োজনীয়তা থাকতে পারে :) যদি কেউ নজর দিন এবং মন্তব্য করতে যত্নবান না হন তবে আমি নিম্নলিখিত সংযোগ ইস্যুটি দায়ের করেছি বা এটিতে ভোট দিন: কানেক্ট করুন.মাইক্রোসফট
জেফ প্যাটারসন

0

অপ্টিমাইজারটিকে যেভাবে আপনি আরও ভাল মনে করেন সেভাবে কাজ করার উপায়টি ক্যোয়ারী ইঙ্গিতগুলির মাধ্যমে।

এক্ষেত্রে, OPTION (MERGE JOIN)

অথবা আপনি পুরো হোগে গিয়ে ব্যবহার করতে পারেন USE PLAN


আমি ব্যক্তিগতভাবে এটি করব না: ইঙ্গিতটি কেবলমাত্র বর্তমান ডেটা ভলিউম এবং বিতরণের জন্য কার্যকর হবে।
gbn

মজার বিষয় হ'ল অপশন (মার্জিন জয়েন) ব্যবহারের ফলে আরও খারাপ পরিকল্পনার ফলস্বরূপ। অপ্টিমাইজারটি বুঝতে পারার পক্ষে যথেষ্ট স্মার্ট নয় যে পার্টিশনের ক্রিয়াকলাপটি দিয়ে মার্জ যোগ যোগ হতে পারে এবং এই ইঙ্গিতটি প্রয়োগ করে ক্যোরিয়াকে ~ 46 সেকেন্ড সময় লাগে। খুবই হতাশাজনক!

@gbn যা সম্ভবতঃ হ্যাশটির জন্য অপ্টিমাইজারটি কেন প্রথম স্থানে যোগদান করবে?

@ জিপটারসন কত বিরক্তিকর! :)

আপনি যদি ইউনিয়নের মাধ্যমে ম্যানুয়ালি পার্টিশনটি জোর করে (তবে: আপনার সংক্ষিপ্ত ক্যোয়ারী অন্যান্য অনুরূপ প্রশ্নের সাথে মিলিত হয়) তবে কী হবে?
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.