Sự ra đời của SSD có bất kỳ hàm ý nào cho việc tối ưu hóa cơ sở dữ liệu không?


26

Hôm nay tôi đã duyệt qua một cuốn sách về tối ưu hóa SQL Server và dường như một số ý tưởng nhất định được dựa trên một mô hình lưu trữ tuyến tính. Vì SSD có mô hình lưu trữ hoàn toàn khác nhau, liệu chúng có thay đổi trò chơi theo cách liên quan đến cách người ta nghĩ về điều chỉnh hoặc tối ưu hóa cơ sở dữ liệu không?


Với SSD, có vẻ như bạn cần tối ưu hóa nhiều hơn để giảm thiểu hao mòn hơn là tăng hiệu suất thô ...
Trezoid

suy nghĩ thú vị và một số câu trả lời thú vị, +1
vẽ

Câu trả lời:


9

Vâng, họ thay đổi trò chơi. Tối ưu hóa dựa trên các đặc điểm của đĩa từ tính quay (như thời gian tìm kiếmđộ trễ quay ) có thể không liên quan trên các ổ SSD. Một bài báo gần đây * được xuất bản trong FITME 2010 trình bày một thuật toán tối ưu hóa truy vấn mới dựa trên các đặc điểm của SSD.

Tuy nhiên, những thay đổi này có thể sẽ là những thay đổi cấp thấp (ví dụ như thuật toán lưu trữ và truy xuất) có thể được các nhà phát triển cơ sở dữ liệu triển khai hiệu quả. Họ có thể sẽ không ảnh hưởng đến người dùng cơ sở dữ liệu nhiều.

* IEEE Xplore - Tối ưu hóa truy vấn lưu trữ theo định hướng cột cho cơ sở dữ liệu dựa trên flash


3
Có - nhưng hầu hết các tối ưu hóa cơ sở dữ liệu đã biến mất khi chúng tôi chỉ đưa mọi thứ vào ram. Khi 64Gb của RaM rẻ hơn so với một chuyên gia SQL, mọi thứ đã thay đổi, không chắc chắn thêm bao nhiêu SSD vào đó
Martin Beckett

3
@Martin đồng ý. Mặt khác, đã có một quyết định chuyển hướng theo chiều ngang (đám mây, v.v.) thay vì theo chiều dọc (các hộp DB trị giá 500 nghìn đô la) gần đây. Các hệ thống phân tán có thể nhận được các cải tiến hiệu suất phi tuyến tính toàn cầu từ loại tối ưu hóa tuyến tính cục bộ này. Điều này thường có thể là một mô hình chi phí tốt hơn là tốt.
Rein Henrichs

8

Hiệu suất

SSD là hiệu suất: chúng không phải tìm kiếm, và thông lượng là rực rỡ. Hầu hết các phần mềm xử lý các đĩa, ở mức độ chúng được tối ưu hóa, được tối ưu hóa để giảm số lượng tìm kiếm đồng bộ. Làm như vậy, họ giới thiệu các máy chủ phức tạp. Với sự ra đời của việc ghi nhanh, không cần tìm đến lưu trữ liên tục, các hệ thống lưu trữ dữ liệu mới sẽ không còn đòi hỏi sự phức tạp như vậy nữa.

Độ bền

SSD hiện có tỷ lệ thất bại cao. SSD của bạn sẽ thất bại. SSD của bạn sẽ thất bại ở tốc độ cao hơn nhiều so với đĩa từ. Bạn phải làm việc xung quanh điều này với sao chép, sao lưu, vv Điều này giới thiệu tập hợp phức tạp của riêng nó.


1
Ừm, cái gì? SSD có tỷ lệ thất bại cao? Tỷ lệ thất bại hàng năm đối với SSD ít hơn đáng kể so với ổ cứng. Cho đến nay, rất ít người đã tìm cách xả hết các ghi có sẵn trên SSD, đặc biệt là với các bộ điều khiển tiên tiến hơn (ví dụ như SandForce của LSI).
Mircea Chirea

5

Việc giảm giá lưu trữ có tác động sâu sắc hơn nhiều.

Trước khi có SQL, chúng tôi đã có cơ sở dữ liệu mạng và phân cấp siêu tối ưu hóa trong đó các DBA phải lên kế hoạch cẩn thận cho việc sắp xếp dữ liệu theo dõi và hình trụ.

Cơ sở dữ liệu SQL kém hiệu quả hơn nhiều. Nhưng bây giờ các đĩa rẻ, lớn và nhanh, chúng tôi hầu như không quan tâm.

Cơ sở dữ liệu NoQuery ("Tài liệu") có thể kém hiệu quả hơn SQL một chút vì không có khả năng ánh xạ logic-vật lý tương tự giữa lược đồ logic SQL và lược đồ vật lý cơ bản của tệp hoặc không gian bảng hoặc bất cứ thứ gì. Và chúng tôi hầu như không quan tâm.

Các cải tiến hiệu suất SSD có thể bị mất trong các thay đổi do sử dụng cơ sở dữ liệu NoQuery theo cách chúng tôi thiết kế hệ thống tổng thể.


2

Vấn đề chính với việc tối ưu hóa mọi thứ cho SSD phải liên quan đến cách chúng ghi dữ liệu. Một ổ cứng truyền thống thường lưu trữ dữ liệu trong các khu vực nhỏ khoảng 512 byte và thực sự có thể thao tác các khu vực trực tiếp ở mức hoặc thậm chí dưới mức đó.

SSD có một số nhược điểm liên quan đến ghi:

  • Kích thước ghi khối tối thiểu khoảng 4-8KB.
  • Việc ghi chỉ có thể được thực hiện trên cơ sở toàn trang thường là 256KB.
  • Chỉ các khối trống có thể được viết vào.

Một kịch bản ác mộng điển hình, được gọi là khuếch đại Ghi , là khi bạn muốn ghi một byte đơn vào một vị trí trên đĩa có một số khối đã được sử dụng. Để ghi vào đó, trước tiên bạn cần sao chép toàn bộ trang 256KB vào bộ nhớ, xóa toàn bộ khối, thay đổi byte đơn trong trang, sau đó ghi lại toàn bộ trang 256KB đã sửa đổi. Vì vậy, để viết một byte đơn, đã có khoảng nửa megabyte "lưu lượng truy cập"!

Có rất nhiều tối ưu hóa cho vấn đề này được triển khai ở cấp độ SSD, bộ điều khiển và thậm chí cả hệ điều hành, nhưng chắc chắn DBMS có thể có lợi bằng cách điều chỉnh các tối ưu hóa này cho hoạt động cụ thể của chúng.

Tuy nhiên, đây không phải là điều mà người dùng cơ sở dữ liệu (như, sử dụng cơ sở dữ liệu trong ứng dụng của họ) cần phải suy nghĩ, vì nó sẽ phụ thuộc nhiều vào các quyết định thiết kế / triển khai ở cấp DBMS.


2

Từ những gì tôi thu thập được từ blog ServerFault , các máy chủ cơ sở dữ liệu phải có phần cứng nặng nề. Máy chủ cơ sở dữ liệu của các trang web trao đổi ngăn xếp đang chạy SSD (xem http://blog.serverfault.com/post/our-st Storage-decision / ) và tôi sẽ tưởng tượng rằng tối ưu hóa truy vấn vẫn rất cần thiết. CPU và bộ nhớ được ảnh hưởng bởi các truy vấn cơ sở dữ liệu cũng như IO.

Tuy nhiên, hiệu suất cơ sở dữ liệu phụ thuộc rất nhiều vào IO, vì vậy SSD chắc chắn sẽ giúp ích.


1

Vâng, vì những lý do tất cả mọi người đã nêu.

Tôi đã nghe một podcast nói rằng các khối RDBMS lớn như Oracle, SQL Server, v.v. sẽ bắt đầu được "tùy chọn" nếu chúng có thể xử lý tách biệt đúng cách. Phát hiện nếu đó là ổ SSD và tối ưu hóa cho phù hợp.

Có rất nhiều mã bổ sung được tích hợp vào bộ nhớ đệm và ghi dữ liệu mà đơn giản là không cần thiết nữa.

Thú vị hơn nữa là RAMAN và các biến thể của nó. Về cơ bản, một ổ đĩa cứng được tạo ra từ chip RAM với bộ lưu trữ X giờ tích hợp và khả năng ghi nền để lưu trữ ổ cứng dài hạn.

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.