How many bi weeks in 2023

Độc giả của chúng tôi biết vị trí của SQLBI trên các mối quan hệ hai chiều. chúng là một công cụ mạnh mẽ nên được sử dụng hết sức cẩn thận hoặc tránh sử dụng hoàn toàn trong hầu hết các tình huống. Thực sự có một kịch bản trong đó các mối quan hệ hai chiều hữu ích. khi bạn cần tạo một mô hình liên quan đến mối quan hệ nhiều-nhiều giữa các thứ nguyên. Trong trường hợp này, sử dụng mối quan hệ bộ lọc hai chiều là giải pháp được đề xuất. Tuy nhiên, một trong những lý do khiến mối quan hệ hai chiều không thể được tạo ra có thể là sự mơ hồ. Nếu bạn đang đối mặt với tình huống này, bạn có thể sử dụng một kỹ thuật lập mô hình khác dựa trên mối quan hệ lực lượng nhiều-nhiều hạn chế, sẽ hoạt động ngay cả khi nó được đặt là mối quan hệ đơn hướng. Sự lựa chọn giữa hai mô hình là không dễ dàng để thực hiện. Cả hai đều có những ưu điểm và nhược điểm cần được hiểu sâu để đưa ra quyết định đúng đắn

Trong bài viết này, trước tiên chúng tôi cung cấp mô tả về hai kỹ thuật, sau đó chúng tôi tiến hành phân tích hiệu suất của cả hai giải pháp, để cung cấp thông tin chi tiết về việc sử dụng kỹ thuật nào và khi nào.

Kịch bản

Trong cơ sở dữ liệu Contoso, không có mối quan hệ nhiều-nhiều. Do đó, chúng tôi đã tạo mối quan hệ nhiều-nhiều giữa Khách hàng và các bảng Thể thao. Chúng tôi chỉ định cho mỗi khách hàng một số môn thể thao nhất định mà họ chơi. Vì mỗi khách hàng có thể chơi nhiều môn thể thao và mỗi môn thể thao có thể được chơi bởi nhiều khách hàng nên mối quan hệ tự nhiên giữa khách hàng và thể thao là mối quan hệ nhiều-nhiều

Cách kinh điển để mô hình hóa mối quan hệ này được hiển thị bên dưới

Bộ lọc từ Thể thao chảy đến CustomerSport, sau đó nó đi qua mối quan hệ hai chiều đến Khách hàng để cuối cùng đến Doanh số bán hàng. Bằng cách sử dụng mô hình này, bạn có thể chia Doanh số bán hàng theo Thể thao, do đó có được hành vi nhiều-nhiều thông thường không phụ gia. Đây là cách chúng tôi đã dạy về mối quan hệ nhiều-nhiều trong nhiều năm qua

Gần đây, chúng tôi đã thảo luận về một tùy chọn khả thi khác để mô hình hóa tình huống này bằng cách sử dụng các mối quan hệ cardinality nhiều-nhiều hạn chế

Mô hình thứ hai này hấp dẫn hơn về mặt trực quan và nó không yêu cầu các mối quan hệ hai chiều – điều phù hợp nhất. Bộ lọc từ Khách hàng hoặc Thể thao trước tiên được áp dụng cho CustomerSport và sau đó được chuyển sang Bán hàng thông qua mối quan hệ nhiều bộ lọc chéo

Do không có mối quan hệ hai chiều trong mô hình này, mô hình chắc chắn linh hoạt hơn mô hình trước. Điều đó nói rằng, nó cũng tốt hơn hoặc ít nhất là tương đương về hiệu suất? . Mô hình thứ hai này tạo ra các kế hoạch truy vấn khác nhau có thể tốt hơn trong một số tình huống và không tốt trong các tình huống khác. Tất cả phụ thuộc vào các bảng liên quan đến truy vấn cụ thể. Do đó, mô hình mới là một tùy chọn cần được kiểm tra kỹ lưỡng trước khi bạn đưa nó vào sản xuất

Để chứng minh cho nhận định trên, rõ ràng chúng ta cần thực hiện các phép thử. Trước khi đi vào chi tiết của các bài kiểm tra, chúng tôi xem xét một số cân nhắc. Để phân biệt giữa hai mô hình, chúng tôi gọi mô hình thứ nhất là mô hình “chính tắc”, trong khi mô hình thứ hai được trình bày là mô hình “mới”

Điểm yếu của mối quan hệ nhiều-nhiều chính tắc là mối quan hệ hai chiều. Đó là một điểm yếu từ quan điểm mô hình hóa, bởi vì nó có thể gây ra sự mơ hồ. Đây cũng là một điểm yếu từ quan điểm hiệu suất, bởi vì việc chuyển bộ lọc từ nhiều bên sang một bên luôn đắt hơn so với làm ngược lại

Giải pháp mới không có mối quan hệ hai chiều, nhưng nó cũng bộc lộ hai điểm yếu. Thứ nhất, mối quan hệ giữa CustomerSport và Sales là mối quan hệ hạn chế. Hiệu suất khôn ngoan, các mối quan hệ hạn chế là chậm bởi vì chúng không được cụ thể hóa. Điều chúng ta nên đo lường là liệu mối quan hệ hai chiều có chậm hơn mối quan hệ nhiều-nhiều hay không. Nhưng sau đó có một vấn đề khác. Trong mô hình chuẩn, Khách hàng được liên kết trực tiếp với Bán hàng thông qua 1. mối quan hệ M. Trong mô hình mới, Khách hàng chỉ được liên kết với Doanh số thông qua bảng cầu nối. Điều này có nghĩa là công cụ sẽ duyệt qua mối quan hệ nhiều-nhiều bất cứ khi nào người dùng cắt theo các thuộc tính của Khách hàng hoặc Thể thao. Trong mô hình chính tắc, nếu người dùng duyệt theo khách hàng, thì bảng cầu không phải là một phần của trò chơi. Trong mô hình mới, bàn cầu luôn đóng vai trò quan trọng. Trong mô hình mới, người dùng duyệt theo khách hàng sẽ chạy một truy vấn luôn sử dụng CustomerSport để lọc Bán hàng. Chi tiết quan trọng này là điểm yếu nhất của mô hình mới, chúng tôi sẽ phân tích sâu hơn với các truy vấn

Kiểm tra hiệu suất

Các cân nhắc cho đến nay rất hữu ích để xác định các thử nghiệm để thực hiện. Chúng tôi sẽ kiểm tra hiệu suất của tính toán Số tiền bán hàng [một biện pháp quét bảng Doanh số] lọc theo Thể thao và theo Khách hàng trong cả hai trường hợp. Mô hình chúng tôi đang sử dụng là phiên bản Contoso với 1. 4 tỷ hàng. Bảng CustomerSport chứa khoảng 3 triệu hàng. chúng tôi đã tạo một mô hình trong đó mỗi khách hàng chơi giữa môn thể thao không và ba môn thể thao khác nhau

Nhóm truy vấn đầu tiên theo Thể thao[Thể thao] và truy vấn này tính toán Số tiền bán hàng. Để đơn giản, truy vấn cần duyệt qua mối quan hệ CustomerSport và chỉ sử dụng bảng Sport để nhóm theo

EVALUATE
SUMMARIZECOLUMNS [
    Sport[Sport],
    "Amt", [Sales Amount]
]

Để hiểu sâu hơn về cách đánh giá mối quan hệ nhiều-nhiều, chúng tôi cũng phân tích truy vấn thứ hai, phức tạp hơn một chút, nhóm theo cả Thể thao và Khách hàng

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

Cuối cùng, trong truy vấn cuối cùng, chúng tôi chỉ phân tích các nhóm theo Khách hàng. Trong mô hình chính tắc, truy vấn này không cần duyệt qua bảng CustomerSport. Mặt khác, trong mô hình mới, truy vấn này vẫn cần sử dụng CustomerSport, do cách trình bày các mối quan hệ

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    "Amt", [Sales Amount]
]

Các thử nghiệm trên mô hình chính tắc

Đầu tiên, đây là mô hình kinh điển, với một mối quan hệ hai chiều giữa Khách hàng và CustomerSport

Bây giờ chúng ta hãy chạy các truy vấn trên mô hình chính tắc. Nhóm truy vấn đầu tiên theo Thể thao

EVALUATE
SUMMARIZECOLUMNS [
    Sport[Sport],
    "Amt", [Sales Amount]
]

Thứ nhất, thời gian thực hiện. Truy vấn sử dụng 385.984 mili giây của CPU công cụ lưu trữ, với một lượng nhỏ công cụ công thức [10 mili giây]

Kế hoạch truy vấn rất thú vị để phân tích. Toàn bộ tính toán được đẩy xuống công cụ lưu trữ, với sự trợ giúp của các bảng tạm thời. Đây là những thông tin chi tiết

--
--  First we retrieve the pairs of CustomerKey and Sport from CustomerSport
--
DEFINE TABLE '$TTable3' := 
SELECT
    'Customer'[CustomerKey], 
    'Sport'[Sport]
FROM 
    'CustomerSport'
    LEFT OUTER JOIN 'Customer' 
        ON 'CustomerSport'[CustomerKey]='Customer'[CustomerKey]
    LEFT OUTER JOIN 'Sport' 
        ON 'CustomerSport'[SportKey]='Sport'[SportKey];

--
--  Here we extract the CustomerKey values in a bitmap
--
DEFINE TABLE '$TTable4' := 
     SELECTSIMPLEINDEXN [ '$TTable3'[Customer$CustomerKey] ]
FROM '$TTable3';

--
--  Here is where the actual computation happens. 
--  Note that the first INNER JOIN is with Table3, to retrieve the Sport
--  Table4 is used to further filter the scanning of Sales
--
DEFINE TABLE '$TTable1' := 
SELECT 
    '$TTable3'[Sport$Sport],
    SUM [ '$TTable2'[$Measure0] ]
FROM 
    '$TTable2' 
    INNER JOIN '$TTable3' ON
        '$TTable2'[Customer$CustomerKey]='$TTable3'[Customer$CustomerKey]
    REDUCED BY
        '$TTable2' := 
            WITH 
                $Expr0 := 'Sales'[Quantity] * 'Sales'[Net Price]
            SELECT
                'Customer'[CustomerKey],
                SUM [ @$Expr0 ]
            FROM 
                'Sales'
                LEFT OUTER JOIN 'Customer' 
                    ON 'Sales'[CustomerKey]='Customer'[CustomerKey]
            WHERE
                'Customer'[CustomerKey] ININDEX '$TTable4'[$SemijoinProjection];

Công cụ thực hiện phép tính của nó theo ba bước, tương ứng với ba truy vấn của công cụ lưu trữ

• Đầu tiên, nó lấy các cặp SportKey và CustomerKey từ CustomerSport
• Tiếp theo, nó tạo một bitmap chứa các giá trị CustomerKey có trong CustomerSport. Bảng này sẽ được sử dụng trong bước tiếp theo, để lọc khách hàng được quét từ Bán hàng. Thật vậy, vì chúng tôi chỉ quan tâm đến việc cắt theo môn thể thao, khách hàng không chơi môn thể thao nào sẽ bị bỏ qua
• Bước cuối cùng là nơi tính toán thực tế xảy ra. Công cụ quét Bán hàng và chỉ truy xuất những khách hàng trong CustomerSport [Bảng 2]. Nó kết hợp kết quả này với Bảng 3, ánh xạ khách hàng đến các môn thể thao

Mặc dù là một kế hoạch phức tạp, nhưng bạn thấy rằng toàn bộ tính toán đã được đẩy xuống công cụ lưu trữ. Tuy nhiên, công cụ lưu trữ không thể tự xử lý các bộ lọc hai chiều, do đó, nó cần chuẩn bị các bảng tạm thời này để tạo ra các liên kết chính xác

Logic tổng thể cũng có thể nhìn thấy trong kế hoạch truy vấn vật lý. Thật vậy, kế hoạch truy vấn vật lý chỉ được tạo từ bốn dòng truy xuất 45 hàng tương ứng với môn thể thao, hoàn toàn được tính toán bởi công cụ lưu trữ

Do toàn bộ tính toán được đẩy xuống bộ lưu trữ nên mức độ song song được sử dụng là rất tốt. nó hiện x49. 7 trên một máy có 64 lõi ảo, như một minh chứng nữa rằng công cụ này đang tối đa hóa việc sử dụng sức mạnh CPU

Chúng tôi đã mô tả kế hoạch rất chi tiết vì điều quan trọng là có thể so sánh kế hoạch đầu tiên này với các kế hoạch sau. Có sự khác biệt đáng kể về hiệu suất của các truy vấn khác nhau trên các mô hình và chi tiết khác nhau

Bây giờ chúng ta hãy thêm Khách hàng [Continent] vào truy vấn. Theo quan điểm của DAX, sự khác biệt không quá phức tạp. chỉ một dòng nữa trong danh sách theo nhóm SUMMARIZECOLUMNS

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

Mặc dù rất gần với truy vấn trước đó, thời gian hiện tại rất khác

Trước khi đi sâu vào chi tiết, xin lưu ý rằng mức độ song song phần lớn đã giảm. bây giờ nó hiển thị x23. 5, ít hơn một nửa những gì chúng tôi có trong truy vấn trước. Hơn nữa, thời gian của công cụ công thức đã tăng lên rất nhiều. nó đã tăng từ 10 đến 3.120 mili giây

Để hiểu lý do tại sao chúng ta có sự suy giảm hiệu suất này, chúng ta cần tìm hiểu sâu hơn. Đây là các truy vấn công cụ lưu trữ

--
--  Here we retrieve the Sales Amount for each customer, without reducing the 
--  set to only the customers being filtered by the CustomerSport table, as it
--  happened in the previous query
--
WITH
    $Expr0 := 'Sales'[Quantity] * 'Sales'[Net Price] 
SELECT
    'Customer'[CustomerKey], 
    'Customer'[Continent],
    SUM [ @$Expr0 ]
FROM 
    'Sales'
    LEFT OUTER JOIN 'Customer' 
        ON 'Sales'[CustomerKey]='Customer'[CustomerKey];

--
--  Here we match CustomerKey values with Customer[Continent] and Sport
--  by scanning Customersport, Customer and Sport together
--
SELECT
    'Customer'[CustomerKey],
    'Customer'[Continent], 
    'Sport'[Sport]
FROM 
    'CustomerSport'
    LEFT OUTER JOIN 'Customer' 
        ON 'CustomerSport'[CustomerKey]='Customer'[CustomerKey]
    LEFT OUTER JOIN 'Sport' 
        ON 'CustomerSport'[SportKey]='Sport'[SportKey];

Lần này, công cụ lưu trữ không thực sự tính toán các giá trị được trả về bởi truy vấn. Đầu tiên, nó truy xuất số tiền bán hàng cho mỗi khóa khách hàng, sau đó là một bảng khác ánh xạ các khóa khách hàng với lục địa và thể thao

Việc không tính toán thêm trong công cụ lưu trữ là một dấu hiệu rõ ràng rằng phép tính nhiều-nhiều thực sự xảy ra trong công cụ công thức. Do đó, sự gia tăng lớn trong việc sử dụng công cụ công thức. Ngoài ra, vì nó sẽ là công cụ công thức tính toán các giá trị thực, điều này có nghĩa là các cấu trúc dữ liệu chứa các giá trị một phần cần được chuyển trở lại công cụ công thức. Đây là điểm khác biệt lớn nhất giữa hai gói truy vấn. kế hoạch truy vấn trước đó đã thực hiện tất cả tính toán của nó bên trong công cụ lưu trữ, trong khi kế hoạch truy vấn sau này yêu cầu di chuyển một lượng lớn dữ liệu trở lại công cụ công thức

Bạn có thể đánh giá “chi tiết” này bằng cách xem kế hoạch truy vấn vật lý, kế hoạch này hiện chỉ ra rõ ràng rằng bảng có Lục địa và Thể thao [135 hàng] được nối với bảng lớn hơn chứa Số tiền bán hàng theo Khóa khách hàng [2.802.660 hàng] trong công cụ công thức

Bởi vì nó liên quan đến công cụ công thức, kế hoạch truy vấn này rõ ràng là dưới mức tối ưu so với kế hoạch truy vấn trước đó

Mọi thứ rất khác khi bảng CustomerSport không phải là một phần của trò chơi. Thật vậy, truy vấn cuối cùng mà chúng tôi phân tích chỉ phân chia số tiền bán hàng theo Khách hàng[Continent]. Do cách chúng tôi trình bày các mối quan hệ, không cần sử dụng bảng CustomerSport, vì Khách hàng có thể áp dụng bộ lọc trực tiếp cho Doanh số bán hàng

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    "Amt", [Sales Amount]
]

Thời gian của máy chủ là tuyệt vời

Không có công cụ công thức nào liên quan, mức độ song song là một x54 tuyệt vời. 5 và toàn bộ truy vấn được thực thi chỉ bằng 16.609 mili giây của CPU công cụ lưu trữ. Đây là hành vi có thể xảy ra với DAX với các mối quan hệ một-nhiều thông thường. Toàn bộ tính toán được thực hiện bởi động cơ tốt nhất của nó. động cơ lưu trữ

Bây giờ chúng ta đã thực hiện và phân tích ba truy vấn, chúng ta có thể rút ra kết luận về mô hình chính tắc. Khi truy vấn chỉ liên quan đến bảng Thể thao và phép tính có thể được đẩy xuống công cụ lưu trữ, Tabular sẽ tạo một kế hoạch truy vấn rất tốt sử dụng công cụ lưu trữ ở mức tốt nhất. Truy vấn nặng, nhưng bằng cách sử dụng các bảng tạm thời không được chuyển ra khỏi VertiPaq, mức độ song song là tốt. Khi truy vấn trở nên phức tạp hơn, công cụ công thức được yêu cầu – điều này làm chậm đáng kể toàn bộ truy vấn. Nếu động cơ không sử dụng bảng cầu CustomerSport, thì VertiPaq sẽ hoạt động tốt nhất. không có công cụ công thức nào được tham gia và truy vấn thậm chí không cần cấu trúc tạm thời

Thử nghiệm trên mô hình mới

Bây giờ chúng ta đã hiểu rõ về cách giải quyết các mối quan hệ nhiều-nhiều trong mô hình chính tắc, chúng ta có thể thực hiện ba thử nghiệm tương tự trên mô hình mới để kiểm tra xem nó hoạt động như thế nào. Dưới đây là những gì các mô hình mới trông giống như

Không có mối quan hệ hai chiều. Lần này, Khách hàng được liên kết với Bán hàng thông qua CustomerSport, giống như cách Sport được liên kết

Chúng tôi bắt đầu với truy vấn đầu tiên, chỉ nhóm theo Thể thao

EVALUATE
SUMMARIZECOLUMNS [
    Sport[Sport],
    "Amt", [Sales Amount]
]

Đầu tiên, thời gian

Toàn bộ truy vấn được giải quyết trong công cụ lưu trữ. Có một số truy vấn chạy trên một lõi đơn và truy vấn chính đạt được mức độ song song rất tốt. Nhìn chung, tổng thời gian rất gần với những gì chúng tôi đạt được với mô hình chính tắc

Bởi vì cách bố trí của các mối quan hệ là khác nhau, kế hoạch truy vấn cũng hơi khác so với kế hoạch thu được với mô hình chính tắc – mặc dù logic tổng thể rất gần nhau. Hãy để chúng tôi xem xét các truy vấn công cụ lưu trữ

--
--  Here we retrieve Sport and CustomerKey scanning CustomerSport
--
DEFINE TABLE '$TTable3' := 
SELECT
    'Sport'[Sport], 
    'CustomerSport'[CustomerKey]
FROM 
    'CustomerSport'	
        LEFT OUTER JOIN 'Sport' 
            ON 'CustomerSport'[SportKey]='Sport'[SportKey];

--
--  Here we retrieve CustomerKey only from Table3, which is derived from CustomerSport
--
DEFINE TABLE '$TTable4' := 
SELECT
    '$TTable3'[CustomerSport$CustomerKey]
FROM 
    '$TTable3';

--
--  Table5 contains the values of CustomerKey that are present in Sales, it will
--  be used later to reduce the scanning of Sales
--
DEFINE TABLE '$TTable5' := 
SELECT
    RJOIN [ '$TTable4'[CustomerSport$CustomerKey] ]
FROM '$TTable4'	
    REVERSE BITMAP JOIN 'Sales' 
        ON '$TTable4'[CustomerSport$CustomerKey]='Sales'[CustomerKey];

--
--  In this final query, Table5 is used to reduce the scanning of Sales to retrieve
--  the final result
--
DEFINE TABLE '$TTable1' := 
SELECT
    '$TTable3'[Sport$Sport],
    SUM [ '$TTable2'[$Measure0] ]
FROM 
    '$TTable2'
    INNER JOIN '$TTable3' 
        ON '$TTable2'[Sales$CustomerKey]='$TTable3'[CustomerSport$CustomerKey]
        REDUCED BY
            '$TTable2' := 
                 WITH $Expr0 := 'Sales'[Quantity] * 'Sales'[Net Price] 
                 SELECT
                     'Sales'[CustomerKey],
                     SUM [ @$Expr0 ]
                 FROM 
                     'Sales'
                 WHERE
                     'Sales'[CustomerKey] ININDEX '$TTable5'[$SemijoinProjection];

Như bạn thấy, mặc dù số lượng truy vấn công cụ lưu trữ là khác nhau, logic tổng thể giống như với mô hình chính tắc. Kế hoạch truy vấn vật lý là minh chứng cuối cùng rằng các kế hoạch thực sự gần như giống hệt nhau và toàn bộ công việc được thực hiện trong công cụ lưu trữ

Đã đến lúc xem truy vấn thứ hai, liên quan đến cả Khách hàng và Thể thao

Đã đến lúc xem truy vấn thứ hai, liên quan đến cả Khách hàng và Thể thao

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

Ở đây chúng ta có thể đánh giá cao sự khác biệt quan trọng đầu tiên giữa mô hình chính tắc và mô hình mới. Trong trường hợp này, mô hình chính tắc liên quan đến việc sử dụng nhiều công cụ công thức vì nó không dựa vào cách tiếp cận được sử dụng trong truy vấn trước đó. Thật vậy, hình dạng của mối quan hệ giữa Khách hàng và Bán hàng không giống với hình dạng của mối quan hệ giữa Thể thao và Khách hàng

Trong mô hình mới, Khách hàng và Thể thao có liên quan đến Khách hàngThể thao bằng cách sử dụng cùng một loại mối quan hệ. Do đó, thời gian và định dạng của các truy vấn nội bộ gần với các truy vấn được quan sát trong mô hình trước đó

Các cân nhắc cho truy vấn này giống như đối với mô hình trước đó. Gần như không có công cụ công thức nào được sử dụng. toàn bộ truy vấn đang được thực hiện trong công cụ lưu trữ. Điều này khác với cùng một truy vấn trên mô hình chính tắc

Trong mô hình chuẩn, việc thêm Khách hàng đã gây ra sự suy giảm hiệu suất nghiêm trọng, với việc sử dụng công cụ công thức nhiều hơn. Trong mô hình mới, việc thêm nhiều bộ lọc không phải là vấn đề. Về điều này, mô hình mới hoạt động tốt hơn đáng kể. Chúng ta hãy xem chi tiết về các truy vấn của công cụ lưu trữ để có được bức tranh rõ hơn

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

Như bạn thấy, ngoài một số khác biệt trong các cột được sử dụng trong truy vấn, cấu trúc tổng thể giống với cấu trúc trong mô hình trước đó. Kế hoạch truy vấn là - một lần nữa - giống hệt nhau

Trong truy vấn thứ hai này, mô hình mới hoạt động tốt hơn mô hình chính tắc. Điều này cực kỳ thú vị vì nó cho thấy rằng tùy thuộc vào loại truy vấn mà bạn dự định thực hiện trên một mô hình, một mô hình hoạt động tốt hơn mô hình kia

Thật không may, mô hình mới không đáp ứng được truy vấn thứ ba – truy vấn sử dụng bộ lọc về Khách hàng để tiếp cận Doanh số bán hàng. Trong mô hình kinh điển, mối quan hệ giữa Khách hàng và Bán hàng là trực tiếp. Do đó, toàn bộ truy vấn được thực thi bằng một truy vấn xmSQL duy nhất hoạt động tốt

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    "Amt", [Sales Amount]
]

Ở mẫu xe mới, động cơ vẫn cần sử dụng CustomerSport để đạt Doanh số. Do đó, truy vấn thứ ba chạy với tốc độ gần bằng với hai truy vấn trước đó và lợi ích bị mất. Dưới đây là thời gian trong hình dưới đây

Vì Continent chứa ít giá trị hơn một chút và không phải tất cả khách hàng đều chơi tất cả các môn thể thao nên cấu trúc dữ liệu mà truy vấn sử dụng nhỏ hơn một chút và thời gian thực hiện ngắn hơn một chút. Nhìn chung, định dạng của các truy vấn công cụ lưu trữ giống với hai truy vấn trước đó và không đáng để lặp lại lần thứ ba

Trong kịch bản thứ ba này, hiệu suất của mô hình kém hơn nhiều so với hiệu suất của mô hình chính tắc. Một lần nữa, đây là một kết quả thú vị vì nó cho thấy rằng bạn cần đưa ra lựa chọn dựa trên các loại truy vấn đang được thực thi. Nếu bạn hầu như không sử dụng mối quan hệ nhiều-nhiều giữa Khách hàng và Thể thao và bạn dựa nhiều hơn vào mối quan hệ trực tiếp giữa Khách hàng và Bán hàng cho hầu hết các tính toán của mình, thì mô hình chuẩn sẽ hoạt động tốt hơn. Mặt khác, nếu cấu trúc nhiều-nhiều luôn là một phần của truy vấn, thì mô hình mới có những ưu điểm thú vị

Tối ưu hóa mô hình mới

Dựa trên một nhận xét thú vị từ Daniel Otykier, chúng tôi đã cập nhật bài viết này với nội dung bổ sung. Chúng tôi cũng đã ghi lại một video rút phích cắm trong khi phân tích hiệu suất của các thay đổi được đề xuất. Thật vậy, Daniel lưu ý rằng các mối quan hệ trong mô hình mới có thể được sửa đổi để đạt được điều tốt nhất của cả hai thế giới. Thay vì liên kết Khách hàng với CustomerSport, chúng tôi liên kết trực tiếp Khách hàng với Bán hàng

Trong trường hợp này, cả CustomerSport và Customer đều được liên kết với Sales bằng cột CustomerKey. Do đó, cùng một cột Sales[CustomerKey] đang được lọc trực tiếp bởi Khách hàng và lọc gián tiếp bởi Thể thao, thông qua CustomerSport

Mô hình này không chứa các mối quan hệ hai chiều, do đó, nó không bị phạt về hiệu suất của mô hình chính tắc; . Mặt khác, mô hình bị thiếu mối quan hệ giữa Khách hàng và Thể thao, do bảng cầu không còn liên kết hai chiều. CustomerSport hiện chỉ liên kết Thể thao với Bán hàng. Do đó, việc xác định các môn thể thao mà khách hàng chơi sẽ phức tạp hơn trong mô hình này

Chúng tôi bắt đầu với truy vấn đầu tiên, chỉ nhóm theo Thể thao

EVALUATE
SUMMARIZECOLUMNS [
    Sport[Sport],
    "Amt", [Sales Amount]
]

Kế hoạch hiệu suất và truy vấn giống hệt với mô hình mới, bởi vì các bảng duy nhất liên quan là Thể thao, Thể thao khách hàng và Bán hàng

Chúng tôi không cung cấp ở đây các truy vấn xmSQL chi tiết, vì chúng giống hệt với các truy vấn được hiển thị cho mô hình mới. Thay vào đó, thật thú vị khi xem hành vi của phiên bản được tối ưu hóa này khi Khách hàng tham gia vào truy vấn

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

Bây giờ quá trình lọc xảy ra với hai đường dẫn khác nhau. Thể thao lọc Bán hàng thông qua bảng cầu, trong khi Khách hàng lọc Bán hàng trực tiếp. Cả hai bộ lọc đang hoạt động trên cùng một cột Sales[CustomerKey]

Mã xmSQL được thực thi khá thú vị. Lần này, phép nối giữa Khách hàng và Bán hàng xảy ra trong bảng được sử dụng để giảm phép nối. Thật vậy, Khách hàng[Continent] chỉ được thu thập trong truy vấn xmSQL cuối cùng

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

Có một sự xuống cấp nhẹ trong hiệu suất. Tuy nhiên, mức độ xuống cấp thấp hơn nhiều so với mô hình chính tắc và hiệu suất của việc quét truy vấn cả Khách hàng và Thể thao có thể so sánh với việc chỉ quét truy vấn Thể thao, như trường hợp của mô hình mới

Phát hiện thú vị nhất là việc lọc cùng một cột Bán hàng[CustomerKey] thông qua nhiều mối quan hệ dường như không có tác động tiêu cực đến toàn bộ truy vấn

Truy vấn cuối cùng trong bộ thử nghiệm chỉ phân chia Doanh số bán hàng theo Khách hàng

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    "Amt", [Sales Amount]
]

Do mối quan hệ trực tiếp, mô hình này cho thấy hiệu suất tuyệt vời giống như mô hình chuẩn

Không cần phải phân tích truy vấn này sâu hơn nữa. một truy vấn Công cụ lưu trữ duy nhất truy xuất kết quả, với tốc độ tuyệt vời như mô hình chuẩn

Do đó, mô hình mới được tối ưu hóa thực sự đại diện cho điều tốt nhất của cả hai thế giới. nó luôn nhanh khi cắt theo một hoặc hai chiều và nó không bị ảnh hưởng bởi hiệu suất của mô hình mới khi chỉ sử dụng Khách hàng

Hạn chế duy nhất là bằng cách liên kết trực tiếp Khách hàng với Bán hàng, chúng tôi đã đánh mất mối quan hệ giữa Thể thao và Khách hàng. Điều này có những hậu quả nghiêm trọng nếu, ví dụ: bạn muốn đếm số lượng môn thể thao trên mỗi khách hàng hoặc số lượng khách hàng chơi một môn thể thao nhất định. Bạn không chỉ cần quét Doanh số để có được kết quả này, bạn còn cần kích hoạt tính năng lọc chéo hai chiều trên một số mối quan hệ tùy thuộc vào số lượng bạn cần tính toán. Tồi tệ hơn, vì mối quan hệ cần duyệt qua Doanh số bán hàng, một khách hàng chưa bao giờ mua bất kỳ sản phẩm nào sẽ bị thiếu trong tính toán. Điều này mở ra cơ hội cho kết quả có khả năng không chính xác

Tuy nhiên, trong trường hợp như vậy, vấn đề có thể được giải quyết dễ dàng bằng cách tạo mối quan hệ không hoạt động giữa Khách hàng và Thể thao khách hàng và kích hoạt mối quan hệ theo yêu cầu bằng cách sử dụng TÍNH TOÁN và MỐI QUAN HỆ SỬ DỤNG trong các biện pháp cần di chuyển bộ lọc giữa Khách hàng và Thể thao mà không yêu cầu Khách hàng Thể thao

kết luận

Chúng tôi đã thực hiện phân tích chi tiết một vài truy vấn trên hai mô hình, cố gắng tìm ra mô hình tốt nhất. Phán quyết cuối cùng, như hầu như luôn luôn xảy ra trong thế giới của các mô hình dữ liệu, nó phụ thuộc vào

Mô hình chính tắc là một lựa chọn tốt bất cứ khi nào mối quan hệ nhiều-nhiều hiếm khi được sử dụng. Bạn phải trả giá đắt khi sử dụng bảng cầu nối thông qua Khách hàng vì trộn lẫn mối quan hệ bộ lọc hai chiều từ nhiều phía với các mối quan hệ khác sẽ tạo ra một kế hoạch truy vấn kém hơn. Khi bảng cầu không phải là một phần của phương trình, mô hình chuẩn sẽ nhanh hơn nhiều. Tuy nhiên, khi sử dụng bảng cầu nối, mô hình chuẩn sẽ chậm hơn và nó sử dụng khá nhiều công cụ công thức. Do đó, bạn quan sát thấy sự thay đổi lớn về tốc độ truy vấn của mình – tùy thuộc vào việc bạn có duyệt qua bảng cầu nối hay không

Phiên bản được tối ưu hóa của mô hình mới có được những điều tốt nhất của cả hai thế giới. Mặc dù khá bất thường với tư cách là một tập hợp các mối quan hệ, nhưng mô hình mới được tối ưu hóa đã chứng tỏ hiệu suất tuyệt vời trong tất cả các thử nghiệm. Bằng cách thêm mối quan hệ không hoạt động giữa CustomerSport và Sport, cũng có thể khôi phục liên kết trực tiếp giữa hai chiều khi cần

Như thường lệ, các lựa chọn phụ thuộc vào các thuộc tính cụ thể của mô hình của bạn. Khi chọn giữa mô hình chính tắc và mô hình mới, bạn nên đánh giá cẩn thận các truy vấn sẽ được thực thi và đưa ra lựa chọn có căn cứ dựa trên yêu cầu của người dùng. Đối với các kịch bản tối ưu hóa cực đoan, cũng có thể giữ cả hai bộ mối quan hệ trong mô hình và mã tác giả bằng cách sử dụng các điều kiện NẾU và các công cụ sửa đổi CROSSFILTER và USERELATIONSHIP để chọn bố cục mối quan hệ tốt nhất tùy thuộc vào truy vấn đang được thực thi. Một lần nữa, đây không phải là một kỹ thuật được đề xuất. thay đổi bố cục mối quan hệ có ảnh hưởng khác đến hiệu suất và vô hiệu hóa một số tối ưu hóa. Tuy nhiên, đó là một kỹ thuật đáng để thử khi bạn cố gắng tối ưu hóa cực độ

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    Sport[Sport],
    "Amt", [Sales Amount]
]

EVALUATE
SUMMARIZECOLUMNS [
    Customer[Continent],
    "Amt", [Sales Amount]
]