Do SSD làm giảm tính hữu dụng của Cơ sở dữ liệu


28

Tôi chỉ nghe nói về Robert Martin ngày hôm nay, và có vẻ như anh ta là một nhân vật đáng chú ý trong thế giới phần mềm, vì vậy tôi không có nghĩa là tiêu đề của tôi xuất hiện như thể đó là mồi nhử hoặc tôi đặt từ ngữ vào miệng anh ta, nhưng điều này chỉ đơn giản là làm thế nào tôi diễn giải những gì tôi nghe được từ anh ấy với kinh nghiệm và sự hiểu biết hạn chế của tôi.

Tôi đã xem một video ngày hôm nay (về kiến ​​trúc phần mềm), trong một cuộc nói chuyện của Robert C. Martin, và trong nửa sau của video, chủ đề về cơ sở dữ liệu là trọng tâm chính.

Từ sự hiểu biết của tôi về những gì anh ấy nói, có vẻ như anh ấy đã nói rằng SSD sẽ làm giảm tính hữu ích của cơ sở dữ liệu ( đáng kể ).

Để giải thích làm thế nào tôi đi đến giải thích này:

Ông đã thảo luận làm thế nào với ổ cứng / đĩa quay, lấy dữ liệu chậm. Tuy nhiên, những ngày này chúng tôi sử dụng SSD, ông lưu ý. Anh ấy bắt đầu với "RAM đang đến" và sau đó tiếp tục bằng cách đề cập đến các đĩa RAM, nhưng sau đó nói rằng anh ấy không thể gọi nó là đĩa RAM, vì vậy, chỉ cần nói RAM. Vì vậy, với RAM, chúng ta không cần các chỉ mục, vì mỗi byte đều mất cùng một thời gian để có được. ( đoạn này được tôi diễn giải )

Vì vậy, anh ta đề xuất RAM (như trong bộ nhớ máy tính) thay thế cho DB (như những gì tôi diễn giải câu nói của anh ta) không có ý nghĩa gì vì điều đó giống như nói rằng tất cả các bản ghi đều được xử lý trong bộ nhớ của ứng dụng ( trừ khi bạn lấy từ một tệp đĩa theo yêu cầu)

Vì vậy, tôi đã nghĩ đến RAM, anh ấy có nghĩa là SSD. Vì vậy, trong trường hợp đó, anh ấy nói rằng SSD làm giảm tính hữu ích của cơ sở dữ liệu. Anh ta thậm chí còn nói "Nếu tôi là Oracle, tôi sẽ sợ. Chính nền tảng của lý do tôi tồn tại là bốc hơi."

Từ hiểu biết nhỏ của tôi về SSD, không giống như ổ cứng đang O(n)tìm kiếm thời gian (tôi nghĩ), SSD đang ở gần O(1)hoặc gần như ngẫu nhiên. Vì vậy, đề nghị của anh ấy rất thú vị với tôi, vì tôi chưa bao giờ nghĩ về nó như thế. Lần đầu tiên tôi được giới thiệu vào cơ sở dữ liệu vài năm trước, khi một giáo sư mô tả các lợi ích so với hệ thống tệp thông thường, tôi đã kết luận vai trò chính của cơ sở dữ liệu về cơ bản là một hệ thống tệp được lập chỉ mục (cũng như tối ưu hóa, lưu trữ, truy cập đồng thời, v.v.), do đó, nếu các chỉ mục không cần thiết trong SSD, loại này làm cho cơ sở dữ liệu ít hữu ích hơn.

Bất kể điều đó, mặc dù rằng tôi là người mới, tôi thấy khó tin rằng chúng trở nên ít hữu ích hơn, vì mọi người vẫn sử dụng DB làm điểm chính trong ứng dụng của họ, thay vì hệ thống tệp thuần túy và cảm thấy như thể anh ta đang quá đơn giản vai trò của cơ sở dữ liệu.

Lưu ý : Tôi đã xem đến cuối để đảm bảo anh ấy không nói điều gì khác.

Để tham khảo: 42:22 là khi toàn bộ chủ đề cơ sở dữ liệu xuất hiện, 43:52 là khi anh ấy bắt đầu với "Tại sao chúng ta thậm chí có cơ sở dữ liệu"

Đây câu trả lời không nói SSD DBS tốc độ lên đáng kể. Câu hỏi này hỏi về cách tối ưu hóa được thay đổi.

Đối với TL; DR câu hỏi của tôi, sự ra đời của việc sử dụng SSD rộng rãi trên thị trường máy chủ (dù sắp ra mắt hay đã xảy ra) có làm giảm tính hữu ích của cơ sở dữ liệu không?

Có vẻ như những gì người trình bày đang cố gắng truyền đạt là với SSD, người ta có thể lưu trữ dữ liệu trên đĩa và không phải lo lắng về việc lấy lại chậm như thế nào với các ổ cứng cũ, như với SSD, thời gian tìm kiếm đã gần O(1)(Tôi nghĩ). Vì vậy, trong trường hợp điều đó là đúng, điều đó về mặt giả thuyết sẽ mất đi một trong những lợi thế của nó: lập chỉ mục, bởi vì lợi thế của việc có các chỉ mục cho thời gian tìm kiếm nhanh hơn đã không còn nữa.

Câu trả lời:


59

Có một số điều trong cơ sở dữ liệu nên được điều chỉnh khi bạn sử dụng SSD. Chẳng hạn, nói cho PostgreSQL bạn có thể điều chỉnh effective_io_concurrencyrandom_page_cost. Tuy nhiên, đọc nhanh hơn và truy cập ngẫu nhiên nhanh hơn không phải là cơ sở dữ liệu. Nó đảm bảo

Anh ấy chỉ sai về chỉ số. Nếu toàn bộ bảng có thể được đọc thành ram, một chỉ mục vẫn hữu ích. Đừng tin tôi? Hãy làm một thí nghiệm suy nghĩ,

  • Hãy tưởng tượng bạn có một bảng với một cột được lập chỉ mục.

    CREATE TABLE foobar ( id text PRIMARY KEY );
  • Hãy tưởng tượng rằng có 500 triệu hàng trong bảng đó.

  • Hãy tưởng tượng tất cả 500 triệu hàng được nối với nhau thành một tệp.

Cái gì nhanh hơn,

  1. grep 'keyword' file
  2. SELECT * FROM foobar WHERE id = 'keyword'

Nó không chỉ là về nơi dữ liệu được đặt, mà còn là cách bạn đặt hàng và những hoạt động bạn có thể thực hiện. PostgreSQL hỗ trợ các chỉ mục B-tree, Hash, GiST, SP-GiST, GIN và BRIN (và Bloom thông qua một phần mở rộng). Bạn sẽ thật ngu ngốc khi nghĩ rằng tất cả toán học và chức năng đó sẽ biến mất vì bạn có quyền truy cập ngẫu nhiên nhanh hơn.


31
Chỉ là một phụ lục - OP nên cẩn thận không kết hợp "quyền truy cập ngẫu nhiên" với "quyền truy cập theo địa chỉ nội dung". Như OP đã lưu ý, "truy cập ngẫu nhiên" có nghĩa là nhận được từng byte bộ nhớ là O (1). Tuy nhiên, TÌM dữ liệu trong "bộ nhớ truy cập ngẫu nhiên" đó vẫn yêu cầu tìm kiếm tuần tự thông qua nó; nghĩa là, bạn không thể yêu cầu bộ nhớ "tìm cho tôi dữ liệu giống như thế này " và đưa nó cho bạn một cách kỳ diệu.
Bob Jarvis - Tái lập Monica

2
@BobJarvis Bạn đã đúng. Nhận xét của bạn giúp làm rõ hơn nữa ví dụ "Cái gì nhanh hơn" của @ EvanCarroll về lý do tại sao lập chỉ mục và thậm chí cả vấn đề phụ, và chỉ cần nắm bắt O(1)là không đủ cho các trường hợp sử dụng mà DB cung cấp
Abdul

12

Dựa trên bài đăng của bạn, có một thông báo rõ ràng là tối ưu hóa thời gian tra cứu RDBMS đang được thay thế bằng phần cứng khiến thời gian IO không đáng kể.

Điều này là hoàn toàn đúng. SSD trên các máy chủ cơ sở dữ liệu kết hợp với RAM cao (thực tế) làm cho IO chờ ngắn hơn đáng kể. Tuy nhiên, lập chỉ mục và bộ nhớ đệm RDBMS vẫn có giá trị bởi vì ngay cả các hệ thống có lợi ích IO khổng lồ này cũng có thể và sẽ có các tắc nghẽn IO từ các truy vấn hoạt động kém do lập chỉ mục xấu. Điều này thường chỉ được tìm thấy trong các ứng dụng khối lượng công việc lớn hoặc các ứng dụng được viết kém.

Giá trị chính cho các hệ thống RDBMS nói chung là tính nhất quán dữ liệu, tính khả dụng của dữ liệu và tổng hợp dữ liệu. Việc sử dụng bảng tính excel, tệp csv hoặc phương pháp khác để giữ "cơ sở dữ liệu" không mang lại sự đảm bảo.

SSD không bảo vệ bạn khỏi máy chủ chính của bạn trở nên không khả dụng vì bất kỳ lý do gì (mạng, hỏng hệ điều hành, mất điện). SSD không bảo vệ bạn khỏi một sửa đổi dữ liệu xấu. SSD không giúp chạy phân tích nhanh hơn so với "chỉ có" chúng.


Mặc dù tôi đã hiểu rõ hơn, tôi đã hỏi trong bối cảnh lưu trữ dữ liệu SSD thô so với lưu trữ dữ liệu trên DB w / HDD và câu trả lời của bạn là trong bối cảnh DB trên SSD (do cách đặt câu hỏi kém từ tôi)
Abdul

4
@Abdul Sự so sánh đó là những cây cầu treo táo. Một thiết bị thô giúp bạn mở rộng dung lượng lưu trữ; một cơ sở dữ liệu giúp bạn có cách tổ chức và truy cập bộ lưu trữ đó theo mô hình dữ liệu. Quan điểm của Josh ở đây là nếu bạn đi sâu vào vấn đề này với ý tưởng sáng suốt rằng SSD thô là một điều tuyệt vời bởi vì nó "nhanh" và bạn sẽ viết mã để thực hiện tất cả lưu trữ dữ liệu của mình trên khối lượng thô đó , cuối cùng bạn sẽ viết một cơ sở dữ liệu.
Blrfl

8

Chú Bob có lẽ đã nói về cơ sở dữ liệu trong bộ nhớ như Redis hoặc Gemfire . Trong các cơ sở dữ liệu này, mọi thứ trong cơ sở dữ liệu thực sự được chứa trong RAM. Cơ sở dữ liệu có thể bắt đầu trống và được lưu trữ với dữ liệu có thời gian sử dụng ngắn (được sử dụng làm bộ đệm) hoặc cơ sở dữ liệu bắt đầu bằng cách tải mọi thứ từ đĩa và thay đổi điểm kiểm tra định kỳ vào đĩa.

Điều này ngày càng trở nên phổ biến vì RAM ngày càng rẻ và việc có một terabyte dữ liệu được lưu trữ trong cơ sở dữ liệu cụm trong bộ nhớ trở nên khả thi. Có rất nhiều trường hợp sử dụng trong đó tốc độ truy cập tức thời vào mọi thứ khiến cho việc đặt RAM trở nên có giá trị hơn là ngay cả một ổ đĩa nhanh như SSD. Bạn thậm chí có thể tiếp tục sử dụng SQL cho một số trong số này nếu nó có ý nghĩa.

Tại sao điều này nên lo lắng Oracle? Dữ liệu đang phát triển và không chắc RDBMS sẽ biến mất. Tuy nhiên, rất nhiều thời gian kỹ thuật của Oracle trong những năm qua đã đi vào các cách để làm cho việc truy xuất dữ liệu trên các đĩa quay thực sự nhanh chóng. Oracle sẽ cần phải thích ứng với một tầng lưu trữ hoàn toàn khác. Họ, với Cơ sở dữ liệu Oracle trong bộ nhớ , nhưng họ tiếp xúc với sự cạnh tranh khác so với trước đây. Hãy suy nghĩ về việc mất bao nhiêu thời gian để đảm bảo trình tối ưu hóa truy vấn chọn chiến lược phù hợp dựa trên bố cục của mọi thứ trên đĩa ....


À. Tôi chưa bao giờ biết có những thứ như cơ sở dữ liệu trong bộ nhớ
Abdul

1
Như một ví dụ khác, SQLite có thể chạy trong bộ nhớ nên không cần sử dụng cơ sở dữ liệu khác
user151019

8

Cộng đồng Wiki bài viết thu thập câu trả lời ban đầu để lại dưới dạng câu hỏi bình luận


Tôi sẽ nói ngược lại. Vì tốc độ đọc / ghi rất nhanh, giờ đây bạn có thể có được cơ sở dữ liệu được tăng tốc GPU (ví dụ BlazedDB hoặc Alenka ) để xử lý số nhanh hơn. Bây giờ bạn có thể có các truy vấn thậm chí phức tạp hơn chạy nhanh hơn. Bây giờ các truy vấn mà mọi người thậm chí không xem xét việc chạy có thể được chạy ở tốc độ hợp lý. Càng phức tạp và càng có nhiều dữ liệu thì bạn càng có lợi - cybernard

Trong khi Bob Martin đã xuất hiện từ lâu và ý kiến ​​của anh ta thường đáng để lắng nghe (nếu không đồng ý với :-), trong trường hợp này tôi nghĩ rằng anh ta đang lao vào đám đông "Cái chết của cơ sở dữ liệu quan hệ là do chúng ta" (trong đó Tôi là thành viên liên kết :-). Đối với một số điều trong các trường hợp hạn chế, một lập luận có phần thuyết phục có thể được đưa ra rằng các công nghệ cơ sở dữ liệu không liên quan có thể cung cấp một lợi thế. Tuy nhiên, điều đó đã được nói, IMO mô hình quan hệ, thiếu sót trong nhiều cách khác nhau và có thể, vẫn cung cấp mô hình cơ sở dữ liệu mục đích chung tốt nhất hiện nay. YMMV. - Bob Jarvis

Lý do chính khiến chúng tôi sử dụng cơ sở dữ liệu không phải vì các đĩa chậm (thực ra, ban đầu, được trích dẫn là lý do không sử dụng cơ sở dữ liệu), mà là vì dữ liệu phức tạp . Mục đích chính của cơ sở dữ liệu là cho phép nhiều ứng dụng / người dùng có thể tìm thấy dữ liệu chính xác và thậm chí có thể đồng thời thay đổi nó theo cách được kiểm soát. Làm điều đó một cách nhanh chóng chỉ là mục tiêu thứ yếu của cơ sở dữ liệu. - RBarryYoung

RDBMS sẽ không biến mất bất cứ lúc nào sớm; chúng là lựa chọn tốt nhất cho một số loại ứng dụng và NoQuery (Mongo, v.v.) là lựa chọn tốt nhất cho những loại khác. Ngựa cho các khóa học. - sh1rts

Cơ sở dữ liệu giúp tổ chức dữ liệu. Nó không thực sự được thiết kế để truy cập nhanh dữ liệu ở mọi nơi. - JI Tương

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.