Phân vùng máy chủ SQL - sử dụng gì cho khóa phân vùng?


10

Tôi chưa bao giờ làm việc với phân vùng SQL Server nhưng hiện tại tôi phải đối mặt với việc thiết kế cơ sở dữ liệu mà khối lượng có thể đảm bảo. Hệ thống này là dành cho phiếu giảm giá. Các phiếu giảm giá sẽ được phát hành định kỳ, thường là sáu tuần một lần mặc dù cũng sẽ có đợt phát hành đột xuất - ví dụ cho một sự kiện đặc biệt. Có 15 triệu khách hàng và cho mỗi sự kiện phát hành, mỗi khách hàng sẽ nhận được 6 loại phiếu giảm giá khác nhau, với tổng số 90 triệu trường hợp phiếu giảm giá. Chúng tôi cần theo dõi dữ liệu mua lại ví dụ phiếu giảm giá và duy trì dữ liệu này trong 6 tháng, mặc dù thông thường, phiếu giảm giá chỉ có hiệu lực trong sáu tuần. Bất kỳ yêu cầu mua lại cho một phiếu giảm giá không hợp lệ sẽ không đến được cơ sở dữ liệu bởi vì nó sẽ được xác nhận bởi POS cho đến khi.

Trong thời hạn sáu tháng, chúng tôi sẽ cần lưu trữ 360 triệu hàng trong bảng Coupon Instance và tối đa 72 triệu (giả sử tỷ lệ mua lại tối đa 20%) trong bảng Mua lại. Tôi có cảm giác rằng những con số này quá lớn cho một phân vùng?

Câu hỏi của tôi là - dùng cái gì làm chìa khóa phân vùng? Một ứng cử viên rõ ràng sẽ là sự kiện phát hành, đưa ra khoảng 6 phân vùng. Nhưng sau đó tôi nghĩ rằng có lẽ điều đó sẽ cho kích thước phân vùng quá lớn để cho phép hiệu suất tối ưu? Có thể phân vùng theo hai khóa, ví dụ như bằng sự kiện phát hành + chữ số cuối của id khách hàng? Vì vậy, logic sẽ là:

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

Ngoài ra, tôi không chắc chắn về thông số kỹ thuật của máy chủ cơ sở dữ liệu mà chúng tôi sẽ cần. 16gb và 8CPU sẽ là đủ? Db cần phải có thể trả về một kết quả từ bảng đối tượng phiếu giảm giá, được khóa trên một giá trị mã vạch số trong chưa đầy nửa giây. Yêu cầu giao dịch dự kiến ​​để xác thực (chọn) và đổi (chèn) dự kiến ​​sẽ đạt đỉnh ở mức khoảng 3.500 mỗi phút.

Máy chủ db SQL Server 2008r2 64 bit sẽ được cung cấp dưới dạng VM từ một máy chủ rất mạnh có quyền truy cập vào SAN hiệu suất cao và dung lượng lớn.

Tôi rất biết ơn về bất kỳ lời khuyên nào từ những người đã triển khai giải pháp SQL Server để quản lý các khối lượng tương tự.

Trân trọng

Cướp.


2
Các bảng của bạn vẫn còn nhỏ - không CẦN cho các phân vùng, tôi có một bảng có vài tỷ hàng không có phân vùng, hoạt động. Các phân vùng là tốt cho DROP NHANH, mặc dù.
TomTom

1
Vô nghĩa @TomTom, các phân vùng có thể có ích ở hàng tính một phần nhỏ của điều này. Cấp lược đồ phân vùng phải có lợi cho các mẫu truy cập để nhận ra hiệu suất tăng nhưng một tấm chăn "không CẦN" ở kích thước này là hoàn toàn sai.
Mark Storey-Smith

1
Không, nó là chính xác. CẦN! = Lợi ích. CẦN là khi bạn gặp vấn đề khi thực hiện truy vấn mà không có phân vùng.
TomTom

1
Xin chào @TomTom Tôi nghĩ rằng bạn cần một người bạn nhỏ phá vỡ, điều đó hơi mạnh mẽ, ngay cả khi không thực sự gây khó chịu. Tôi đồng tình với Mark StoreySmith, một tấm chăn "không CẦN" là hoàn toàn sai, tuy nhiên khẳng định của bạn rằng có lẽ không cần thiết là đúng. Tôi tưởng tượng đó là một vấn đề về lập chỉ mục. Tôi cũng biết rằng Mark biết ý của bạn là gì so với nhu cầu và lợi ích. Cắt tất cả chúng ta một chút chùng và buông caffeine, k? (Và hãy tin tôi, tôi biết là có rất ít kiên nhẫn vài ngày, đặc biệt là ngày như ngày nay, nơi tôi đang trên meds đau lưng)
jcolebrand

Câu trả lời:


14

Các câu hỏi thông số kỹ thuật của máy chủ nên được chuyển đến Serverfault hoặc DBA.SE.

Đối với câu hỏi phân vùng, tôi không nghĩ bạn nhất thiết phải phân vùng cho việc này.

Hàng 360m là rất nhiều nhưng nó không quá khó sử dụng.

Đừng KHÔNG trong mọi trường hợp cố gắng phân vùng dựa trên các chữ số cuối cùng của một lĩnh vực. Tôi không chắc điều này thậm chí sẽ hoạt động, nhưng nó không phải là SARGable.

Nếu bạn chỉ cần thực hiện tìm kiếm một hàng dựa trên khóa số, phân vùng có thể sẽ không giúp ích.

Nếu bạn quyết định theo đuổi lộ trình phân vùng, hãy nhớ rằng có hiệu quả tất cả các truy vấn của bạn cần bao gồm (các) khóa phân vùng để động cơ biết phân vùng nào cần kiểm tra. Nếu không, nó sẽ kiểm tra tất cả và bạn thực sự làm tổn thương hiệu suất.



Tôi cũng đồng tình. Đôi khi bạn chỉ cần chỉ số tốt hơn.
jcolebrand

Tôi không đồng ý @JNK. Một hàng tìm kiếm dựa trên khóa số có lợi từ việc loại bỏ phân vùng là giảm IO. Nếu các mẫu truy cập sao cho các phân vùng được truy cập thường xuyên vẫn nằm trong nhóm bộ đệm trên các phân vùng được truy cập không thường xuyên, bạn có thêm lợi ích hiệu suất. Và chúng tôi thậm chí không chạm vào tính năng yêu thích của tôi mà phân vùng mang lại cho bạn, tính khả dụng một phần.
Mark Storey-Smith

Đối với hồ sơ, về những điểm khác của bạn, tôi đồng ý hết lòng :)
Mark Storey-Smith

@ MarkStorey-Smith - Nó sẽ phụ thuộc vào chìa khóa của anh ấy. Như được định nghĩa trong OP, phân vùng sẽ không thêm bất kỳ giá trị nào. Có vẻ như anh ta sẽ không thể sử dụng khóa hai phần với trường ngày hoặc sơ đồ phân vùng "bình thường".
JNK

5

Bạn có thể phân vùng trên nhiều khóa nếu bạn sử dụng cột được tính toán bền vững; như những người khác đã nói, tuy nhiên, phân vùng không hoạt động cho mọi tình huống. Tôi không chắc rằng tôi hiểu kịch bản của bạn đủ để cho bạn lời khuyên cụ thể, nhưng đây là một số nguyên tắc chung:

  • Phân vùng rất hữu ích trong việc đọc dữ liệu khi khóa phân vùng là một phần của câu lệnh SQL, cho phép trình tối ưu hóa gọi ra loại trừ phân vùng. Bạn cần chắc chắn rằng khóa bạn chọn là hữu ích cho hầu hết các truy vấn.

  • Một lợi ích của chiến lược phân vùng tốt là cho dữ liệu cũ; ví dụ: nếu khóa phân vùng của bạn dựa trên ngày (tức là ngày trong năm) và bạn muốn xóa tất cả dữ liệu cũ hơn một ngày nhất định, thì rất dễ dàng CHUYỂN ĐỔI các phân đoạn đó vào một bảng trống và cắt bớt.


4

Bạn thực sự cần phải xác định yêu cầu của bạn rõ ràng hơn một chút. Bạn đề cập rằng bạn sẽ có khoảng 360 triệu hàng trong 6 tháng. Làm thế nào trong 2 năm thời gian? Bạn sẽ vẫn chỉ phát triển với tốc độ mà bạn hiện đang tăng. Hoặc có một cơ hội mà bạn sẽ trải nghiệm sự tăng trưởng theo cấp số nhân. Bạn có muốn giữ dữ liệu trong bảng này mãi mãi; hoặc bạn muốn lưu trữ dữ liệu một cách thường xuyên.

Phân vùng có thể được sử dụng để lưu trữ dữ liệu. Xem kịch bản cửa sổ trượt. Xem whitepaper nàycái này .

Phân vùng cũng có thể được sử dụng để quản lý phân mảnh chỉ mục. Bạn có thể xây dựng lại / sắp xếp lại các phân vùng cụ thể.

Bạn cũng nên xem xét các khung nhìn được phân vùng trái ngược với các bảng được phân đoạn. Chế độ xem được phân vùng không yêu cầu giấy phép SQL Server Enterprise. Chế độ xem được phân vùng cũng cho phép bạn thực hiện xây dựng lại chỉ mục trực tuyến trên một "phân vùng" cụ thể.

Phân vùng cũng có thể được xem xét khi thực hiện kế hoạch khắc phục thảm họa của bạn. Nó có thể được sử dụng để phục hồi cơ sở dữ liệu một phần. Ví dụ: bạn có thể có các phân vùng cũ trên một nhóm tệp khác với các phân vùng chính / hiện tại. Và sau đó khi bạn đang khôi phục, bạn khôi phục filegroup chính, sau đó filegroup mà các phân vùng hiện tại của bạn cư trú và cuối cùng bạn có thể khôi phục các filegroup mà các phân vùng cũ nằm trên đó. Điều này có thể làm giảm thời gian ứng dụng của bạn phải ngừng hoạt động.

Hãy xem video tuyệt vời này từ Kimberly Tripp về phân vùng .


Chúng tôi chỉ cần giữ dữ liệu trong sáu tháng. Mỗi tuần, chúng tôi sẽ thực hiện một công việc dọn phòng sẽ xóa bất kỳ phiếu giảm giá nào được phát hành hơn sáu tháng trước.
Rob Bowman

3
Vì vậy, về cơ bản, bạn sẽ phải xóa / xóa khoảng 15 triệu hàng mỗi tuần. Bàn rộng bao nhiêu? Tôi sẽ đề nghị bạn phân vùng bảng theo cột ngày. Bằng cách này, việc xóa hàng tuần sẽ là một thao tác meta đơn giản. Bạn chỉ cần SWITCH phân vùng cũ nhất trong bảng được phân vùng chính thành bảng phân tầng. Sau đó thả bảng dàn dựng. Đây được gọi là kịch bản Windows trượt. Tra cứu tờ giấy trắng đầu tiên tôi đăng oh làm thế nào để làm điều này.
DharmWiki Kumar 'DK'

-2

Trừ khi bạn thực hiện phân vùng vì lưu trữ dữ liệu cũ, bạn đang làm điều đó vì lý do sai và không nên làm điều đó.


2
Có rất nhiều lý do để sử dụng phân vùng bên cạnh việc lưu trữ; loại trừ một phần có lợi cho nhiều loại truy vấn khác nhau, nếu được sử dụng đúng cách.
Stuart Ainsworth

Tôi đồng ý với Stuart, đây là một lời khuyên tồi.
jcolebrand
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.