SQL Server: số hàng tối đa trong bảng [đã đóng]

Tôi phát triển phần mềm lưu trữ nhiều dữ liệu trong một trong các bảng cơ sở dữ liệu của nó (SQL Server phiên bản 8, 9 hoặc 10). Giả sử, khoảng 100.000 bản ghi được chèn vào bảng đó mỗi ngày. Đây là khoảng 36 triệu bản ghi mỗi năm. Vì sợ rằng tôi sẽ mất hiệu suất, tôi quyết định tạo một bảng mới hàng ngày (một bảng có tên ngày hiện tại) để giảm số lượng bản ghi trên mỗi bảng.

Bạn có thể vui lòng cho tôi biết, liệu đó có phải là một ý kiến ​​hay không? Có giới hạn bản ghi cho các bảng máy chủ SQL không? Hoặc bạn có biết có bao nhiêu bản ghi (nhiều hơn hoặc ít hơn) có thể được lưu trữ trong một bảng trước khi hiệu suất bị giảm đáng kể?

Thật khó để đưa ra một câu trả lời chung cho điều này. Nó thực sự phụ thuộc vào số lượng yếu tố:

• kích thước hàng của bạn là bao nhiêu
• loại dữ liệu bạn lưu trữ (chuỗi, đốm màu, số)
• bạn làm gì với dữ liệu của mình (chỉ cần giữ nó ở dạng lưu trữ, truy vấn nó thường xuyên)
• bạn có chỉ mục trên bảng của mình không - có bao nhiêu
• thông số kỹ thuật máy chủ của bạn là gì

Vân vân.

Như đã trả lời ở những nơi khác ở đây, 100.000 một ngày và do đó mỗi bảng là quá mức cần thiết - tôi đề xuất hàng tháng hoặc hàng tuần, thậm chí hàng quý. Bạn càng có nhiều bảng thì cơn ác mộng bảo trì / truy vấn càng lớn.

Đây là một số Thông số kỹ thuật về dung lượng tối đa cho SQL Server 2008 R2

• Kích thước cơ sở dữ liệu: 524,272 terabyte
• Cơ sở dữ liệu cho mỗi phiên bản của SQL Server: 32,767
• Nhóm tệp trên mỗi cơ sở dữ liệu: 32,767
• Tệp trên mỗi cơ sở dữ liệu: 32.767
• Kích thước tệp (dữ liệu): 16 terabyte
• Kích thước tệp (nhật ký): 2 terabyte
• Hàng trên mỗi bảng: Bị giới hạn bởi bộ nhớ khả dụng
• Bảng trên mỗi cơ sở dữ liệu: Bị giới hạn bởi số lượng đối tượng trong cơ sở dữ liệu

Tôi có một bảng ba cột chỉ với hơn 6 Tỷ hàng trong SQL Server 2008 R2.

Chúng tôi truy vấn nó mỗi ngày để tạo biểu đồ phân tích hệ thống từng phút cho khách hàng của chúng tôi. Tôi đã không nhận thấy bất kỳ lần truy cập hiệu suất cơ sở dữ liệu nào (mặc dù thực tế là nó tăng ~ 1 GB mỗi ngày khiến việc quản lý các bản sao lưu liên quan nhiều hơn tôi muốn).

Cập nhật tháng 7 năm 2016

Chúng tôi đã thực hiện đến ~ 24,5 tỷ hàng trước khi các bản sao lưu trở nên đủ lớn để chúng tôi quyết định cắt bớt các bản ghi cũ hơn hai năm (~ 700 GB được lưu trữ trong nhiều bản sao lưu, kể cả trên các băng đắt tiền). Cần lưu ý rằng hiệu suất không phải là động lực đáng kể trong quyết định này (tức là nó vẫn hoạt động tốt).

Đối với bất kỳ ai nhận thấy mình đang cố gắng xóa 20 tỷ hàng khỏi SQL Server, tôi thực sự khuyên bạn nên sử dụng bài viết này . Mã liên quan trong trường hợp liên kết chết (đọc bài viết để được giải thích đầy đủ):

ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO

BEGIN TRY
    BEGIN TRANSACTION
        -- Bulk logged 
        SELECT  *
        INTO    dbo.bigtable_intermediate
        FROM    dbo.bigtable
        WHERE   Id % 2 = 0;

        -- minimal logged because DDL-Operation 
        TRUNCATE TABLE dbo.bigtable;  

        -- Bulk logged because target table is exclusivly locked! 
        SET IDENTITY_INSERT dbo.bigTable ON;
        INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
        SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
        SET IDENTITY_INSERT dbo.bigtable OFF;
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
END CATCH

ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO

Cập nhật tháng 11 năm 2016

Nếu bạn dự định lưu trữ nhiều dữ liệu này trong một bảng: đừng. Tôi thực sự khuyên bạn nên xem xét phân vùng bảng (theo cách thủ công hoặc với các tính năng tích hợp nếu bạn đang chạy phiên bản Enterprise). Điều này làm cho việc loại bỏ dữ liệu cũ dễ dàng như cắt bớt một bảng mỗi lần một lần (tuần / tháng / v.v.). Nếu bạn không có Enterprise (chúng tôi không có), bạn có thể chỉ cần viết một tập lệnh chạy mỗi tháng một lần, loại bỏ các bảng cũ hơn 2 năm, tạo bảng của tháng tiếp theo và tạo lại một chế độ xem động tham gia tất cả các phân vùng các bảng với nhau để dễ dàng truy vấn. Rõ ràng "mỗi tháng một lần" và "cũ hơn 2 năm" nên được bạn xác định dựa trên những gì phù hợp với trường hợp sử dụng của bạn.

Tôi không biết giới hạn hàng, nhưng tôi biết các bảng có hơn 170 triệu hàng. Bạn có thể tăng tốc bằng cách sử dụng các bảng được phân vùng (2005+) hoặc các dạng xem kết nối nhiều bảng.

Tôi không biết cụ thể MSSQL, nhưng 36 triệu hàng không phải là lớn đối với cơ sở dữ liệu doanh nghiệp - làm việc với cơ sở dữ liệu máy tính lớn, 100.000 hàng nghe giống như một bảng cấu hình đối với tôi :-).

Mặc dù tôi không phải là một fan hâm mộ lớn của một số phần mềm của Microsoft, nhưng đây không phải là Access mà chúng ta đang nói đến ở đây: Tôi cho rằng họ có thể xử lý các kích thước cơ sở dữ liệu khá lớn với DBMS doanh nghiệp của họ.

Tôi nghi ngờ những ngày có thể đã quá tốt để phân chia nó, nếu thực sự nó cần phải phân chia.

Chúng tôi có các bảng trong SQL Server 2005 và 2008 với hơn 1 Tỷ hàng trong đó (30 triệu được thêm hàng ngày). Tôi không thể tưởng tượng được việc mỗi ngày lại đi xuống tổ chuột để chia nó thành một chiếc bàn mới.

Rẻ hơn nhiều khi thêm dung lượng đĩa thích hợp (cái mà bạn cần) và RAM.

Nó phụ thuộc, nhưng tôi sẽ nói rằng tốt hơn là giữ mọi thứ trong một bảng vì mục đích đơn giản đó.

100.000 hàng mỗi ngày thực sự không phải là một con số quá lớn. (Tùy thuộc vào phần cứng máy chủ của bạn). Cá nhân tôi đã thấy MSSQL xử lý tới 100 triệu hàng trong một bảng duy nhất mà không gặp bất kỳ vấn đề nào. Miễn là bạn giữ các chỉ mục của mình theo thứ tự thì mọi thứ sẽ tốt. Điều quan trọng là phải có đống bộ nhớ để các chỉ mục không cần phải được hoán đổi ra đĩa.

Mặt khác, nó phụ thuộc vào cách bạn đang sử dụng dữ liệu, nếu bạn cần thực hiện nhiều truy vấn và dữ liệu không chắc sẽ cần thiết kéo dài nhiều ngày (vì vậy bạn sẽ không cần phải tham gia các bảng), nó sẽ nhanh hơn để tách nó ra thành nhiều bảng. Điều này thường được sử dụng trong các ứng dụng như điều khiển quy trình công nghiệp, nơi bạn có thể đọc giá trị trên 50.000 dụng cụ cứ sau 10 giây. Trong trường hợp này, tốc độ là cực kỳ quan trọng, nhưng đơn giản thì không.

Chúng tôi đã làm tràn một khóa chính số nguyên một lần (~ 2,4 tỷ hàng) trên bảng. Nếu có giới hạn hàng, bạn sẽ không bao giờ đạt được nó ở mức chỉ 36 triệu hàng mỗi năm.

Bạn có thể điền vào bảng cho đến khi bạn có đủ dung lượng đĩa. Để có hiệu suất tốt hơn, bạn có thể thử chuyển sang SQL Server 2005, sau đó phân vùng bảng và đặt các phần trên các đĩa khác nhau (nếu bạn có cấu hình RAID thực sự có thể giúp bạn). Chỉ có thể phân vùng trong phiên bản doanh nghiệp của SQL Server 2005. Bạn có thể xem ví dụ về phân vùng tại liên kết này: http://technet.microsoft.com/en-us/magazine/cc162478.aspx

Ngoài ra, bạn có thể thử tạo các khung nhìn cho phần dữ liệu được sử dụng nhiều nhất, đó cũng là một trong những giải pháp.

Hy vọng điều này đã giúp ...

Bảng lớn nhất mà tôi gặp trên SQL Server 8 trên Windows2003 là 799 triệu với 5 cột. Nhưng liệu nó có tốt hay không sẽ được đo lường dựa trên SLA và trường hợp sử dụng - ví dụ: tải 50.000-100.000.000 bản ghi và xem nó có còn hoạt động hay không.

SELECT Top 1 sysobjects.[name], max(sysindexes.[rows]) AS TableRows, 
  CAST( 
    CASE max(sysindexes.[rows]) 
      WHEN 0 THEN -0 
      ELSE LOG10(max(sysindexes.[rows])) 
    END 
    AS NUMERIC(5,2)) 
  AS L10_TableRows 
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id] 
WHERE sysobjects.xtype = 'U' 
GROUP BY sysobjects.[name] 
ORDER BY max(rows) DESC

Phân vùng bảng hàng tháng. Đó là cách tốt nhất để xử lý các bảng có lưu lượng lớn hàng ngày, có thể là oracle hoặc MSSQL.