Cơ sở dữ liệu SQL Server trên SSD - có lợi thế nào cho một tệp riêng cho mỗi bảng không?


19

Tôi đang tạo một cơ sở dữ liệu trong đó sẽ có khoảng 30 bảng, với mỗi bảng chứa hàng chục triệu hàng và mỗi bảng chứa một cột quan trọng duy nhất và cột khóa chính / ngoại khóa để tối đa hóa hiệu quả truy vấn khi đối mặt với nặng cập nhật và chèn thêm và sử dụng nhiều các chỉ mục được nhóm. Hai trong số các bảng sẽ chứa dữ liệu văn bản có độ dài thay đổi, với một trong số chúng chứa hàng trăm triệu hàng nhưng phần còn lại sẽ chỉ chứa dữ liệu số.

Vì tôi thực sự muốn vắt kiệt mọi hiệu năng cuối cùng ra khỏi phần cứng tôi có (khoảng 64GB RAM, SSD rất nhanh và 16 lõi), tôi đã nghĩ đến việc cho phép mỗi bảng có tệp riêng để không có vấn đề gì Tôi đang tham gia vào 2, 3, 4, 5 hoặc nhiều bảng, mỗi bảng sẽ luôn được đọc bằng một luồng riêng biệt và cấu trúc của mỗi tệp sẽ được liên kết chặt chẽ với nội dung của bảng, hy vọng sẽ giảm thiểu sự phân mảnh và làm cho nó nhanh hơn cho SQL Server để thêm vào nội dung của bất kỳ bảng nào.

Một cảnh báo, tôi bị kẹt trên SQL Server 2008 R2 Phiên bản web . Điều đó có nghĩa là tôi không thể sử dụng phân vùng ngang tự động, quy định đó là sự tăng cường hiệu suất.

Việc sử dụng một tệp trên mỗi bảng có thực sự tối đa hóa hiệu suất hay tôi đang xem xét các đặc điểm động cơ SQL Server tích hợp sẽ khiến việc này trở nên dư thừa?

Thứ hai, nếu sử dụng một tệp cho mỗi bảng là thuận lợi, tại sao create tablechỉ cung cấp cho tôi tùy chọn phân bổ bảng cho một nhóm tệp chứ không phải cho tệp logic cụ thể? Điều này sẽ yêu cầu tôi tạo một nhóm tệp riêng cho mỗi tệp trong kịch bản của mình, điều này gợi ý cho tôi rằng có lẽ SQL Server không hình dung được những lợi thế mà tôi cho rằng sẽ đến từ việc làm những gì tôi đề xuất.

Câu trả lời:


18

Tôi đã nghĩ đến việc cho phép mỗi bảng có tệp riêng của mình để không có vấn đề gì nếu tôi tham gia vào 2, 3, 4, 5 hoặc nhiều bảng, mỗi bảng sẽ luôn được đọc bằng một luồng riêng biệt và cấu trúc của mỗi tệp sẽ được liên kết chặt chẽ với các nội dung của bảng, hy vọng sẽ giảm thiểu sự phân mảnh và giúp SQL Server nhanh hơn để thêm vào nội dung của bất kỳ bảng đã cho nào

bạn nói cái gì vậy? Không chắc chắn bạn đã lấy thông tin từ đâu, nhưng bạn chắc chắn nên loại bỏ nguồn đó. Không có gì từ những gì bạn giả định ở đây là thực sự chính xác.

Nếu bạn muốn đọc một cuộc thảo luận tốt về hiệu suất SSD cho SQL Server, có một số loạt blog trên mạng. Như thường lệ, bài viết của Paul Randal là bài đọc hàng đầu:

Brent cũng có một bài thuyết trình hay về chủ đề: SQL trên SSD: Hot and Crazy Love và còn nhiều thứ khác nữa.

Xem qua tất cả các bài thuyết trình này, bạn sẽ nhanh chóng nhận thấy rằng tất cả chúng đều tập trung vào việc ghi vì đây là lúc hiệu suất của SSD xuất hiện. Từ ngữ bài viết của bạn gần như hoàn toàn về đọc, đó là một chủ đề khác nhau. Nếu đọc là điểm đau của bạn thì bạn nên nói về RAM, không phải về SSD và về các chiến lược truy vấn và lập chỉ mục phù hợp.


1
Đúng, tôi đã được cung cấp thông tin sai ở đâu đó dọc theo dòng nhưng như tôi đã nhận xét về câu trả lời của Stuart, tôi đã đặt câu hỏi để đảm bảo rằng tôi không dựa trên quyết định của mình về thông tin không chính xác. Cảm ơn các liên kết, tôi sẽ kiểm tra chúng.

17

Đề nghị đầu tiên của tôi sẽ là không đưa ra bất kỳ giả định nào về hiệu suất mà không thực hiện kiểm tra tải đối với cả hai cấu hình.

Tôi đoán từ trước khi thấy các cấu hình như vậy (có ý nghĩa trên giấy) trong quá khứ sẽ là việc mỗi bảng trên một tệp riêng biệt sẽ không có tác động tích cực có thể đo lường được đối với hiệu suất ... và độ phức tạp bổ sung sẽ bù đắp cho bất kỳ hiệu suất nào ngay cả khi chúng có thể đo lường được.

Cuối cùng, khi nói đến việc giảm từng giọt hiệu năng ra khỏi Máy chủ Sql, tôi giới thiệu bạn đến biểu đồ sau (cung cấp Microsoft của tôi):

nhập mô tả hình ảnh ở đây

Bất kỳ tối ưu hóa tiềm năng nào có thể được thực hiện từ góc độ ứng dụng đều dễ dàng vượt qua mọi tối ưu hóa có thể có ở mức cấu hình phần cứng / cơ sở dữ liệu ... vì vậy hãy tập trung sự chú ý của bạn một cách thích hợp.


Tất nhiên. Trong trường hợp của tôi, tôi đã tối ưu hóa toàn bộ hệ thống hết mức có thể và nút thắt chính mà tôi có ngay bây giờ là tốc độ truy vấn rất nhanh khi đối mặt với các cập nhật, xóa và chèn thường xuyên. Vì tôi sẽ tận dụng SQL Server để giải quyết vấn đề này, tôi muốn đảm bảo rằng tôi cho nó cơ hội tuyệt đối tốt nhất có thể để vận hành nhanh nhất có thể trên dữ liệu của mình.

@NathanRidley Ok, đã hiểu ... Tôi nghĩ câu trả lời thực sự trừ khi ai đó có tài nguyên nói "không bao giờ làm điều này", rằng cách hành động tốt nhất sẽ là so sánh hai cấu hình với khối lượng công việc thông thường của bạn và xem liệu có sự khác biệt có thể đo lường được không.
Michael Fredrickson

4

Như những người khác đã lưu ý, không có lợi ích trực tiếp từ một tệp trên mỗi bảng; đây là một bản tóm tắt tuyệt vời từ Steve Jones về cách huyền thoại này bắt nguồn: http://www.sqlservercentral.com/bloss/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

Bạn cũng có thể muốn điều tra một chế độ xem được phân vùng mà tôi tin là được hỗ trợ bởi Phiên bản web 2008. Có một số thủ thuật để mã hóa theo chế độ xem được phân vùng, nhưng bạn có thể bắt chước rất nhiều chức năng của các bảng được phân vùng tương đối dễ dàng.


2

Tôi nghĩ các tệp riêng biệt cho mỗi bảng sẽ không mang lại lợi ích hiệu suất. Các chỉ mục chính xác có thể có một hiệu suất tiềm năng (đọc đĩa) trên máy chủ cơ sở dữ liệu.

SQL Server 2008 R2 có hỗ trợ nén không? Nếu có, bật nó lên.

Sửa lỗi cho tôi nếu tôi sai.


Bạn có thể giải thích tại sao sẽ không có lợi ích hiệu suất? Ít nhất, hãy giải thích tại sao đây là trường hợp khi các tệp riêng biệt cho phép SQL Server sử dụng nhiều luồng để đọc.

Nếu bạn đặt tất cả các bảng trên nhóm riêng của mình nhưng trên cùng một ổ đĩa, hiệu suất sẽ bằng nhau trước khi phân vùng. Nhưng nếu bạn tách một số bảng thành nhóm của chúng trên một đĩa nhanh hơn khác, nó sẽ có lợi ích về hiệu suất. Bạn cũng có thể phân vùng ví dụ theo năm nếu bạn có nhiều dữ liệu phụ thuộc vào năm. Với kỹ thuật này, bạn có thể giữ dữ liệu được sử dụng nhiều nhất trên một đĩa nhanh hơn dữ liệu cũ. Bạn cũng có thể tách các chỉ mục nhưng chỉ khi bạn đặt chúng vào một đĩa vật lý mới sẽ có bất kỳ lợi ích hiệu suất nào.

Bạn nói đúng về các luồng song song (bảng / tệp) nhưng tôi nghĩ cho đến khi bạn chỉ có một đĩa vật lý thì hiệu suất đạt được sẽ nhỏ.

Và tôi khuyên bạn nên lấy một mảng RAID RAID mạnh mẽ cho cơ sở dữ liệu vì SSD sẽ chết sớm.
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.