B-Tree vs Hash Table

Trong MySQL, kiểu chỉ mục là cây b và việc truy cập một phần tử trong cây b là theo thời gian phân bổ theo lôgarit O(log(n)).

Mặt khác, truy cập một phần tử trong bảng băm là trong O(1).

Tại sao bảng băm không được sử dụng thay vì b-tree để truy cập dữ liệu bên trong cơ sở dữ liệu?

Bạn chỉ có thể truy cập các phần tử bằng khóa chính của chúng trong bảng băm. Điều này nhanh hơn so với thuật toán cây ( O(1)thay vìlog(n) ), nhưng bạn không thể chọn phạm vi ( mọi thứ ở giữa xvày ). Các thuật toán cây hỗ trợ điều này trong Log(n)khi các chỉ mục băm có thể dẫn đến việc quét toàn bộ bảng O(n). Ngoài ra, chi phí không đổi của các chỉ số băm thường lớn hơn ( không có yếu tố trong ký hiệu theta, nhưng nó vẫn tồn tại ). Ngoài ra, các thuật toán cây thường dễ bảo trì hơn, phát triển theo dữ liệu, quy mô, v.v.

Chỉ mục băm hoạt động với kích thước băm được xác định trước, vì vậy bạn sẽ có một số "nhóm" nơi lưu trữ các đối tượng. Các đối tượng này được lặp lại nhiều lần để thực sự tìm thấy đối tượng phù hợp bên trong phân vùng này.

Vì vậy, nếu bạn có kích thước nhỏ, bạn có nhiều chi phí cho các phần tử nhỏ, kích thước lớn dẫn đến việc quét thêm.

Các thuật toán bảng băm ngày nay thường mở rộng quy mô, nhưng việc mở rộng quy mô có thể không hiệu quả.

Thực sự có các thuật toán băm có thể mở rộng. Đừng hỏi tôi cách hoạt động của nó - nó cũng là một bí ẩn đối với tôi. AFAIK chúng đã phát triển từ việc nhân rộng có thể mở rộng, nơi việc băm lại không dễ dàng.

Nó được gọi là RUSH - R eplication U nder S calable H tro, và các thuật toán đó do đó được gọi là thuật toán RUSH.

Tuy nhiên, có thể có điểm mà chỉ mục của bạn vượt quá kích thước có thể chấp nhận được so với kích thước băm của bạn và toàn bộ chỉ mục của bạn cần được xây dựng lại. Thông thường đây không phải là vấn đề, nhưng đối với các cơ sở dữ liệu khổng lồ-khổng lồ, việc này có thể mất vài ngày.

Việc đánh đổi các thuật toán cây là nhỏ và chúng phù hợp với hầu hết mọi trường hợp sử dụng và do đó được mặc định.

Tuy nhiên, nếu bạn có một trường hợp sử dụng rất chính xác và bạn biết chính xác những gì và chỉ những gì sẽ cần thiết, bạn có thể tận dụng các chỉ mục băm.

Trên thực tế, có vẻ như MySQL sử dụng cả hai loại chỉ mục hoặc bảng băm hoặc cây b theo liên kết sau .

Sự khác biệt giữa việc sử dụng b-tree và hash table là ở chỗ cái trước cho phép bạn sử dụng so sánh cột trong các biểu thức sử dụng các toán tử =,>,> =, <, <= hoặc BETWEEN, trong khi cái sau chỉ được sử dụng cho so sánh bình đẳng sử dụng các toán tử = hoặc <=>.

Độ phức tạp về thời gian của các hashtable chỉ không đổi đối với các hashtable có kích thước đủ lớn (cần có đủ nhóm để chứa dữ liệu). Kích thước của một bảng cơ sở dữ liệu không được biết trước vì vậy bảng phải được băm lại ngay bây giờ và sau đó để có được hiệu suất tối ưu từ một bảng băm. Việc làm lại cũng rất tốn kém.

Tôi nghĩ Hashmap cũng không chia tỷ lệ và có thể tốn kém khi toàn bộ bản đồ cần được băm lại.

Chọn DB / OS dựa trên băm và hoạt động tốt. Ngày nay, với nhiều bộ nhớ hơn để hỗ trợ các bảng băm thưa thớt hiệu quả và băm dự phòng để hỗ trợ các truy vấn có phạm vi khiêm tốn, tôi muốn nói rằng hàm băm có thể vẫn chưa có vị trí của nó (một số muốn có các dạng đối sánh tương tự khác ngoài phạm vi, chẳng hạn như ký tự đại diện và regexps ). Chúng tôi cũng khuyên bạn nên sao chép để giữ cho các chuỗi va chạm liền nhau khi phân cấp bộ nhớ có sự khác biệt lớn về tốc độ.