Dung lượng bảng tối đa trong SQL Server 2008

Tôi có một ứng dụng chèn hơn 1 tỷ hàng hàng năm vào một bảng. Bảng này chứa một số varcharvà bigintcột và một cột blob là tốt.

1 tỷ hàng bao gồm dữ liệu lịch sử được lưu giữ cho mục đích theo dõi. Vì vậy, tôi đã tự hỏi liệu sẽ có giới hạn dung lượng bảng nếu tôi tiếp tục trong cấu trúc này theo bài viết MSDN này về kích thước bảng tối đa .

Kích thước tệp dữ liệu được đề cập trong liên kết đó có đề cập đến nhóm tệp dữ liệu bảng không?

sql-server-2008

— LỖ HỔNG
nguồn

@marc_s cảm ơn vì đã nắm bắt điều đó. vui lòng tham gia cùng chúng tôi trong The Heap , trong số những thứ khác, chúng tôi tập trung vào những điều này

— JNK

Kích thước tối đa của mỗi hàng là bao nhiêu?

— Nick Chammas

Câu trả lời:

Không có giới hạn thực tế ngoại trừ không gian đĩa. Tôi đọc bảng bạn liên kết đến hoàn toàn và kiểm tra nó.

Nếu bạn cần vượt quá 16TB, bạn cần nhiều tệp (một thủ tục đơn giản).

— sử dụng
nguồn

Tôi đoán điều này có thể đạt được bằng cách phân vùng bảng và bỏ qua phân vùng để sử dụng các nhóm tệp khác nhau, nếu tôi đúng?

— GAP

Điều đó thậm chí không cần thiết. Chỉ cần thêm một tệp mới (vào nhóm tệp hiện có). SQL Server sẽ bắt đầu lấp đầy tất cả các tệp. Nếu một tệp không thể phát triển được nữa, nó sẽ chỉ phát triển tệp khác.

— usr

một bảng trong máy chủ sql 2008 có thể xử lý số lượng lớn các bản ghi và như @usr đã đề cập, nó phụ thuộc vào dung lượng ổ đĩa nhưng khuyến nghị rằng nếu bảng của bạn có nhiều hàng và nó tiếp tục phát triển thì bạn sử dụng Bảng phân vùng http://technet.microsoft. com / en-us / library / dd578580 (v = sql.100) .aspx

Khi một bảng cơ sở dữ liệu tăng kích thước lên hàng trăm gigabyte trở lên, việc tải dữ liệu mới trở nên khó khăn hơn, loại bỏ dữ liệu cũ và duy trì các chỉ mục

thêm thông tin về nó

http://msdn.microsoft.com/en-us/l Library / ms190787.aspx

và cách triển khai http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/

— AmmarR
nguồn

Bạn cần phải thực sự cẩn thận về phân vùng mặc dù. Chức năng và chìa khóa cần được xem xét cẩn thận, cũng như trường hợp sử dụng. Trường logic để phân vùng trên có thể không bao giờ được sử dụng trong bất kỳ truy vấn nào, điều này sẽ giết chết hiệu suất.

— JNK

Đúng nhưng hàng tỷ hàng trong một bảng cũng sẽ có hiệu quả, cũng có tùy chọn chia dữ liệu của bạn trong nhiều bảng, ví dụ một bảng riêng cho mỗi năm và nếu bạn muốn xem tất cả dữ liệu bạn có thể sử dụng chế độ xem A nhưng tại ít nhất là không xác định và cập nhật sẽ nhanh hơn trên mỗi bảng

— AmmarR

chèn trên một bảng lớn không nhất thiết phải chậm, nó phụ thuộc vào khóa và chỉ mục. Tôi thực hiện tải hàng tháng khoảng 30m hàng vào một bảng có 700m hàng hiện có và chúng tôi không thực hiện bất kỳ phân vùng nào. Tôi đã thử phân vùng nhưng nó gây ra nhiều vấn đề hơn nó đã giải quyết. Đây thực sự là một câu hỏi nếu bạn muốn kiểm tra nó.

— JNK

Tôi đã suy nghĩ về việc di chuyển dữ liệu lịch sử của mình sang một bảng riêng biệt và tạo chế độ xem hợp nhất để ứng dụng có thể được sử dụng khi cần lịch sử truy vấn + dữ liệu mới nhất chiếm khoảng dưới 25% các truy vấn mà tôi có trong hệ thống. Điều này sẽ hiệu quả hơn so với việc có nhiều tệp dữ liệu hoặc chia bảng dựa trên cột đánh dấu dữ liệu mới nhất? Từ hoạt động IO nào sẽ hiệu quả hơn? Vì tôi nghi ngờ là nó sẽ giống nhau từ quan điểm IO trong cả hai giải pháp.

— GAP

bất kỳ cách tiếp cận nào bạn thực hiện đều có những cách thực hành tốt nhất có thể làm cho nó tốt hay xấu, ý tôi là nếu bạn có nhiều bảng thì truy vấn của bạn sẽ phức tạp và sẽ khó duy trì, nếu bạn có một bảng và sử dụng phân vùng bảng thì có những cân nhắc khác nhau như phiên bản sql của bạn phải là doanh nghiệp, v.v., có nhiều tệp dữ liệu được khuyến nghị cho các hoạt động IO tốt hơn nhưng nó cũng có các hoạt động tốt nhất, đối với hiệu suất sql không có cách nào dễ dàng ...

— AmmarR

Có lẽ Chế độ xem phân vùng sẽ hoạt động.

Từ bài viết MSDN xem phân vùng :

Các khung nhìn được phân vùng cho phép dữ liệu trong một bảng lớn được chia thành các bảng thành viên nhỏ hơn. Dữ liệu được phân vùng giữa các bảng thành viên dựa trên phạm vi giá trị dữ liệu trong một trong các cột. Phạm vi dữ liệu cho mỗi bảng thành viên được xác định trong ràng buộc CHECK được chỉ định trên cột phân vùng. Một khung nhìn sử dụng UNION ALL để kết hợp các lựa chọn của tất cả các bảng thành viên thành một tập kết quả duy nhất sau đó được xác định. Khi các câu lệnh CHỌN tham chiếu khung nhìn xác định một điều kiện tìm kiếm trên cột phân vùng, trình tối ưu hóa truy vấn sử dụng các định nghĩa ràng buộc CHECK để xác định bảng thành viên nào chứa các hàng.

Tôi không chắc nó khác với Bảng Parition mà AmmarR đã cung cấp thông tin về câu trả lời của anh ấy như thế nào.

— Adam porad
nguồn