Đã có rất nhiều tài liệu viết về phân vùng bảng. Đây là một tính năng phức tạp và bạn có thể mất nhiều ngày chỉ để hiểu cách áp dụng nó. Nhưng liệu nó có cải thiện hiệu suất cho bạn không? Phân vùng bảng mang lại lợi ích to lớn cho một số ứng dụng, nhưng lại gây ra những rắc rối khổng lồ cho những ứng dụng khác.
Làm thế nào để bạn biết mình có nên đầu tư thời gian vào việc phân vùng bảng hay không?
Tôi có thể giúp bạn.
Phân vùng bảng trong SQL Server: Những điều cơ bản
Phân vùng bảng cho phép các bảng hoặc chỉ mục được lưu trữ trong nhiều phần vật lý— một chỉ mục được phân vùng giống như một chỉ mục lớn được tạo thành từ nhiều chỉ mục nhỏ. Mỗi phần, hay phân vùng, đều có các cột giống nhau– chỉ khác nhau về phạm vi hàng. Phân vùng bảng có tính "trong suốt". Điều này có nghĩa là một heap, clustered index hoặc non-clustered index đã được phân vùng có thể được tham chiếu như một cấu trúc duy nhất mặc dù nó được lưu trữ trong các phân vùng vật lý độc lập. Nói cách khác, về lý thuyết, bạn không cần thay đổi bất kỳ mã nguồn nào trong các ứng dụng gọi đến nó. (Điều này có đúng trong thực tế không? Chúng ta sẽ bàn thêm về điều này sau.)
Một ví dụ điển hình về phân vùng bảng
Bộ phận Froyo của Tập đoàn Contoso có một cơ sở dữ liệu 2TB tên là FroyoReports. Mỗi ngày, 10 triệu hàng dữ liệu bán hàng được tải vào một bảng tên là FroyoSales. Contoso Corp có nhân viên trên toàn thế giới truy vấn dữ liệu bằng SQL Server Reporting Services. Các báo cáo được chạy trên FroyoReports 24/7, mặc dù mỗi ngày có một khoảng thời gian hai giờ có tải lượng thấp hơn đáng kể. 95% báo cáo được chạy dựa trên dữ liệu của hai tháng gần nhất, và đội ngũ DBA kiểm soát cũng như có thể tinh chỉnh các truy vấn được chạy bởi mỗi báo cáo. Đội ngũ DBA của Froyo cần duy trì chỉ 13 tháng dữ liệu trong bảng FroyoSales. Để đề phòng, họ muốn giữ thêm ba tháng dữ liệu trực tuyến, nhưng không muốn các báo cáo truy cập vào dữ liệu cũ hơn.
Cuộc sống từng rất khó khăn đối với đội ngũ DBA của Froyo. Mỗi đêm khi dữ liệu được tải, các báo cáo liên tục chặn các lệnh chèn dữ liệu. Để giúp giảm bớt tình trạng chặn, một số báo cáo đã được sửa đổi để thêm các gợi ý NOLOCK. Điều này có nghĩa là đôi khi các báo cáo chứa dữ liệu không đầy đủ của ngày gần nhất, gây ra nhiều vấn đề. Người dùng không bao giờ thực sự chắc chắn khi nào dữ liệu đã tải xong và khi nào an toàn để chạy báo cáo. Đội ngũ DBA của Froyo đã xóa dữ liệu cũ vào cuối tuần, và quá trình đó cũng gặp vấn đề. Việc chặn xảy ra nhiều hơn và các lệnh xóa làm chậm hiệu suất đáng kể. Để giải quyết những vấn đề này, đội ngũ Froyo đã triển khai phân vùng bảng. Họ đã phân vùng bảng FroyoSales theo ngày.
Mỗi đêm, đội ngũ Froyo tải dữ liệu bằng một quy trình tự động. Đầu tiên, nó tải dữ liệu thực tế mới vào một bảng trống, mới tên là FroyoSalesStaging.
Một bảng tạm được tải dữ liệu
Tiếp theo, nó thêm các chỉ mục và ràng buộc vào FroyoSalesStaging để cấu trúc của nó khớp với Froyo sales.
Chuẩn bị một bảng tạm để chuyển vào bảng thực tế
Sau đó, họ chuyển phân vùng đơn lẻ ra khỏi FroyoSalesStaging và vào bảng đã phân vùng FroyoSales. (Việc này bao gồm một vài lệnh để chuẩn bị siêu dữ liệu cho bảng đã phân vùng trước khi chuyển đổi– chúng ta đang xem xét tổng quan ở đây.) Việc chuyển đổi này chỉ mất một khoảnh khắc, sau đó tất cả dữ liệu mới sẽ hiển thị cho người dùng.
Chuyển một phân vùng từ bảng tạm sang bảng thực tế
Đội ngũ Froyo cũng đã tự động hóa cách họ xóa dữ liệu cũ. Mỗi đêm, họ chuyển ngày cũ nhất– hiện đã quá giới hạn 13 tháng của họ– ra khỏi FroyoSales và vào một bảng tên là FroyoSalesArchive. (Tương tự, có một vài lệnh để dọn dẹp siêu dữ liệu cho FroyoSales sau khi chuyển ra ngoài.)
Chuyển một phân vùng bảng sang bảng lưu trữ
Tiện lợi phải không?
Các tính năng chính của phân vùng bảng— Và những cạm bẫy
Dưới đây là những điểm hấp dẫn lớn của phân vùng bảng, cùng với các lưu ý chi tiết.
SWITCH (Chuyển đổi) phân vùng đó
Như bạn có thể thấy ở trên, toàn bộ một phân vùng có thể được chuyển vào bảng hoặc chuyển ra ngoài, cho phép tải và xóa một lượng lớn dữ liệu cực nhanh. Theo tôi, đây là lợi ích lớn nhất của việc phân vùng.
Có một vài cạm bẫy cần lưu ý. Việc chuyển vào và chuyển ra các phân vùng có thể rất nhanh, nhưng cần có một khóa độc quyền— được gọi là khóa 'SCH-M', hay khóa sửa đổi lược đồ (Schema Modification lock). Điều này có nghĩa là bạn có thể bị chặn không cho tải hoặc xóa dữ liệu khỏi bảng của mình— có khả năng trong một thời gian rất dài. Ngoài ra, tất cả các non-clustered index đã bật của bạn phải được "căn chỉnh phân vùng" (partition aligned) để chuyển một phân vùng vào. Điều này có nghĩa là khóa phân vùng phải là một phần của mỗi chỉ mục đó. Nếu bạn cần duy trì tính duy nhất trên một tập hợp các cột không bao gồm khóa phân vùng (thường xảy ra trong môi trường OLTP), điều này có thể gây ra vấn đề.
Hiệu suất truy vấn trên các bảng được phân vùng: Loại bỏ phân vùng và hơn thế nữa
SQL Server cố gắng xác định khi nào nó có thể sử dụng các phần giới hạn của một bảng được phân vùng. Trình tối ưu hóa truy vấn của SQL Server có thể hướng một truy vấn chỉ đến một phân vùng duy nhất, nhiều phân vùng, hoặc toàn bộ bảng. Việc sử dụng ít phân vùng hơn toàn bộ bảng được gọi là "loại bỏ phân vùng" (partition elimination).
Số liệu thống kê được duy trì cho toàn bộ bảng hoặc chỉ mục được phân vùng— bạn không nhận được các bước bổ sung trong biểu đồ tần suất (histogram) cho mỗi phân vùng. Điều này có nghĩa là trình tối ưu hóa truy vấn của SQL Server vẫn có thể gặp rất nhiều khó khăn trong việc biết lượng dữ liệu sẽ
Việc đặt một filegroup ở chế độ chỉ đọc (read-only) không loại bỏ chi phí quản lý khóa—điều đó chỉ đúng đối với một cơ sở dữ liệu chỉ đọc.
Columnstore Indexes và Phân vùng Bảng
Columnstore indexes là một tính năng thực sự nổi bật trong SQL Server 2012. Đây là các chỉ mục dạng cột được tối ưu hóa cho hiệu suất cực nhanh. Mặc dù các chỉ mục này sẽ ở chế độ chỉ đọc, các phân vùng vẫn có thể được chuyển đổi vào Columnstore indexes.
Khi nào một bảng đủ lớn để phân vùng?
Sau khi đề cập đến những điều cơ bản về phân vùng bảng, đây thường là câu hỏi đầu tiên mà mọi người đặt ra: “Bảng của tôi đã đủ lớn chưa?” Câu trả lời của tôi là: “Hãy cùng thảo luận về lý do tại sao bạn quan tâm đến phân vùng bảng. Vấn đề bạn đang gặp phải là gì?”
Hãy cho tôi biết bảng của bạn đang gặp vấn đề ở đâu
Khi mọi người tìm hiểu về phân vùng bảng trong SQL Server, thường là họ đang gặp vấn đề trong việc mở rộng quy mô cơ sở dữ liệu của mình. Những gì bạn đang trải qua có thể xuất hiện dưới nhiều hình thức khác nhau. Vấn đề có thể bao gồm một hoặc nhiều yếu tố sau:
Các truy vấn “chậm” trả về một lượng nhỏ dữ liệu
Các truy vấn “chậm” trả về một lượng lớn dữ liệu
Tải dữ liệu “chậm”
Xung đột (blocking) giữa các tiến trình đọc và ghi (chèn hoặc cập nhật)
Các tác vụ bảo trì chỉ mục chạy trong thời gian dài (hoặc không thể chạy được vì chúng sẽ mất quá nhiều thời gian)
Tất nhiên, “chậm” là một khái niệm mang tính tương đối cao. Ở đây, nó có nghĩa là “người dùng của tôi đang phàn nàn” hoặc “máy chủ web của tôi đang bị quá thời gian chờ” hoặc “có thứ gì đó đang gặp lỗi và gọi tôi dậy vào giữa đêm.” Thông thường, các bảng được đề cập đang được sử dụng cho sự kết hợp giữa hoạt động OLTP và hoạt động báo cáo.
Cách tiếp cận của tôi là trao đổi với nhóm và tìm hiểu xem trải nghiệm về vấn đề đó như thế nào. Theo nghĩa đen, “Điều gì khiến bạn mất ngủ về bảng này?”
Tình trạng tổng thể của bạn như thế nào?
Việc chỉ định phân vùng bảng giống như việc đề nghị một cuộc phẫu thuật quan trọng— bạn không muốn ai đó phải lên bàn mổ trừ khi đó là cách tốt nhất để cải thiện tình hình. Tôi xem xét tình trạng tổng thể của hệ thống. Các nút thắt cổ chai hiện tại nằm ở đâu? Chúng ta đang chờ đợi điều gì? Các thành phần riêng lẻ có hoạt động tốt không? Các truy vấn hiện đang thực thi như thế nào và các kế hoạch truy vấn (query plans) trông ra sao? Những mẫu hình nào đang được sử dụng trong các truy vấn đang chạy? Tôi cũng xem xét cấu trúc của các bảng và chỉ mục trong bối cảnh của các truy vấn.
Bạn cần những đặc điểm hiệu suất nào?
Bạn *muốn* tải bao nhiêu bản ghi mỗi ngày? Bạn sẽ xóa bao nhiêu bản ghi mỗi ngày trong sáu tháng tới? Doanh nghiệp của bạn dự kiến sẽ có thêm bao nhiêu khách hàng mới và tác động ước tính của điều đó đối với việc đọc và ghi trên hệ thống của bạn là gì? Số lượng khách hàng dự kiến có thể rất khó để chuyển đổi thành hoạt động cơ sở dữ liệu. Một bài kiểm tra sức khỏe SQL Server có thể tạo ra một số chỉ số cho hoạt động hiện tại để sử dụng cho các dự báo.
Bạn có thể tinh chỉnh bao nhiêu truy vấn?
Việc bạn có linh hoạt trong việc tinh chỉnh truy vấn hay không là một yếu tố khác biệt lớn trong cách bạn chọn mở rộng quy mô ứng dụng của mình. Một mặt, phân vùng bảng là “trong suốt” vì tên của các đối tượng được phân vùng không thay đổi. Mặt khác, bạn muốn tinh chỉnh các truy vấn để đạt được việc loại bỏ phân vùng (partition elimination) và các kế hoạch truy vấn tốt nhất có thể sau khi bạn phân vùng— và đôi khi bạn cần phải sáng tạo một chút. Cấu trúc các bảng của bạn và cách các truy vấn hiện đang được viết sẽ đóng một vai trò rất lớn nếu bạn có khả năng tinh chỉnh truy vấn hạn chế (hoặc không có).
Cách tiếp cận tốt nhất để mở rộng quy mô ứng dụng của bạn là gì?
Đây là bí mật của tôi: Tôi không trả lời câu hỏi “Tôi có nên sử dụng phân vùng bảng không?” Thay vào đó, tôi trả lời câu hỏi “Cách tốt nhất để mở rộng quy mô ứng dụng này là gì?”
Cách tiếp cận đúng đắn cho vấn đề khả năng mở rộng của bạn có thể bao gồm phân vùng bảng— có lẽ là riêng lẻ, có lẽ là kết hợp với các công nghệ khác. Trong ứng dụng phù hợp, phân vùng bảng có thể thực sự tuyệt vời. Nhưng chúng ta cũng có thể mở rộng quy mô ứng dụng của bạn theo một cách khác— có lẽ rẻ hơn, có lẽ nhanh hơn, hoặc có lẽ theo cách bao gồm tính đa dạng địa lý tích hợp sẵn. Tất cả phụ thuộc vào tình trạng cơ sở dữ liệu, yêu cầu hiệu suất, ngân sách và sự linh hoạt của bạn.
Bạn vẫn quan tâm chứ?
Nếu bạn đã đọc đến đây và vẫn quan tâm đến phân vùng bảng, có lẽ đó là lựa chọn phù hợp với bạn!
Trước khi bạn bắt đầu thiết kế chiến lược phân vùng bảng, hoặc nếu bạn đang cố gắng khắc phục sự cố tại sao các bảng được phân vùng của bạn không hoạt động nhanh như mong đợi, hãy xem trang tài nguyên phân vùng bảng SQL Server của chúng tôi.