Cây B và các cấu trúc dữ liệu khác sẽ trở nên lỗi thời với sự xuất hiện của các ổ đĩa trạng thái rắn?

Nhiều ứng dụng cơ sở dữ liệu (có lẽ là hầu hết?) Ngày nay sử dụng B-Tree và các biến thể để lưu trữ dữ liệu, vì cấu trúc dữ liệu này tối ưu hóa các hoạt động đọc, ghi và tìm kiếm trên đĩa cứng (và các hoạt động này lần lượt đóng vai trò quan trọng trong hiệu quả tổng thể của các cơ sở dữ liệu).

Tuy nhiên, liệu Solid Drive Drive (SSD) có thể loại bỏ hoàn toàn các ổ cứng truyền thống (HDD) không, liệu chúng ta có thể nói rằng B-Tree và các biến thể sẽ trở nên lỗi thời, nhường chỗ cho các cấu trúc dữ liệu hoạt động hiệu quả hơn trên bộ nhớ truy cập trực tiếp? Nếu vậy, những cấu trúc đó sẽ là gì? (ví dụ: bảng băm, cây AVL)

database data-structures

— Daniel Scocco
nguồn

Bạn đang hỏi liệu chúng sẽ trở nên lỗi thời từ quan điểm thực hiện cơ sở dữ liệu hay nói chung bởi vì có rất nhiều ứng dụng khác bên ngoài các ứng dụng cơ sở dữ liệu.

— Pemdas

Từ quan điểm cơ sở dữ liệu.

— Daniel Scocco

Câu trả lời:

B-Tree thường được sử dụng cho các chỉ mục cơ sở dữ liệu trên đĩa cứng, nhưng chúng có lợi thế ngay cả khi là cấu trúc dữ liệu trong bộ nhớ, với sự thừa kế bộ nhớ hiện đại với nhiều lớp bộ đệm và với bộ nhớ ảo. Ngay cả khi bộ nhớ ảo trên SSD, điều đó sẽ không thay đổi.

Tôi sử dụng một thư viện cây đa đường kiểu B + trong bộ nhớ mà tôi đã viết khá nhiều trong C ++. Nó có thể có lợi thế về hiệu suất - lý do ban đầu được viết là để cố gắng sử dụng bộ đệm tốt hơn - nhưng tôi phải thừa nhận rằng nó thường không hoạt động theo cách đó. Vấn đề là sự đánh đổi, có nghĩa là các mục phải di chuyển xung quanh trong các nút khi chèn và xóa, điều này không xảy ra đối với cây nhị phân. Ngoài ra, một số hack mã hóa cấp thấp mà tôi đã sử dụng để tối ưu hóa nó - tốt, có lẽ chúng gây nhầm lẫn và đánh bại trình tối ưu hóa, sự thật đã nói.

Dù sao, ngay cả khi cơ sở dữ liệu của bạn được lưu trữ trên ổ SSD, đó vẫn là một thiết bị lưu trữ hướng khối và vẫn có lợi thế khi sử dụng B-Plants và các cây đa đường khác.

NHƯNG khoảng mười năm trước, các thuật toán và cấu trúc dữ liệu lãng quên bộ nhớ cache đã được phát minh. Chúng không chú ý đến kích thước và cấu trúc của bộ đệm, v.v. - chúng làm cho (không có triệu chứng) sử dụng tốt nhất có thể của bất kỳ chế độ thừa kế bộ nhớ. Cây B cần được "điều chỉnh" theo một kiểu thừa kế bộ nhớ cụ thể để sử dụng tốt nhất (mặc dù chúng hoạt động khá tốt đối với một phạm vi biến thể khá rộng).

Cấu trúc dữ liệu không biết bộ nhớ cache thường không được nhìn thấy trong tự nhiên, nếu có, nhưng đến lúc chúng có thể làm cho cây nhị phân trong bộ nhớ thông thường trở nên lỗi thời. Và họ cũng có thể chứng minh giá trị đối với đĩa cứng và SSD, vì họ không quan tâm kích thước trang bộ nhớ cache kích thước cụm hoặc đĩa cứng là gì.

Bố cục của Van Emde Boas rất quan trọng trong cấu trúc dữ liệu bị lãng quên trong bộ nhớ cache.

Khóa học thuật toán MIT OpenC thảoware bao gồm một số phạm vi bảo hiểm của các cấu trúc dữ liệu lãng quên bộ nhớ cache.

— Steve314
nguồn

Hấp dẫn. Bạn đã đưa ra một số gợi ý hay (không có ý định chơi chữ!) Để khám phá chủ đề này hơn nữa. Cảm ơn.

— Daniel Scocco

Khóa học MIT này cũng có thông tin về cấu trúc dữ liệu lãng quên bộ nhớ cache.

— dan_waterworth

Xin chào, ý bạn là B-tree sẽ lỗi thời, vì cấu trúc dữ liệu bị lãng quên trong bộ nhớ cache chứ không phải do SSD? Nhưng làm thế nào về các cấu trúc dữ liệu khác, như quản lý khối trong DBMS?

— Yang Bo

@ user955091 - Ý tôi là do cấu trúc dữ liệu bị lãng quên trong bộ nhớ cache (có nghĩa là các cấu trúc có ý nghĩa tối ưu trong mô hình không biết bộ nhớ cache), nhưng lúc đó tôi đã hơi quá lời về chúng. Các cấu trúc dữ liệu khác sẽ không biến mất bất cứ lúc nào sớm. Đối với một điều, bộ đệm không phải là vấn đề hiệu suất duy nhất - song song thực hiện các yêu cầu khác nhau. Bên cạnh đó, cần đặt hàng dựa trên khóa thường là một trường hợp đặc biệt - thông thường, các bảng băm là vua. Có thể khó thấy bố cục "ngẫu nhiên" là thân thiện với bộ đệm, nhưng một lần truy cập để lấy trực tiếp mục đó là khó đánh bại - bạn không cần địa phương.

— Steve314

Một tiên nghiệm, vâng, hầu hết các công cụ cơ sở dữ liệu sẽ phải được viết lại vì B-Tree sẽ không còn là cấu trúc dữ liệu hiệu quả nhất để lưu trữ dữ liệu, vì địa phương đó rất quan trọng trong một ổ đĩa cứng, nơi đĩa di chuyển chậm và dữ liệu được tìm nạp trong các khối, có nghĩa là bất kỳ thay đổi nào đối với dữ liệu cần phải:

Di chuyển đầu đến đúng vị trí trên đĩa (~ 10ms).
Đợi đĩa quay (ở tốc độ 10k vòng / phút, có nghĩa là 167 vòng quay mỗi giây, nhưng trung bình chúng tôi chỉ chờ nửa vòng quay, vì vậy ~ 3ms).
Đọc khối (~ 3ms).
Sửa đổi trong RAM. (~ 10ns)
Di chuyển đầu đến đúng vị trí trên đĩa một lần nữa (~ 10ms một lần nữa).
Đợi đĩa quay lại (~ 3ms lần nữa).
Viết khối (~ 3ms).

Đó là 10 + 3 + 3 + 10 + 3 + 3 = 34 ms

Trung bình, làm tương tự trên SSD chỉ là 1ms, bất kể vị trí trên đĩa.

Và vì hashtable nhanh hơn nhiều, chúng ta có thể nghĩ rằng hashtable sẽ là sự thay thế tốt hơn.

Vấn đề duy nhất là hashtables không được bảo quản theo thứ tự và do đó không thể tìm thấy tiếp theo và trước đó như Van Emde Boas.

Xem:

Tại sao tìm thấy tiếp theo và trước đó là quan trọng? Hãy tưởng tượng nhận được tất cả các phần tử lớn hơn x và nhỏ hơn z, bạn cần sử dụng các chỉ mục với tìm trước và tìm tiếp theo.

Chà, vấn đề duy nhất là chúng tôi chưa tìm thấy hashtables với khả năng bảo toàn trật tự. Có thể kích thước của thùng trong cây B sẽ rất quan trọng nhưng điều đó được giải quyết bằng các thuật toán lãng quên bộ đệm.

Vì vậy, tôi sẽ nói đây là một vấn đề kết thúc mở.

— Wilhelm Van Ende Boas
nguồn

Một bảng băm là (thông thường) bộ nhớ cache WRT lãng quên mô hình hóa hiệu suất của nó, nhưng điều đó không có nghĩa là nó hiệu quả trong mô hình đó. Vấn đề là các hàm băm thường được thiết kế để phân tán các mục "ngẫu nhiên" - đó là lý do tại sao các bảng băm không có thứ tự và cũng là lý do tại sao chúng có địa phương kém. Điều đó có nghĩa là ngay cả khi bạn có thể xác định một chuỗi các mục bằng các phím liền kề, bạn sẽ không thể hưởng lợi từ việc đọc hai hoặc nhiều mục trên mỗi khối (SSD vẫn là thiết bị chặn).

— Steve314

Tất nhiên băm cũng đôi khi được gọi là "chuyển đổi quan trọng" và biến đổi không phải là "ngẫu nhiên" - có lẽ nó có thể xác định một hàm băm cho phép truy cập tuần tự hợp lý hiệu quả (không loại bỏ sự tìm kiếm - thông tin bị mất do hàm băm, sau tất cả - nhưng giảm thiểu nó) và mang lại một số lợi ích cục bộ trong khi vẫn giữ cho các va chạm băm hiếm.

— Steve314