Điều này Neo4j so với thời gian thực hiện RDBMS có đúng không?

Bối cảnh: Dưới đây là từ cuốn sách Cơ sở dữ liệu đồ thị , bao gồm một bài kiểm tra hiệu suất được đề cập trong cuốn sách Neo4j in Action :

Mối quan hệ trong một biểu đồ tự nhiên hình thành đường dẫn. Truy vấn, hoặc duyệt qua, biểu đồ bao gồm các đường dẫn sau. Do tính chất định hướng đường dẫn cơ bản của datamodel, phần lớn các hoạt động cơ sở dữ liệu đồ thị dựa trên đường dẫn được liên kết chặt chẽ với cách thức trình bày dữ liệu, làm cho chúng cực kỳ hiệu quả. Trong cuốn sách Neo4j in Action, Partner và Vukotic của họ thực hiện một thử nghiệm sử dụng cửa hàng quan hệ và Neo4j.

So sánh cho thấy rằng cơ sở dữ liệu đồ thị nhanh hơn đáng kể cho dữ liệu được kết nối so với cửa hàng quan hệ. Thử nghiệm của Vartotic và Vukotic tìm cách tìm bạn bè trong mạng xã hội, đến độ sâu tối đa là năm. Cho bất kỳ hai người được chọn ngẫu nhiên, có một con đường kết nối họ dài nhất là năm mối quan hệ? Đối với một mạng xã hội chứa 1.000.000 người, mỗi người có khoảng 50 người bạn, kết quả cho thấy mạnh mẽ rằng cơ sở dữ liệu đồ thị là lựa chọn tốt nhất cho dữ liệu được kết nối, như chúng ta thấy trong Bảng 2-1.

Bảng 2-1. Tìm bạn bè mở rộng trong cơ sở dữ liệu quan hệ so với tìm kiếm hiệu quả trong Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

Ở độ sâu hai (bạn bè của bạn bè) cả cơ sở dữ liệu quan hệ và cơ sở dữ liệu đồ thị hoạt động đủ tốt để chúng tôi xem xét sử dụng chúng trong một hệ thống trực tuyến. Trong khi truy vấn Neo4j chạy trong hai phần ba thời gian của mối quan hệ, một người dùng cuối sẽ hầu như không nhận thấy sự khác biệt về mili giây giữa hai lần. Tuy nhiên, vào thời điểm chúng tôi đạt đến độ sâu ba (bạn của bạn bè), tuy nhiên, rõ ràng cơ sở dữ liệu quan hệ không còn có thể xử lý truy vấn trong một khung thời gian hợp lý: ba mươi giây để hoàn thành sẽ hoàn toàn không thể chấp nhận được cho một hệ thống trực tuyến. Ngược lại, thời gian phản hồi của Neo4j vẫn tương đối bằng phẳng: chỉ một phần giây để thực hiện truy vấn, đủ chắc chắn cho một hệ thống trực tuyến.

Ở độ sâu bốn, cơ sở dữ liệu quan hệ thể hiện độ trễ làm tê liệt, làm cho nó thực sự vô dụng đối với một hệ thống trực tuyến. Thời gian của Neo4j cũng đã xuống cấp một chút, nhưng độ trễ ở đây là ngoại vi có thể chấp nhận được đối với một hệ thống trực tuyến đáp ứng. Cuối cùng, ở độ sâu năm, cơ sở dữ liệu quan hệ chỉ mất quá nhiều thời gian để hoàn thành truy vấn. Ngược lại, Neo4j trả về kết quả sau khoảng hai giây. Ở độ sâu năm, nó truyền tải gần như toàn bộ mạng là bạn của chúng tôi: đối với nhiều trường hợp sử dụng trong thế giới thực, chúng tôi có thể sẽ cắt bớt kết quả và thời gian.

Câu hỏi là:

• Đây có phải là một thử nghiệm hợp lý để mô phỏng những gì người ta có thể ngoại trừ tìm thấy trong một mạng xã hội? (Có nghĩa là các mạng xã hội thực thường có các nút với khoảng 50 người bạn chẳng hạn; có vẻ như mô hình " giàu trở nên giàu hơn " sẽ tự nhiên hơn đối với các mạng xã hội, mặc dù có thể sai.)
• Bất kể sự tự nhiên của thi đua, có lý do nào để tin rằng kết quả bị tắt, hoặc không thể thực hiện được?

Nhìn vào tài liệu này có tên là Anatomy of Facebook, tôi lưu ý rằng trung vị là 100. Nhìn vào biểu đồ hàm tích lũy, tôi có thể đặt cược rằng mức trung bình cao hơn, gần 200. Vì vậy, 50 dường như không phải là con số tốt nhất ở đây. Tuy nhiên tôi nghĩ rằng đây không phải là vấn đề chính ở đây.

Vấn đề chính là thiếu thông tin về cách sử dụng cơ sở dữ liệu.

Có vẻ hợp lý khi một bộ lưu trữ dữ liệu được thiết kế đặc biệt để các cấu trúc đồ thị hoạt động hiệu quả hơn các RDBM truyền thống. Tuy nhiên, ngay cả khi các RDBM không nằm trong các xu hướng mới nhất dưới dạng lưu trữ dữ liệu được lựa chọn, các hệ thống này vẫn phát triển liên tục trong một cuộc đua với kích thước của tập dữ liệu. Có nhiều loại thiết kế có thể, nhiều cách lập chỉ mục dữ liệu, các cải tiến liên quan đến đồng thời, v.v.

Để kết luận tôi nghĩ rằng liên quan đến khả năng tái tạo, nghiên cứu thiếu một mô tả thích hợp về cách thiết kế lược đồ cơ sở dữ liệu. Tôi không hy vọng rằng một cơ sở dữ liệu sẽ thống trị trên vua thẩm vấn như vậy, tuy nhiên tôi sẽ hy vọng rằng với một thiết kế được điều chỉnh tốt, sự khác biệt sẽ không quá lớn.

Có nhiều cách tốt / nhanh để mô hình hóa các biểu đồ trong RDBMS và các cách ngu ngốc / chậm.

• Một số sử dụng lập chỉ mục thông minh và Procs lưu trữ, giao dịch tải CPU và các bảng tạm thời được điều chỉnh trên các đĩa RAM để có tốc độ truy xuất đồ thị nhanh hơn.

• Một số sử dụng các đường dẫn biểu đồ được tính toán trước (điều này có thể ít khả thi hơn trong kịch bản mạng xã hội, nhưng trong một cây có phần lớn các nút là các nút lá, đó là một không gian đánh đổi khá tốt theo thời gian

• Một số chỉ đơn giản là tính toán trong một vòng lặp, sử dụng bảng tạm thời không được điều chỉnh. Từ số # được ném trong bài viết, có mùi giống như những gì họ đã làm (hiệu suất 30 giây trên tập dữ liệu khá nhỏ)

  Ví dụ, tôi có tính toán cây của riêng tôi.

  • Nó được gói gọn trong một kho lưu trữ được điều chỉnh cao

  • Mặc dù nó đang chạy trong bộ lưu trữ dữ liệu Sybase ASE15 có kích thước phần cứng dành cho doanh nghiệp, máy chủ đó được chia sẻ với một vài terabyte dữ liệu từ tất cả các ứng dụng doanh nghiệp khác , một số dữ liệu đói hơn nhiều so với của tôi; và không dành riêng để thực hiện các truy vấn của tôi.

  • Tôi không có quyền truy cập vào công cụ tăng tốc chính, bảng tạm thời trên đĩa RAM.

  • Một bộ dữ liệu đại diện mà tôi đang truy xuất dường như khớp với dữ liệu của họ đã nhận được một phần phụ 150.000 nút trong số liệu dữ liệu đầy đủ của nút 2,5M (độ sâu của cây không giới hạn, thay đổi trong khoảng từ 5 đến 15, nhưng mức độ trung bình nhỏ hơn của một nút đã cho 50 người bạn được liệt kê trong thí nghiệm)

  • Tôi đã điều chỉnh nó đến điểm mà truy vấn này ~ 30-45 giây. Điều chắc chắn nhất là KHÔNG thể hiện sự chậm lại theo cấp số nhân mà các số liệu trong câu hỏi dường như chỉ ra về hiệu suất RDBMS của họ, điều kỳ lạ tăng gấp đôi do không có sự tăng trưởng theo cấp số nhân trong tập kết quả (mà theo tôi là chỉ số không được điều chỉnh trên một chỉ số bảng tạm thời từ kinh nghiệm cá nhân).

Vì vậy, so sánh này rất có thể không chính xác và dựa trên thiết kế bên RDBMS kém, mặc dù như câu trả lời trước đã lưu ý, không thể xác định được nếu không có nguồn mở 100% định nghĩa mã và bảng của họ.