Cấu hình SQL cho hiệu năng tối ưu SSD SSD hoặc HDD?


8

Có ai biết bất kỳ so sánh nào cho thấy SSD so với ổ cứng cho hiệu năng trong môi trường SQL không?

Tôi đang cố gắng hiểu loại lợi ích hiệu suất nào có thể đạt được bằng cách chuyển sang SSD.


1
Tôi chắc chắn rằng một bản sao của tiêu chuẩn SQL sẽ hoạt động tốt như nhau trên SSD như trên các ổ đĩa cứng dạng đĩa. Hoặc có lẽ bạn quan tâm đến việc triển khai tiêu chuẩn SQL cụ thể?
womble

Câu trả lời:


14

Nếu bạn đang thực hiện một số lượng lớn các lần đọc nhỏ, SSD sẽ nhanh hơn nhiều . Đây là một trong số ít những so sánh nổi xung quanh hiệu năng cơ sở dữ liệu. Nhìn vào biểu đồ dưới cùng cho câu trả lời ngắn.

Đối với hiệu suất thô, SSD cung cấp nhiều lợi thế, yếu tố chính là thời gian tìm kiếm có hiệu quả bằng 0, có nghĩa là tất cả các lần truy cập HD nhỏ mà cơ sở dữ liệu được xử lý nhanh hơn nhiều.

Tuy nhiên, có một số lo ngại với thế hệ hiện tại về thời gian viết, vì sau rất nhiều lần viết, một khối không thể sử dụng được nữa. Họ có thể viết khá nhiều, tôi tin rằng intel nói tròn một petabyte byte cho ổ đĩa 32 GB trước khi họ bắt đầu đạt đến mức kho nguy hiểm ... điều này sẽ chỉ trở nên tốt hơn theo thời gian.

Để hiểu rõ hơn về lý do tại sao chúng hoạt động tốt hơn nhiều, hãy đọc bài viết này từ Anandtech trên SSD . Anh ấy đi sâu vào chi tiết về các ổ đĩa, cái gì tốt, cái gì không, và cách thức hoạt động của chúng. Trên cùng cũng là một liên kết đến một bài viết tiếp theo bao gồm loạt ổ đĩa mới nhất.


2
Trong điều kiện hao mòn do chu kỳ ghi hạn chế, SSD tốt gần như an toàn cho đĩa quay ngày nay do sự kết hợp giữa khả năng ghi chu kỳ lớn hơn của từng ô, viết "thủ thuật" để giảm chu kỳ ghi yêu cầu và cân bằng hao mòn thuật toán. Ngay cả đối với các ứng dụng tải IO cao như cơ sở dữ liệu rất tích cực, SSD tốt vẫn không có khả năng lưu trữ trước khi thay thế thường xuyên sau đó là đĩa quay. Chỉ cần giữ thường xuyên, thường xuyên kiểm tra, sao lưu như với bất kỳ giải pháp lưu trữ.
David Spillett

Tôi đồng ý, đó là lý do tại sao tôi gọi nó là mối quan tâm không phải là trình dừng hiển thị ... một đĩa giá rẻ có vấn đề thực sự với vấn đề này ngay bây giờ và đó là vấn đề phần sụn. Trong vòng 6 tháng, tôi không nghĩ mức độ hao mòn thậm chí sẽ được đưa lên nữa, nó tiến triển rất tốt, rất nhanh.
Nick Craver

1
Câu trả lời tốt. Chỉ cần thêm vào nó tôi sẽ nghĩ rằng trong hầu hết các trường hợp, nhật ký nên vẫn còn trên một ổ cứng thông thường vì nó được ghi tuần tự và các ổ cứng có giá rẻ. Chỉ cần có cơ sở dữ liệu thực tế trên ổ SSD vì đó là nơi truy cập ngẫu nhiên.
PeteT

@PeteT - nó thay đổi / phụ thuộc một chút, hãy nhớ rằng một nhật ký cụ thể là tuần tự có, nhưng trên một máy chủ lưu trữ nhiều cơ sở dữ liệu (như Stack Exchange lưu trữ nhiều trang web tại cơ sở dữ liệu), hành vi thực tế gần với truy cập / ghi ngẫu nhiên hơn nhiều so với tuần tự, do đó, nó phụ thuộc vào những gì bạn đang chạy.
Nick Craver

Một điều tuyệt vời là khi một ổ SSD đã hết tuổi thọ và không thể ghi vào nữa, nó vẫn có thể đọc được. Bạn không thể nói rằng về một đĩa quay bị hỏng.
djangofan

4

Bạn có thể cài đặt hệ điều hành và phần mềm SQL trên ổ cứng tiêu chuẩn và sau đó thêm ổ SSD để giữ các tệp cơ sở dữ liệu của bạn. Điều này sẽ hạn chế số lần ghi mà ổ SSD gặp phải và cũng tối đa hóa dung lượng trống cho dữ liệu của bạn trên ổ đĩa.



2

Câu trả lời của Nick Craver là tốt; Tôi chỉ muốn thêm hai cảnh báo vào SSD mà tôi nghĩ mọi người nên biết:

a) Các vấn đề của SSD với hao mòn ghi sẽ không biến mất, chúng là nền tảng cho các tế bào flash được sử dụng. Các tế bào SLC có độ bền ghi cao hơn nhiều so với MLC, vì vậy OP nên xem xét việc đưa ổ SLC qua MLC. Tất nhiên, SLC cũng đắt hơn đáng kể.

b) Ổ đĩa hiện tại dữ liệu bộ nhớ cache trên ổ đĩa trước khi ghi nó ra. Do đó, có nguy cơ mất dữ liệu nếu nguồn bị cắt trong quá trình ghi. Đó là thứ bạn có thể làm việc xung quanh, nhưng bộ đệm có cả hiệu năng và giảm khuếch đại ghi.

IMHO không phải ở trên là thỏa thuận. Tôi sẽ sẵn sàng triển khai SSD để sản xuất ngay hôm nay, nhưng với một số kế hoạch đầu tiên.

  1. Nếu một rủi ro nhỏ về mất dữ liệu là không thể chấp nhận được, thì các ổ cứng thông thường của SAS bị tắt bộ đệm dữ liệu có thể là lựa chọn tốt hơn.
  2. Tôi nghĩ bạn nên đo lượng dữ liệu ghi vào ổ SSD trong một ngày bình thường. Dựa trên thông số này và các nhà sản xuất mặc thông số kỹ thuật, hãy tính tuổi thọ dự kiến ​​của SSD với kiểu sử dụng của bạn. Nếu tuổi thọ dự kiến ​​thấp hơn thời gian dự kiến ​​của máy chủ, thì hãy đặt ngày thay thế ưu tiên cho SSD. Giống như các bộ phận máy bay, trao đổi nó trước khi nó có khả năng thất bại.

Phụ tùng máy bay? Không phải là sự tương tự tốt nhất nếu bạn mở rộng nó sang các con thoi của NASAs, chạy trên các máy tính IBM AP101S với RAM 1GB khổng lồ và không có ổ cứng. Sự cần thiết phải dự đoán và độ tin cậy là trên tất cả các cân nhắc khác.
CJM

1

Một cái gì đó để giữ trong tâm trí.

Nếu bạn nhấn cơ sở dữ liệu đủ để việc đọc của bạn chậm lại và bạn cần SSD, thì bạn cần sửa chỉ mục của mình hoặc xem xét thêm RAM vào máy chủ.

Hầu hết các máy chủ cơ sở dữ liệu, một khi được điều chỉnh đầy đủ, không cần SSD để chạy tốt.


Đọc của tôi không thực sự chậm lại. Chúng tôi đang cố gắng tối ưu hóa truy vấn "lần truy cập đầu tiên" trong đó mất khoảng 120-130ms lần đầu tiên truy vấn được thực hiện và 80ms sau đó. Những lần này loại trừ việc tạo các kế hoạch truy vấn và đọc số liệu thống kê có liên quan. Chúng ta có thể thấy rằng sự khác biệt về thời gian trong trường hợp của chúng ta là dành cho việc đọc từ đĩa, vì vậy hãy cố gắng khám phá làm thế nào tôi có thể thực hiện cú đánh đầu tiên đó gần hơn với 80ms.
muỗng16

Vậy ngay cả sau lần chạy đầu tiên, nó vẫn mất 80ms? Có phải đó chủ yếu là dữ liệu đọc, hoặc rất nhiều CPU (tổng hợp hoặc sắp xếp)? Vẫn nghĩ rằng có rất nhiều chỗ để tối ưu hóa "truyền thống" trước khi đi đến các công nghệ lưu trữ kỳ lạ.
BradC

Nếu bạn phải vào đĩa trong lần chạy truy vấn đầu tiên, thì SQL sẽ loại bỏ dữ liệu khỏi bộ đệm vì một số lý do. Trước tiên bạn có thể muốn xem tuổi thọ trang của bạn là bao nhiêu. Nếu nó thấp thì sẽ có nhiều RAM hơn. Tỷ lệ nhấn bộ nhớ cache của bạn trước, trong và sau khi truy vấn là gì? Nếu nó dưới 99,8% hoặc hơn thì lập chỉ mục và nhiều RAM hơn theo thứ tự. Bạn đang thực hiện bất kỳ quét? Nếu vậy thì lập chỉ mục nhiều hơn có thể theo thứ tự.
mrdenny

Với khối lượng công việc nặng nề với bộ nhớ đệm ghi (tức là dữ liệu được cam kết thực tế vào đĩa trước khi cuộc gọi trở lại), bạn sẽ nhận được hiệu suất ghi tốt hơn đáng kể từ SSD, giả sử ứng dụng của bạn thực sự bị ràng buộc I / O. Lưu ý rằng đây là chiến lược lưu trữ ưu tiên cho SQL Server, đặc biệt là trên SAN và MS yêu cầu SAN đảm bảo hành vi này để có được chứng nhận để sử dụng với SQL Server.
Mối quan tâmOfTunbridgeWells

1

Hãy đọc bài viết này (khá cũ - 2009):

Tóm tắt: thay thế ổ đĩa 24 x 15k RPM bằng 6 ổ SSD (có sáu) và vẫn có hiệu suất cao hơn 35%. Điều này là với Intel X25M không còn là con chó hàng đầu cho SSD.

Đối với người cơ sở dữ liệu, điều này thật tuyệt vời khi bạn có thể có các máy chủ nhanh hơn nhỏ hơn sử dụng ít năng lượng hơn.


1

Một điều cần xem xét là có bản ghi transatcion trên ổ cứng và MDF của bạn trên SSD. Ngoài ra tuổi thọ sẽ phụ thuộc rất lớn vào loại ứng dụng. OLTP có thể ghi mặc dù nhanh chóng khi dữ liệu tĩnh hợp lý không có vấn đề.


1

Kinh nghiệm của riêng tôi đã được trộn lẫn ở đây ...

Thử nghiệm trên windows 7 với máy chủ sql 2008 express r2. Chạy trên máy tính để bàn i7 với Sandy Bridge và ram được cài đặt 12G (DDR3 tôi nghĩ sao?). Xin lỗi, thiết lập là máy tính để bàn, tôi chỉ sau khi xem có bao nhiêu bản ghi tôi có thể quản lý trên nền tảng i7 trước khi tôi xây dựng một máy chủ.

Lần đầu tiên tôi chạy các thử nghiệm này trên ổ đĩa 1.5TB 7200rpm đã cài đặt để có được thời gian cơ sở.

Bản ghi 10k với các procs cập nhật, tối ưu hóa các bảng để lưu trữ dữ liệu liên quan phổ biến trong một bảng phẳng, thêm các chỉ mục cho đến khi tôi lấy thời gian xuống vài giây làm điểm bắt đầu, sau đó tôi sao chép các bản ghi lên tới 1,2 triệu và có thời gian 0: 3: 37 cho các cập nhật tương tự. 3 1/2 phút không tệ cho thiết lập không đột kích này.

Sao chép các hồ sơ lên ​​tới 2,56 triệu giúp tôi có thời gian là 0h15: tăng gần gấp 5 lần. Có khả năng chủ yếu là do phân trang qua bộ nhớ 12G đã cài đặt.

Đã cài đặt ổ SSD và chuyển cơ sở dữ liệu qua, thời gian thực sự tăng lên chỉ hơn 20 phút. Tôi cho rằng điều này là do các tệp trang trên mỗi ổ cứng và không có mặc định nào trên ổ SSD vì nó không được cài đặt như ổ đĩa hệ điều hành (bluescreen galore khi tôi thử điều đó).

Đã thêm một trang vào ổ đĩa SSD và chạy lại bài kiểm tra, 0: 5: 52 -m vì vậy trang này dường như đã thực hiện thủ thuật nhưng tôi không chắc chắn một trang nào phù hợp với ổ SSD vì tất cả các lý do trên, họ rất nặng nề và có thể làm hao mòn quá mức trên ổ đĩa.

Một cảnh báo, tôi cũng đã kích hoạt Smartboost trên ổ đĩa đó và điều đó cũng có thể ảnh hưởng đến thời gian, sẽ chạy lại mà không có nó.

Điều tốt nhất của tôi về nó là việc thêm bộ nhớ ngày nay dễ dàng hơn và với chi phí có thể một cuộc đột kích 0 + 1 của các đĩa Hybrid sẽ làm gần như một công việc tốt mà không gặp vấn đề gì.

chỉnh sửa: vô hiệu hóa tệp hoán trang trên SSD và để tăng cường thông minh thực hiện công việc của nó, thời gian được cải thiện từ 5:51 phút đến 4:55 phút cho 2,56 triệu bản ghi với một loạt 3 bản cập nhật mỗi bản. Hãy thử bộ đệm ssd 8G trên ổ đĩa lai Seagate 750G tiếp theo. sau đó nếu điều đó không tệ, tôi sẽ thử chúng trong cuộc đột kích 0 + 1.

cập nhật mới nhất về điều này vì đây là một chủ đề cũ - nhưng tôi muốn đưa kết quả tôi nhận ra để ai đó có thể tìm thấy chúng.

Di chuyển cơ sở dữ liệu sang Seagate 750G Hybrid với bộ đệm SSD 8G Tôi đã chạy thử nghiệm một vài lần để bộ nhớ cache SSD có thể học được. Nó mang lại cho tôi thời gian 5:15 m: cho cùng một bài kiểm tra, cập nhật 2,56 triệu bản ghi - gần đủ với hiệu suất SSD (4:55 m: s với Intel Smartboost) để tôi xem xét chi phí.

Với khoảng 50 đô la trở lên ($ 239 so với $ 189 ngay bây giờ), hybrid cung cấp hơn 6 lần dung lượng lưu trữ và hiệu năng gần như tương tự, mà không cần chạy bất kỳ phần mềm bổ sung nào để tối ưu hóa. Trong một cuộc đột kích 0 + 1, tôi hy vọng sẽ cải thiện được thời gian và ổ đĩa này được bảo hành 5 năm, đây là hy vọng tôi sẽ không cần nó.


0

Cá nhân, tôi sẽ không sử dụng SSD vì những lý do đã được đề cập; họ sẽ dần dần chậm lại trước khi cuối cùng thất bại. Chúng tôi chưa thực sự biết khi nào điều này sẽ xảy ra - ước tính hiện tại chỉ là điều đó - ước tính. Bạn có nhớ khi tất cả chúng ta đã mua những đĩa CD 'không thể phá hủy' vào đầu / giữa thập niên 80 không? Vài năm sau, chúng tôi coi việc lưu trữ dữ liệu có thời hạn trên CD nhiều như việc sử dụng đĩa mềm.

Nếu bạn đã có phần cứng, hệ điều hành và DB của bạn được cấu hình đúng, thì bạn sẽ không cần phải đánh bạc trên SSD.

Trong một vài năm, khi các sản phẩm đã trưởng thành một chút, đó sẽ là một kịch bản khác. Nhưng cho đến lúc đó...


0

Bài báo Nghiên cứu của Microsoft liên quan đến chính nó với chi phí cho mỗi Gb hơn là hiệu suất đạt được. Nó không thực sự phù hợp và kiểm tra các ổ đĩa mà sử dụng thuật toán đúc retro dựa trên các tệp nhật ký từ các máy chủ thực tế.

Một số điều mà tôi nghĩ đến với SSD và SQL:

1 / Nếu bạn bỏ qua việc thêm các chỉ mục phù hợp, SSD sẽ dễ tha thứ hơn nhiều vì thời gian tìm kiếm ngẫu nhiên rất thấp.

2 / Chi phí giảm khi nghiên cứu được thực hiện và đối với các ứng dụng web nhỏ, giả sử chạy phần cuối của ứng dụng điện thoại, không phải máy chủ Exchange doanh nghiệp, hiệu suất có thể tiết kiệm chi phí khi thuê chuyên gia tư vấn điều chỉnh SQL Server.

3 / Một ổ SSD duy nhất có bản sao bóng chắc chắn phải rẻ hơn một loạt các trục chính trong tủ RAID và bộ điều khiển và các kết nối. Không đề cập đến sức mạnh và sưởi ấm và không gian rack.

4 / Spindles nổi tiếng là phần thường chết nhất trên máy tính. SSD không có bộ phận chuyển động và thời gian ngừng hoạt động trong một giờ có thể khiến giá của SSD chỉ trong một lần.

5 / Hao mòn là một vấn đề nhưng họ có cách để quản lý nó (liên quan đến các khối tán xạ) có thể xảy ra do dữ liệu bị phân mảnh ngẫu nhiên sẽ không làm chậm ổ SSD. Ngoài ra, một cơ sở dữ liệu nhỏ trên một đĩa lớn có thể sẽ không bị hao mòn kịp thời để mua một cái mới rẻ hơn trong tương lai.

6 / Có xu hướng về cơ sở dữ liệu phi quan hệ và tham gia vào tầng lớp trung lưu. Điều này thực sự có thể thay đổi mọi thứ: I / O thành các bảng không có đơn giản trên các ổ SSD trên các phân đoạn mà không bị phạt hiệu năng và với một đề xuất mở rộng đơn giản hơn nhiều. Cũng tiết kiệm giấy phép SQL Server trên mỗi phân đoạn.

7 / Đây là tất cả lý thuyết. Nếu bất cứ ai có thử nghiệm hiệu suất trong thế giới thực chống lại các trục chính, tôi rất muốn xem.

Luke

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.