Thiết kế cơ sở dữ liệu: một bảng lớn hoặc bảng riêng biệt?

Question

Hiện tại tôi đang thiết kế một cơ sở dữ liệu để sử dụng trong công ty của chúng tôi. Chúng tôi đang sử dụng SQL Server 2008. Cơ sở dữ liệu sẽ giữ dữ liệu được thu thập từ một số khách hàng. Mục tiêu của cơ sở dữ liệu là thu thập số điểm chuẩn tổng hợp trên một số khách hàng.

Gần đây, tôi đã trở nên lo lắng với thực tế là một bảng đặc biệt sẽ nhận được rất lớn. Mỗi khách hàng có khoảng 20.000.000 hàng dữ liệu và sẽ sớm có 30 khách hàng trong cơ sở dữ liệu (nếu không có nhiều hơn). Rất nhiều truy vấn sẽ được thực hiện trên bảng này. Tôi đã nhận thấy các vấn đề về hiệu suất và người dùng tạm thời bị khóa.

Câu hỏi của tôi, chúng tôi sẽ có thể xử lý bảng này trong tương lai hay tốt hơn là chia bảng này thành các bảng nhỏ hơn cho từng khách hàng?

---

Cập nhật: Nó bây giờ đã được khoảng nửa năm kể từ khi chúng tôi lần đầu tiên tạo ra các bảng. Theo những lời khuyên dưới đây, tôi đã tạo ra một số bàn khổng lồ. Kể từ đó, tôi đã được experimenting with indexes và quyết định trên một chỉ mục nhóm trên hai cột đầu tiên (mã bệnh viện và mã vùng) mà trên đó chúng tôi sẽ có phân vùng bảng đã có chúng tôi đã có phiên bản doanh nghiệp. Thiết lập này đã hoạt động tốt cho đến gần đây, như Galwegian dự đoán, các vấn đề về hiệu năng đang tăng lên. Việc xây dựng lại một chỉ mục mất độ tuổi, người dùng khóa nhau, truy vấn thường mất nhiều thời gian hơn, và đối với hầu hết các truy vấn, nó trả tiền để sao chép phần dữ liệu có liên quan vào bảng tạm thời, tạo chỉ mục trên bảng tạm thời và chạy truy vấn. Đây không phải là nó nên như thế nào. Do đó, chúng tôi đang xem xét mua phiên bản Enterprise để sử dụng các bảng được phân đoạn. Nếu mua hàng không thể đi qua tôi có kế hoạch sử dụng workaround to accomplish partitioning in Standard Edition.

Answer 1

Bắt đầu với một bảng lớn, và sau đó áp dụng phân vùng bảng 2008 khả năng khi thích hợp, nếu hiệu suất sẽ trở thành một vấn đề.

Answer 2

Một bảng, sau đó lo lắng về hiệu suất. Đó là, giả sử bạn đang thu thập chính xác thông tin tương tự cho từng khách hàng. Bằng cách đó, nếu bạn phải thêm/xóa/sửa đổi một cột, bạn chỉ làm ở một nơi.

Answer 3

Bảng phân tách vì lý do hiệu suất được gọi là sharding. Ngoài ra, lược đồ cơ sở dữ liệu có thể được chuẩn hóa nhiều hơn hoặc ít hơn. Một lược đồ chuẩn hóa có các bảng riêng biệt với các quan hệ giữa chúng và dữ liệu không bị trùng lặp.

Answer 4

Tôi giả sử bạn có cơ sở dữ liệu được chuẩn hóa đúng cách. Nó không phải là một vấn đề để đối phó với khối lượng dữ liệu bạn tham khảo trên một bảng duy nhất trong SQL Server; những gì tôi nghĩ bạn cần làm là xem lại các chỉ mục của bạn.

Answer 5

Datawarehouses được cho là lớn (đầu mối có tên). Hai mươi triệu hàng là trung bình theo tiêu chuẩn kho bãi, mặc dù sáu trăm triệu hàng có thể được coi là lớn.

Điều cần lưu ý là các bảng lớn như vậy có một vật lý khác nhau, như lỗ đen. Vì vậy, điều chỉnh chúng sẽ có một bộ kỹ thuật khác. Một điều nữa là, người dùng datawarehouse phải hiểu rằng họ đang xử lý một lượng lớn dữ liệu và vì vậy họ không được mong đợi phản hồi phụ thứ hai (hoặc thực sự là phút phụ) cho mọi truy vấn.

Phân vùng có thể hữu ích, đặc biệt nếu bạn có phân giới rõ ràng như, như trong trường hợp của bạn, CUSTOMER. Bạn phải biết rằng việc phân vùng có thể làm suy giảm hiệu suất của các truy vấn cắt ngang hạt của khóa phân vùng. Vì vậy, nó không phải là một viên đạn bạc.

Answer 6

Nếu bạn đang sử dụng máy chủ MS SQL và bạn muốn giữ một bảng, phân vùng bảng có thể là một giải pháp.

Answer 7

Vì bạn đã gắn thẻ câu hỏi của mình là 'datawarehouse', tôi cho rằng bạn biết một số điều về chủ đề. Tùy thuộc vào mục tiêu của bạn, bạn có thể đi cho một lược đồ sao (một mô hình đa chiều với một thực tế và dimensiontables). Lưu trữ tất cả dữ liệu trao đổi nhanh trong 1 bảng (cho mỗi chủ đề) và dữ liệu chậm chạp trong một bảng kích thước/'bông tuyết' khác.

Một tùy chọn khác là phương pháp DataVault của Dan Lindstedt. Đó là một chút phức tạp hơn nhưng cung cấp cho bạn sự linh hoạt đầy đủ.

http://danlinstedt.com/category/datavault/

Answer 8

Giữ một bảng - hàng 20M không phải là rất lớn, và khách hàng không chính xác các loại bảng mà bạn có thể dễ dàng 'lưu trữ tắt', và aggrevation tìm kiếm nhiều bảng để tìm một khách hàng không phải là giá trị nỗ lực (SQL có thể hiệu quả hơn nhiều khi tìm kiếm BTree hơn phát minh của riêng bạn)

Tuy nhiên, bạn sẽ cần phải xem xét các vấn đề về hiệu năng và khóa - điều này sẽ ngăn không cho mở rộng quy mô của bạn.

Answer 9

Bạn cũng có thể tạo các bảng bổ sung chứa các chi tiết đã được tính toán trên thông tin lịch sử nếu có các truy vấn phổ biến.

Answer 10

Việc chia tay chắc chắn là điều cần xem xét. Tôi đã có một cơ sở dữ liệu có 2 bảng được phân phát. Mỗi bảng chứa khoảng 30-35million hồ sơ. Từ đó tôi đã hợp nhất thành một bảng lớn và gán một số chỉ mục tốt. Cho đến nay, tôi đã không phải phân vùng bảng này vì nó làm việc một điều trị, nhưng tôi đang giữ phân vùng trong tâm trí. Một điều mà tôi đã nhận thấy, so với khi dữ liệu bị phân hủy, và đó là việc nhập dữ liệu. Bây giờ nó chậm hơn, nhưng tôi có thể sống với điều đó vì công cụ Nhập có thể được viết lại; o)

Answer 11

Một bảng và sử dụng phân vùng bảng.

Tôi nghĩ rằng lời khuyên để sử dụng NOLOCK không được điều chỉnh dựa trên thông tin được cung cấp. NOLOCK có nghĩa là bạn sẽ nhận được kết quả không chính xác và không đáng tin cậy từ các truy vấn của bạn (đọc bẩn và ma). Trước khi sử dụng NOLOCK, bạn cần chắc chắn rằng đó không phải là vấn đề đối với khách hàng của bạn.

Answer 12

Trong một cơ sở dữ liệu được thiết kế phù hợp, đó không phải là một bản lưu trữ lớn và máy chủ SQl sẽ dễ dàng xử lý.

Một bảng đơn được chia tay thường là cách tốt nhất để đi. Cố gắng duy trì các bảng khách hàng độc lập riêng biệt là rất tốn kém trong thời hạn của thời gian và công sức và nhiều hơn nữa probne đến lỗi.

Đồng thời kiểm tra các truy vấn hiện tại của bạn nếu bạn gặp sự cố về hiệu suất. Nếu bạn không có các chỉ mục thích hợp (bạn có thể lập chỉ mục các trường khóa ngoài?), Các truy vấn sẽ chậm, nếu bạn không có các truy vấn có thể sargeable chúng sẽ chậm nếu bạn sử dụng các truy vấn con tương ứng hoặc con trỏ, chúng sẽ chậm. Bạn có quay trở lại nhiều dữ liệu hơn mức cần thiết không? Nếu bạn đã chọn * bất kỳ nơi nào trong mã sản xuất của mình, hãy loại bỏ nó và chỉ trả về các trường bạn cần. Nếu bạn đã sử dụng chế độ xem gọi chế độ xem gọi chế độ xem hoặc nếu bạn đã sử dụng bảng EAV, bạn sẽ có các hiệu suất ở cấp độ này. Nếu bạn cho phép một khuôn khổ để tự động tạo mã SQl, bạn cũng có thể có các truy vấn perforimng xấu. Hãy nhớ Profiler là bạn của bạn. Tất nhiên bạn cũng có thể có một vấn đề phần cứng, bạn cần một máy chủ chuyên dụng có kích thước khá tốt cho số lượng hồ sơ đó. Nó sẽ không hoạt động để chạy trên máy chủ web của bạn hoặc một hộp nhỏ.

Tôi khuyên bạn nên thuê một dba chuyên nghiệp với trải nghiệm điều chỉnh hiệu suất. Đó là những thứ khá phức tạp.Cơ sở dữ liệu desigend bởi các lập trình viên ứng dụng thường là những người thực hiện xấu khi họ nhận được một số lượng người dùng và bản ghi thực sự. Cơ sở dữ liệu PHẢI được thiết kế với tính toàn vẹn dữ liệu, hiệu suất và bảo mật. Nếu bạn không làm điều đó, những thay đổi của việc có chúng thực sự là mỏng.

Answer 13

Đây có phải là một bảng phẳng đơn (không có mô hình cụ thể) không? Thông thường trong kho dữ liệu, bạn có một mô hình dữ liệu chuẩn hóa (dạng bình thường thứ ba ít nhất - thường là trong mô hình quan hệ thực thể) hoặc bạn có dữ liệu chiều (phương pháp hoặc biến thể Kimball - thường là bảng thực tế với các bảng thứ nguyên được liên kết trong một tập hợp sao).

Trong cả hai trường hợp, chỉ mục đóng một phần lớn và phân vùng cũng có thể đóng vai trò trong việc truy vấn để thực hiện (nhưng phân vùng thường không về hiệu suất nhưng về bảo trì có thể thêm và thả phân vùng nhanh chóng) trên dữ liệu rất lớn bộ - nhưng nó thực sự phụ thuộc vào thứ tự tập hợp và các loại truy vấn.