Những thiết kế bảng nào là tốt hơn cho hiệu suất?

Tôi đã được yêu cầu tạo ra thứ gì đó theo dõi chi phí hàng ngày để thu thập trên các tài khoản và tôi đang cố gắng tìm ra một lược đồ bảng cơ sở dữ liệu sẽ hỗ trợ việc này.

Đây là những gì tôi biết

• Công ty có hơn 2,5 triệu tài khoản
• Trong số này, họ hiện làm việc trung bình 200.000 mỗi tháng (thay đổi theo cấp độ nhân viên, hiện đang ở mức thấp)
• Họ có 13 loại chi phí khác nhau mà họ muốn theo dõi và họ đã cảnh báo rằng họ có thể bổ sung thêm trong tương lai
• Họ muốn các chi phí được theo dõi hàng ngày
• Chi phí không được chia trên toàn bộ hàng tồn kho. Chúng được chia thành số tài khoản được làm việc mỗi tháng (200.000) hoặc người dùng có thể nhập số nhận dạng tài khoản để áp dụng chi phí cho một nhóm tài khoản hoặc đơn giản là họ có thể chỉ định tài khoản nào sẽ áp dụng chi phí.

Suy nghĩ đầu tiên của tôi là một cơ sở dữ liệu chuẩn hóa:

Tài khoản
Ngày
CostTypeId
Số tiền

Vấn đề của tôi với điều này là, làm toán. Bảng này sẽ nhận được rất lớn nhanh chóng. Giả sử tất cả 13 loại chi phí được áp dụng cho tất cả các tài khoản đã hoạt động cho tháng hiện tại 200k * 13 * N days in month, đó là khoảng 75-80 triệu hồ sơ mỗi tháng, hoặc gần một tỷ hồ sơ mỗi năm.

Suy nghĩ thứ hai của tôi là không chuẩn hóa nó một chút

Tài khoản
Ngày
Tổng chi phí
Chi phí1
Chi phí loại2
Chi phí loại3
Chi phí loại4
Chi phí loại5
Chi phí loại6
Chi phí loại7
Chi phí loại8
Chi phí loại9
Chi phí loại10
Chi phí11
Chi phí loại12
Chi phí13

Phương pháp này không chuẩn hóa hơn và có thể tạo tới 6 triệu bản ghi mỗi tháng ( 200k * N days in month), hoặc khoảng 72 triệu mỗi năm. Nó ít hơn nhiều so với phương pháp đầu tiên, tuy nhiên nếu công ty quyết định Loại chi phí mới trong tương lai, một cột cơ sở dữ liệu khác sẽ cần được thêm vào.

Trong hai phương pháp, bạn thích phương pháp nào? Tại sao? Có một sự thay thế khác mà bạn có thể nghĩ ra sẽ xử lý việc này tốt hơn không?

Tôi quan tâm nhất đến hiệu suất báo cáo, cả báo cáo chi tiết và mùa hè. Công việc phân bổ chi phí ra khỏi tài khoản sẽ được thực hiện hàng đêm khi không có ai xung quanh. Một mối quan tâm thứ yếu là kích thước cơ sở dữ liệu. Cơ sở dữ liệu hiện có đã gần 300 GB và tôi tin rằng dung lượng trên đĩa khoảng 500 GB.

Cơ sở dữ liệu là SQL Server 2005

Một tỷ hồ sơ một năm không nhiều.

Với phân vùng (có thể theo Costtype) và lưu trữ, nó có thể quản lý được.

Số lượng mục dữ liệu cần lưu trữ vẫn là 200k * 13 * N. Là các cột, bạn sẽ nhận được ít hàng hơn trên mỗi trang và sẽ mất nhiều không gian hơn so với hàng. Bạn có thể đạt được nếu "CostType1" không phải là kiểu dữ liệu có độ dài cố định, nhưng nó không đáng kể.

"HÔN" như họ nói

Mặc dù thiết kế của bạn chắc chắn có thể tạo ra sự khác biệt về đêm hoặc ngày, nhưng trong trường hợp này tôi sẽ tập trung nhiều hơn vào các chỉ mục, bao gồm cả các chỉ số khi cần thiết. Tôi cũng sẽ xem xét một số công cụ mà SQL Server cung cấp cho bạn để xử lý các bảng rất lớn, chẳng hạn như phân vùng bảng.

Hãy nghĩ về nó theo cách này, mặc dù có 80 tỷ bản ghi trong bảng, với việc lập chỉ mục thích hợp, những bản ghi mà bạn thực sự quan tâm tại bất kỳ điểm nào sẽ được nhóm lại với nhau trên đĩa. Do cách thức tổ chức dữ liệu trong máy chủ SQL, dữ liệu được phân chia theo các ranh giới chỉ mục cũng có thể nằm trong một bảng khác vì nó không phải đọc toàn bộ bảng để có được những gì nó cần.

Nếu bạn cũng chọn phân vùng bảng, bạn có thể cải thiện thời gian truy cập và chèn thời gian.

Tôi sẽ bình thường hóa. Chúng tôi đã hạch toán chi phí cho lợi nhuận tài khoản của khách hàng tại ngân hàng và chúng tôi đã tạo ra hơn 250 triệu hàng chi phí cá nhân bằng cách sử dụng hàng trăm trình điều khiển được phân bổ bởi trung tâm chi phí hoặc sổ cái chung hoặc bằng nhiều kỹ thuật khác trên hàng triệu tài khoản mỗi tháng.

Chẳng hạn, tổng chi phí phục vụ ATM được chia cho các tài khoản đã sử dụng ATM dựa trên lượng sử dụng tương đối. Vì vậy, nếu 1 triệu đô la được sử dụng để phục vụ các máy ATM và chỉ có 5 khách hàng sử dụng nó một lần và một khách hàng đã sử dụng nó 5 lần, thì một khách hàng đó đã trả cho ngân hàng 0,5 đô la và các khách hàng khác phải trả cho ngân hàng 0,5 đô la mỗi lần. Các trình điều khiển khác có thể phức tạp hơn nhiều.

Cuối cùng, có lẽ bạn sẽ thấy nó thưa thớt - một số tài khoản không nhận được chi phí từ các nguồn / trình điều khiển nhất định - và một số tài khoản không nhận được gì. Trong một mô hình chuẩn hóa, những hàng đó không tồn tại. Trong mô hình không chuẩn hóa, hàng tồn tại, với một số cột trống. Ngoài ra, trong một mô hình chuẩn hóa thưa thớt, bạn sẽ thấy hiệu suất được cải thiện, bởi vì sự tồn tại của một hàng thường nhanh hơn để kiểm tra (với chỉ số bao phủ trên CostType) so với kiểm tra tất cả các hàng có không phải NULL trong một "nhóm" cụ thể (ngay cả với các chỉ mục trên mỗi cột số lượng - mà bạn có thể thấy bắt đầu rất lãng phí).

Bất kể lợi ích về hiệu suất, tôi chắc chắn sẽ ủng hộ phương án 1. Phương án 2 sẽ cướp Peter để trả Paul, theo ý kiến ​​của tôi.

Tôi sẽ sử dụng tùy chọn 1 và sau đó, nếu tốc độ báo cáo trở thành vấn đề, tôi cũng sẽ thêm bảng 2 và đưa nó vào cơ sở dữ liệu báo cáo trong một quy trình xử lý qua đêm / tự động.

Sau đó, bạn cũng có thể xem xét triển khai cấu trúc bảng 2 hàng ngày thành các danh mục hàng tuần, hàng tháng, hàng quý, hàng năm nếu được bảo hành.

Nhưng, như tôi đã nói, tôi cũng chọn lưu trữ dữ liệu 'thô' ở dạng thích hợp (chuẩn hóa).

Xem xét các tập bạn đề cập, tôi sẽ chọn tùy chọn thứ hai, nhưng không có TotalCost. Bạn có thể nói rằng vẫn còn bình thường.

Chỉnh sửa: như một giải pháp thay thế và tùy thuộc vào yêu cầu của bạn và kích thước của AccountId, bạn cũng có thể xem xét các điều sau:

AccountDate
-----------
AccountId  
Date  
AcDtID (surrogate key)

Costs
-------
AcDtID
CostTypeId  
Amount  

Với thiết kế đó, bạn vẫn có thể thêm TotalCost không chuẩn hóa vào bảng đầu tiên và tính toán lại hàng đêm, cho phép chạy một số báo cáo trên bảng đầu tiên.

bạn thực sự nên chia bảng linh hoạt thành hai bảng để bạn có thể sử dụng truy vấn con và chọn hàng thứ hai làm cột hoặc nhiều cột. theo cách đó linh hoạt hơn và bằng cách đó, bạn có thể nhận được kết quả như kết quả thứ hai dễ dàng hơn.