Tại sao tham gia không tốt hoặc 'chậm'. Tôi biết tôi đã nghe điều này nhiều hơn một lần. Tôi tìm thấy câu trích dẫn này
Vấn đề là các phép nối tương đối chậm, đặc biệt là trên các tập dữ liệu rất lớn, và nếu chúng chậm thì trang web của bạn sẽ chậm. Phải mất một thời gian dài để lấy tất cả các bit thông tin riêng biệt đó ra khỏi đĩa và tập hợp chúng lại với nhau.
Tôi luôn nghĩ rằng họ rất nhanh, đặc biệt là khi tra cứu PK. Tại sao họ 'chậm chạp'?
Câu trả lời:
Khả năng mở rộng là tất cả về việc tính toán trước, dàn trải hoặc cắt nhỏ công việc lặp đi lặp lại thành những yếu tố cần thiết để giảm thiểu việc sử dụng tài nguyên trên mỗi đơn vị công việc. Để mở rộng quy mô tốt, bạn không làm bất cứ điều gì bạn không cần đến khối lượng và những việc bạn thực sự làm mà bạn đảm bảo được thực hiện một cách hiệu quả nhất có thể.
Trong bối cảnh đó, tất nhiên việc kết hợp hai nguồn dữ liệu riêng biệt là tương đối chậm, ít nhất là so với việc không kết hợp chúng, bởi vì đó là công việc bạn cần thực hiện trực tiếp tại thời điểm người dùng yêu cầu.
Nhưng hãy nhớ rằng giải pháp thay thế không còn có hai phần dữ liệu riêng biệt nữa; bạn phải đặt hai điểm dữ liệu khác nhau trong cùng một bản ghi. Bạn không thể kết hợp hai phần dữ liệu khác nhau mà không dẫn đến hậu quả ở đâu đó, vì vậy hãy đảm bảo rằng bạn hiểu sự đánh đổi.
Tin tốt là cơ sở dữ liệu quan hệ hiện đại có khả năng kết hợp tốt . Bạn thực sự không nên nghĩ về việc tham gia là chậm với một cơ sở dữ liệu tốt được sử dụng tốt. Có một số cách thân thiện với khả năng mở rộng để lấy các phép nối thô và làm cho chúng nhanh hơn nhiều :
Tôi sẽ đi xa hơn khi nói rằng lý do chính mà cơ sở dữ liệu quan hệ tồn tại là cho phép bạn tham gia một cách hiệu quả * . Nó chắc chắn không chỉ để lưu trữ dữ liệu có cấu trúc (bạn có thể làm điều đó với các cấu trúc tệp phẳng như csv hoặc xml). Một số tùy chọn mà tôi đã liệt kê thậm chí sẽ cho phép bạn xây dựng trước hoàn toàn sự tham gia của mình, vì vậy kết quả đã được thực hiện trước khi bạn đưa ra truy vấn - giống như thể bạn đã không chuẩn hóa dữ liệu (phải thừa nhận là phải trả giá bằng các thao tác ghi chậm hơn).
Nếu bạn tham gia chậm, có thể bạn đang sử dụng cơ sở dữ liệu của mình không đúng cách.
Việc khử chuẩn hóa chỉ nên được thực hiện sau khi các kỹ thuật khác này không thành công. Và cách duy nhất bạn có thể thực sự đánh giá "thất bại" là đặt ra các mục tiêu hiệu suất có ý nghĩa và đo lường dựa trên các mục tiêu đó. Nếu bạn chưa đo, còn quá sớm để nghĩ đến việc khử chuẩn hóa.
* Nghĩa là, tồn tại dưới dạng các thực thể khác biệt với tập hợp các bảng đơn thuần. Một lý do bổ sung cho rdbms thực là truy cập đồng thời an toàn.
Việc tham gia có thể chậm hơn so với việc tránh chúng thông qua quá trình khử chuẩn hóa nhưng nếu được sử dụng đúng cách (tham gia trên các cột có chỉ mục thích hợp, v.v.) thì chúng vốn dĩ không chậm .
Khử chuẩn hóa là một trong nhiều kỹ thuật tối ưu hóa mà bạn có thể xem xét nếu lược đồ cơ sở dữ liệu được thiết kế tốt của bạn có vấn đề về hiệu suất.
bài báo nói rằng chúng chậm khi so sánh với việc không có liên kết. điều này có thể đạt được với sự không chuẩn hóa. vì vậy có sự đánh đổi giữa tốc độ và bình thường hóa. cũng đừng quên về việc tối ưu hóa sớm :)
Trước hết, cơ sở dữ liệu quan hệ (lý do tồn tại) của cơ sở dữ liệu quan hệ là có thể mô hình hóa mối quan hệ giữa các thực thể. Tham gia chỉ đơn giản là cơ chế mà chúng tôi vượt qua các mối quan hệ đó. Chúng chắc chắn đi kèm với chi phí danh nghĩa, nhưng không có liên kết, thực sự không có lý do gì để có một cơ sở dữ liệu quan hệ.
Trong thế giới học thuật, chúng ta học về những thứ như các dạng thông thường khác nhau (1, 2, 3, Boyce-Codd, v.v.), và chúng ta tìm hiểu về các loại khóa khác nhau (chính, ngoại, thay thế, duy nhất, v.v.) và cách những thứ này phù hợp với nhau để thiết kế một cơ sở dữ liệu. Và chúng tôi tìm hiểu những điều thô sơ của SQL cũng như thao tác với cả cấu trúc và dữ liệu (DDL & DML).
Trong thế giới doanh nghiệp, nhiều cấu trúc học thuật hóa ra kém khả thi hơn đáng kể so với những gì chúng ta từng tin tưởng. Một ví dụ hoàn hảo là khái niệm về khóa chính. Về mặt học thuật, đó là thuộc tính (hoặc tập hợp các thuộc tính) xác định duy nhất một hàng trong bảng. Vì vậy, trong nhiều lĩnh vực vấn đề, khóa chính học thuật thích hợp là tổ hợp của 3 hoặc 4 thuộc tính. Tuy nhiên, hầu hết mọi người trong thế giới doanh nghiệp hiện đại đều sử dụng số nguyên tuần tự, được tạo tự động làm khóa chính của bảng. Tại sao? Hai lý do. Thứ nhất là vì nó làm cho mô hình sạch hơn nhiều khi bạn di chuyển FK khắp nơi. Điều thứ hai, và cũng là sai lầm nhất cho câu hỏi này, đó là việc truy xuất dữ liệu thông qua các phép nối nhanh hơn và hiệu quả hơn trên một số nguyên duy nhất so với trên 4 cột varchar (như đã được đề cập bởi một số người).
Bây giờ chúng ta hãy tìm hiểu sâu hơn một chút về hai loại phụ cụ thể của cơ sở dữ liệu thế giới thực. Loại đầu tiên là cơ sở dữ liệu giao dịch. Đây là cơ sở cho nhiều ứng dụng thương mại điện tử hoặc quản lý nội dung thúc đẩy các trang web hiện đại. Với DB giao dịch, bạn đang tối ưu hóa rất nhiều cho "thông lượng giao dịch". Hầu hết các ứng dụng thương mại hoặc nội dung phải cân bằng hiệu suất truy vấn (từ các bảng nhất định) với hiệu suất chèn (trong các bảng khác), mặc dù mỗi ứng dụng sẽ có các vấn đề kinh doanh riêng cần giải quyết.
Loại thứ hai của cơ sở dữ liệu thế giới thực là cơ sở dữ liệu báo cáo. Chúng hầu như chỉ được sử dụng để tổng hợp dữ liệu kinh doanh và tạo các báo cáo kinh doanh có ý nghĩa. Chúng thường có hình dạng khác với cơ sở dữ liệu giao dịch nơi dữ liệu được tạo và chúng được tối ưu hóa cao cho tốc độ tải dữ liệu hàng loạt (ETL) và hiệu suất truy vấn với các tập dữ liệu lớn hoặc phức tạp.
Trong mỗi trường hợp, nhà phát triển hoặc DBA cần cân bằng cẩn thận cả đường cong chức năng và hiệu suất, và có rất nhiều thủ thuật nâng cao hiệu suất cho cả hai phía của phương trình. Trong Oracle, bạn có thể thực hiện cái được gọi là "giải thích kế hoạch" để bạn có thể thấy cụ thể cách một truy vấn được phân tích cú pháp và thực thi. Bạn đang tìm cách tối đa hóa việc sử dụng hợp lý các chỉ mục của DB. Một điều thực sự khó chịu là đặt một hàm trong mệnh đề where của một truy vấn. Bất cứ khi nào bạn làm điều đó, bạn đảm bảo rằng Oracle sẽ không sử dụng bất kỳ chỉ mục nào trên cột cụ thể đó và bạn có thể sẽ thấy bản quét toàn bộ hoặc một phần bảng trong kế hoạch giải thích. Đó chỉ là một ví dụ cụ thể về cách một truy vấn có thể được viết mà kết thúc là chậm và nó không liên quan gì đến các phép nối.
Và trong khi chúng ta đang nói về quét bảng, chúng rõ ràng tác động đến tốc độ truy vấn tỷ lệ thuận với kích thước của bảng. Việc quét toàn bộ bảng gồm 100 hàng thậm chí không đáng chú ý. Chạy cùng một truy vấn đó trên một bảng có 100 triệu hàng và bạn sẽ cần phải quay lại vào tuần tới để trả lại.
Hãy nói về bình thường hóa trong một phút. Đây là một chủ đề học thuật phần lớn tích cực khác có thể khiến bạn quá căng thẳng. Hầu hết khi chúng ta nói về chuẩn hóa, chúng ta thực sự muốn nói đến việc loại bỏ dữ liệu trùng lặp bằng cách đưa nó vào bảng của chính nó và di chuyển một FK. Những người thường bỏ qua toàn bộ điều phụ thuộc được mô tả bởi 2NF và 3NF. Và trong một trường hợp cực đoan, chắc chắn có thể có một cơ sở dữ liệu BCNF hoàn hảo, khổng lồ và là một con thú hoàn chỉnh để viết mã vì nó quá bình thường.
Vậy chúng ta cân bằng ở đâu? Không có câu trả lời tốt nhất. Tất cả các câu trả lời tốt hơn có xu hướng thỏa hiệp giữa việc dễ bảo trì cấu trúc, dễ bảo trì dữ liệu và dễ tạo / bảo trì mã. Nói chung, càng ít trùng lặp dữ liệu càng tốt.
Vậy tại sao tham gia đôi khi bị chậm? Đôi khi đó là thiết kế quan hệ tồi. Đôi khi, việc lập chỉ mục không hiệu quả. Đôi khi đó là vấn đề về khối lượng dữ liệu. Đôi khi đó là một truy vấn được viết khủng khiếp.
Xin lỗi vì một câu trả lời dài dòng như vậy, nhưng tôi cảm thấy bắt buộc phải cung cấp bối cảnh về thịt xung quanh nhận xét của mình hơn là chỉ nói lảm nhảm một câu trả lời 4 gạch đầu dòng.
Những người có cơ sở dữ liệu có kích thước terrabyte vẫn sử dụng các phép nối, nếu họ có thể làm cho chúng hoạt động hiệu quả thì bạn cũng vậy.
Có nhiều lý do để không biến đổi. Đầu tiên, tốc độ của các truy vấn được chọn không phải là mối quan tâm duy nhất hoặc thậm chí chính với cơ sở dữ liệu. Tính toàn vẹn của dữ liệu là mối quan tâm đầu tiên. Nếu bạn không chuẩn hóa thì bạn phải áp dụng các kỹ thuật để giữ cho dữ liệu không chuẩn hóa khi dữ liệu mẹ thay đổi. Vì vậy, giả sử bạn lưu tên máy khách trong tất cả các bảng thay vì tham gia vào bảng máy khách trên client_Id. Bây giờ khi tên của máy khách thay đổi (100% khả năng một số tên của máy khách sẽ thay đổi theo thời gian), bây giờ bạn cần cập nhật tất cả các bản ghi con để phản ánh sự thay đổi đó. Nếu bạn thực hiện việc này với bản cập nhật theo tầng và bạn có một triệu bản ghi con, bạn cho rằng tốc độ đó sẽ diễn ra nhanh như thế nào và bao nhiêu người dùng sẽ gặp phải vấn đề khóa và chậm trễ trong công việc của họ khi nó xảy ra? Hơn nữa hầu hết những người không chuẩn hóa bởi vì "
Chuẩn hóa là một quá trình phức tạp đòi hỏi sự hiểu biết thấu đáo về hiệu suất và tính toàn vẹn của cơ sở dữ liệu nếu nó được thực hiện đúng cách. Đừng cố gắng chuẩn hóa lại trừ khi bạn có chuyên môn về nhân viên.
Việc tham gia diễn ra khá nhanh nếu bạn thực hiện một số việc. Đầu tiên hãy sử dụng một khóa gợi ý, một phép nối int gần như là phép nối nhanh nhất. Thứ hai, luôn lập chỉ mục cho khóa ngoại. Sử dụng các bảng dẫn xuất hoặc các điều kiện nối để tạo một tập dữ liệu nhỏ hơn để lọc. Nếu bạn có một cơ sở dữ liệu lớn rất phức tạp, thì hãy thuê một nhân viên cơ sở dữ liệu chuyên nghiệp có kinh nghiệm trong việc phân chia và quản lý cơ sở dữ liệu khổng lồ. Có rất nhiều kỹ thuật để cải thiện hiệu suất mà không cần loại bỏ các phép nối.
Nếu bạn chỉ cần khả năng truy vấn, thì có, bạn có thể thiết kế một kho dữ liệu có thể không chuẩn hóa và được điền thông qua một công cụ ETL (được tối ưu hóa cho tốc độ) chứ không phải nhập dữ liệu của người dùng.
Tham gia chậm nếu
Vì vậy, đúng, bộ dữ liệu của bạn càng lớn thì bạn càng cần nhiều xử lý hơn cho một truy vấn nhưng việc kiểm tra và làm việc trên ba tùy chọn đầu tiên ở trên thường sẽ mang lại kết quả tuyệt vời.
Nguồn của bạn cung cấp bất chuẩn hóa như một tùy chọn. Điều này chỉ ổn miễn là bạn đã hết các lựa chọn thay thế tốt hơn.
Các phép nối có thể chậm nếu cần quét một phần lớn bản ghi từ mỗi bên.
Như thế này:
SELECT SUM(transaction)
FROM customers
JOIN accounts
ON account_customer = customer_idNgay cả khi một chỉ mục được xác định trên account_customer, tất cả các bản ghi từ chỉ mục sau vẫn cần được quét.
Đối với danh sách truy vấn này, các trình tối ưu hóa tốt có thể sẽ không xem xét đến đường dẫn truy cập chỉ mục, thay vào đó thực hiện một HASH JOINhoặc một MERGE JOIN.
Lưu ý rằng đối với một truy vấn như thế này:
SELECT SUM(transaction)
FROM customers
JOIN accounts
ON account_customer = customer_id
WHERE customer_last_name = 'Stellphlug'quá trình tham gia có lẽ sẽ nhanh chóng: đầu tiên, một chỉ mục trên customer_last_namesẽ được sử dụng để lọc tất cả các Stellphlug (tất nhiên là không nhiều lắm), sau đó một bản quét chỉ mục account_customersẽ được thực hiện cho mỗi Stellphlug để tìm các giao dịch của anh ta.
Mặc dù thực tế rằng đây có thể là hàng tỷ bản ghi trong accountsvà customers, chỉ một số ít thực sự cần được quét.
accounts(account_customer)hầu hết các RDBMS sẽ sử dụng chỉ mục đó để tìm ra chính xác hàng nào của customerscơ sở dữ liệu cần được quét.
HASH JOINsẽ nhanh hơn nhiều vì đó là những gì sẽ được sử dụng trừ trong tất cả các cơ sở dữ liệu lớn, ngoại trừ MySQL, đó sẽ chỉ làm cho customershàng đầu trong một vòng lặp lồng nhau (vì nó là kích thước nhỏ hơn)
Joins are fast.Tham gia nên được coi là thực hành tiêu chuẩn với một lược đồ cơ sở dữ liệu được chuẩn hóa đúng cách. Tham gia cho phép bạn tham gia các nhóm dữ liệu khác nhau một cách có ý nghĩa. Đừng sợ tham gia.
Lưu ý là bạn phải hiểu chuẩn hóa, kết hợp và sử dụng hợp lý các chỉ mục.
Cẩn thận với việc tối ưu hóa quá sớm, vì lỗi số một của tất cả các dự án phát triển là đáp ứng thời hạn. Khi bạn đã hoàn thành dự án và bạn hiểu sự đánh đổi, bạn có thể phá vỡ các quy tắc nếu bạn có thể biện minh cho nó.
Đúng là hiệu suất tham gia suy giảm không tuyến tính khi kích thước của tập dữ liệu tăng lên. Do đó, nó không chia tỷ lệ độc đáo như các truy vấn bảng đơn lẻ, nhưng nó vẫn mở rộng quy mô.
Cũng đúng khi một con chim bay nhanh hơn mà không có cánh mà chỉ bay thẳng xuống.
Các phép ghép nối đòi hỏi phải xử lý thêm vì chúng phải tìm nhiều tệp hơn và nhiều chỉ mục hơn để "nối" dữ liệu lại với nhau. Tuy nhiên, "tập dữ liệu rất lớn" đều là tương đối. Định nghĩa của large là gì? Tôi là trường hợp của JOIN, tôi nghĩ rằng nó tham chiếu đến một tập kết quả lớn, không phải tập dữ liệu tổng thể đó.
Hầu hết các cơ sở dữ liệu có thể rất nhanh chóng xử lý một truy vấn chọn 5 bản ghi từ bảng chính và kết hợp 5 bản ghi từ một bảng có liên quan cho mỗi bản ghi (giả sử có các chỉ mục chính xác). Mỗi bảng này có thể có hàng trăm triệu bản ghi, hoặc thậm chí hàng tỷ bản ghi.
Khi tập hợp kết quả của bạn bắt đầu phát triển, mọi thứ sẽ chậm lại. Sử dụng cùng một ví dụ, nếu bảng chính cho kết quả 100 nghìn bản ghi, thì sẽ có 500 nghìn bản ghi "được nối" cần được tìm thấy. Chỉ cần kéo nhiều dữ liệu đó ra khỏi cơ sở dữ liệu với thêm sự chậm trễ.
Đừng tránh tham gia, chỉ cần biết rằng bạn có thể cần phải tối ưu hóa / không chuẩn hóa khi tập dữ liệu trở nên "rất lớn".
Cũng từ bài báo bạn đã trích dẫn:
Nhiều trang web quy mô lớn với hàng tỷ bản ghi, petabyte dữ liệu, hàng nghìn người dùng đồng thời và hàng triệu truy vấn mỗi ngày đang sử dụng sơ đồ phân tích và một số thậm chí còn ủng hộ việc không chuẩn hóa là chiến lược tốt nhất để lưu trữ tầng dữ liệu.
và
Và trừ khi bạn là một trang web thực sự lớn, bạn có thể không cần phải lo lắng về mức độ phức tạp này.
và
Nó dễ xảy ra lỗi hơn là để cơ sở dữ liệu thực hiện tất cả công việc này, nhưng bạn có thể vượt qua những gì mà ngay cả cơ sở dữ liệu cao cấp nhất có thể xử lý.
Bài báo đang thảo luận về các trang web lớn như Ebay. Ở mức độ sử dụng đó, bạn có thể sẽ phải xem xét một cái gì đó khác hơn là quản lý cơ sở dữ liệu quan hệ đơn giản. Nhưng trong quá trình kinh doanh "bình thường" (các ứng dụng có hàng nghìn người dùng và hàng triệu bản ghi), những cách tiếp cận đắt tiền hơn, dễ xảy ra lỗi hơn là quá mức cần thiết.
Tham gia được coi là lực lượng đối lập với khả năng mở rộng vì chúng thường là nút thắt cổ chai và chúng không thể dễ dàng phân phối hoặc song song.
Các bảng được thiết kế phù hợp có chứa các chỉ dẫn thích hợp và các truy vấn được viết chính xác không phải lúc nào cũng chậm. Bạn đã từng nghe điều đó ở đâu:
Tại sao tham gia không tốt hoặc 'chậm'
không biết họ đang nói gì !!! Hầu hết các lần tham gia sẽ rất nhanh. Nếu bạn phải kết hợp nhiều hàng cùng một lúc, bạn có thể nhận được một lần truy cập so với một bảng không chuẩn hóa, nhưng điều đó sẽ quay trở lại các bảng được thiết kế phù hợp, biết khi nào thì không chuẩn hóa và khi nào thì không. trong một hệ thống báo cáo nặng nề, hãy chia nhỏ dữ liệu trong các bảng không chuẩn hóa cho các báo cáo, hoặc thậm chí tạo một kho dữ liệu. Trong một hệ thống giao dịch nặng, bình thường hóa các bảng.
Lượng dữ liệu tạm thời được tạo ra có thể rất lớn dựa trên các phép nối.
Ví dụ, một cơ sở dữ liệu tại nơi làm việc có chức năng tìm kiếm chung trong đó tất cả các trường là tùy chọn. Quy trình tìm kiếm đã tham gia vào mọi bảng trước khi bắt đầu tìm kiếm. Điều này đã hoạt động tốt ngay từ đầu. Nhưng, bây giờ bảng chính có hơn 10 triệu hàng ... không quá nhiều. Tìm kiếm hiện mất 30 phút hoặc hơn.
Tôi được giao nhiệm vụ tối ưu hóa thủ tục tìm kiếm được lưu trữ.
Điều đầu tiên tôi làm là nếu bất kỳ trường nào của bảng chính đang được tìm kiếm, tôi chỉ thực hiện chọn một bảng tạm thời trên các trường đó. VẬY, tôi đã nối tất cả các bảng với bảng tạm thời đó trước khi thực hiện phần còn lại của tìm kiếm. Các tìm kiếm trong đó một trong các trường bảng chính hiện mất chưa đến 10 giây.
Nếu không có trường nào trong bảng chính được bắt đầu tìm kiếm, tôi thực hiện tối ưu hóa tương tự cho các bảng khác. Khi tôi đã hoàn tất, không có tìm kiếm nào mất quá 30 giây với hầu hết dưới 10.
Việc sử dụng CPU của máy chủ SQL cũng CÓ THỂ XUỐNG.
Trong khi các phép nối (có lẽ là do thiết kế chuẩn hóa) rõ ràng có thể truy xuất dữ liệu chậm hơn so với việc đọc từ một bảng đơn lẻ, thì cơ sở dữ liệu không chuẩn hóa có thể chậm cho các hoạt động tạo / cập nhật dữ liệu vì dấu chân của giao dịch tổng thể sẽ không nhỏ.
Trong cơ sở dữ liệu chuẩn hóa, một phần dữ liệu sẽ chỉ tồn tại ở một nơi, do đó, dấu vết cho một bản cập nhật sẽ càng ít càng tốt. Trong cơ sở dữ liệu không chuẩn hóa, có thể cùng một cột trong nhiều hàng hoặc trên các bảng sẽ phải được cập nhật, có nghĩa là dấu chân sẽ lớn hơn và khả năng bị khóa và tắc nghẽn có thể tăng lên.
Vâng, đúng vậy, việc chọn các hàng từ một bảng không chuẩn hóa (giả sử có các chỉ mục phù hợp cho truy vấn của bạn) có thể nhanh hơn việc chọn các hàng được tạo từ việc kết hợp một số bảng, đặc biệt nếu các liên kết không có sẵn chỉ mục hiệu quả.
Các ví dụ được trích dẫn trong bài báo - Flickr và eBay - là những trường hợp ngoại lệ IMO, vì vậy hãy có (và xứng đáng) những phản hồi đặc biệt. Tác giả đặc biệt chỉ ra việc thiếu RI và mức độ trùng lặp dữ liệu trong bài báo.
Hầu hết các ứng dụng - một lần nữa, IMO - được hưởng lợi từ việc xác nhận và giảm sự trùng lặp do các RDBMS cung cấp.
Chúng có thể chậm nếu được thực hiện một cách cẩu thả. Ví dụ: nếu bạn thực hiện 'select *' trên một tham gia, bạn sẽ mất một khoảng thời gian để lấy lại nội dung. Tuy nhiên, nếu bạn cẩn thận chọn những cột nào để trả về từ mỗi bảng và với các chỉ mục thích hợp tại chỗ, sẽ không có vấn đề gì.