So sánh Cơ sở dữ liệu quan hệ và Cơ sở dữ liệu đồ thị

Ai đó có thể giải thích cho tôi những ưu điểm và nhược điểm của cơ sở dữ liệu quan hệ như MySQL so với cơ sở dữ liệu đồ thị như Neo4j không?

Trong SQL, bạn có nhiều bảng với nhiều id khác nhau liên kết chúng. Sau đó, bạn phải tham gia để kết nối các bảng. Từ quan điểm của một người mới, tại sao bạn lại thiết kế cơ sở dữ liệu để yêu cầu một phép nối thay vì có các kết nối rõ ràng dưới dạng các cạnh ngay từ đầu như với cơ sở dữ liệu đồ thị. Về mặt khái niệm, nó sẽ không có ý nghĩa gì đối với một người mới. Có lẽ có một lý do rất kỹ thuật nhưng phi khái niệm cho điều này?

Thực sự có lý do khái niệm đằng sau cả hai phong cách. Wikipedia về mô hình quan hệ và cơ sở dữ liệu đồ thị cung cấp những cái nhìn tổng quan tốt về điều này.

Sự khác biệt cơ bản là trong cơ sở dữ liệu đồ thị, các mối quan hệ được lưu trữ ở mức bản ghi riêng lẻ, trong khi trong cơ sở dữ liệu quan hệ, cấu trúc được xác định ở mức cao hơn (định nghĩa bảng).

Điều này có các phân nhánh quan trọng:

• Cơ sở dữ liệu quan hệ nhanh hơn nhiều khi hoạt động trên số lượng lớn các bản ghi. Trong cơ sở dữ liệu đồ thị, mỗi bản ghi phải được kiểm tra riêng lẻ trong khi truy vấn để xác định cấu trúc của dữ liệu, trong khi điều này được biết trước trong cơ sở dữ liệu quan hệ.
• Cơ sở dữ liệu quan hệ sử dụng ít không gian lưu trữ hơn, vì chúng không phải lưu trữ tất cả các mối quan hệ đó.

Việc lưu trữ tất cả các mối quan hệ ở mức bản ghi cá nhân chỉ có ý nghĩa nếu có nhiều sự thay đổi trong các mối quan hệ; nếu không bạn chỉ đang sao chép lặp đi lặp lại những thứ giống nhau. Điều này có nghĩa là cơ sở dữ liệu đồ thị rất phù hợp với các cấu trúc phức tạp, bất thường. Nhưng trong thế giới thực, hầu hết các cơ sở dữ liệu đều yêu cầu cấu trúc thông thường, tương đối đơn giản. Đây là lý do tại sao cơ sở dữ liệu quan hệ chiếm ưu thế.

Sự khác biệt chính giữa đồ thị và cơ sở dữ liệu quan hệ là cơ sở dữ liệu quan hệ hoạt động với các tập hợp trong khi cơ sở dữ liệu đồ thị hoạt động với các đường dẫn.

Điều này thể hiện theo những cách không mong muốn và không hữu ích cho người dùng RDBMS. Ví dụ: khi cố gắng mô phỏng các hoạt động đường dẫn (ví dụ như bạn của bạn bè) bằng cách tham gia đệ quy vào cơ sở dữ liệu quan hệ, độ trễ truy vấn tăng lên một cách khó lường và ồ ạt cũng như việc sử dụng bộ nhớ, chưa kể đến việc nó tra tấn SQL để diễn đạt các loại hoạt động đó. Nhiều dữ liệu hơn có nghĩa là chậm hơn trong cơ sở dữ liệu dựa trên tập hợp, ngay cả khi bạn có thể trì hoãn sự cố thông qua lập chỉ mục hợp lý.

Như Dan1111 đã gợi ý, hầu hết các cơ sở dữ liệu đồ thị không phải chịu đựng kiểu liên kết này vì chúng thể hiện các mối quan hệ ở mức cơ bản. Nghĩa là, các mối quan hệ tồn tại vật lý trên đĩa và chúng được đặt tên, định hướng và có thể được trang trí bằng các thuộc tính (đây được gọi là mô hình đồ thị thuộc tính, xem: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Mô hình ). Điều này có nghĩa là nếu bạn chọn, bạn có thể xem xét các mối quan hệ trên đĩa và xem cách chúng "tham gia" các thực thể. Do đó, các mối quan hệ là các thực thể hạng nhất trong cơ sở dữ liệu đồ thị và về mặt ngữ nghĩa mạnh hơn nhiều so với các mối quan hệ ngụ ý được sửa đổi trong thời gian chạy trong một cửa hàng quan hệ.

Vậy tại sao bạn nên quan tâm? Vì hai lý do:

1. Cơ sở dữ liệu đồ thị nhanh hơn nhiều so với cơ sở dữ liệu quan hệ cho dữ liệu được kết nối - một điểm mạnh của mô hình cơ bản. Hệ quả của điều này là độ trễ truy vấn trong cơ sở dữ liệu đồ thị tỷ lệ với mức độ của biểu đồ bạn chọn để khám phá trong một truy vấn và không tỷ lệ với lượng dữ liệu được lưu trữ, do đó làm giảm quá trình kết hợp .
2. Cơ sở dữ liệu đồ thị làm cho việc lập mô hình và truy vấn trở nên dễ chịu hơn nhiều, nghĩa là phát triển nhanh hơn và ít khoảnh khắc WTF hơn. Ví dụ, thể hiện tình bạn của một mạng xã hội thông thường bằng ngôn ngữ truy vấn Cypher của Neo4j MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

Dan1111 đã đưa ra một câu trả lời được gắn cờ là đúng. Một số điểm bổ sung đáng lưu ý khi vượt qua.

Đầu tiên, trong hầu hết mọi việc triển khai cơ sở dữ liệu đồ thị, các bản ghi được "ghim" bởi vì có một số lượng không xác định con trỏ trỏ vào bản ghi ở vị trí hiện tại của nó. Điều này có nghĩa là không thể xáo trộn một bản ghi đến một vị trí mới mà không để lại địa chỉ chuyển tiếp ở vị trí cũ hoặc phá vỡ một số lượng con trỏ không xác định.

Về mặt lý thuyết, người ta có thể xáo trộn tất cả các bản ghi cùng một lúc và tìm ra cách để xác định vị trí và sửa chữa tất cả các con trỏ. Trong thực tế, đây là một hoạt động có thể mất hàng tuần trên cơ sở dữ liệu đồ thị lớn, trong thời gian đó cơ sở dữ liệu sẽ phải không hoạt động. Nó chỉ là không khả thi.

Ngược lại, trong cơ sở dữ liệu quan hệ, các bản ghi có thể được cải tổ lại trên quy mô khá lớn và việc duy nhất phải làm là xây dựng lại bất kỳ chỉ mục nào đã bị ảnh hưởng. Đây là một hoạt động khá lớn, nhưng không ở đâu lớn bằng hoạt động tương đương đối với cơ sở dữ liệu đồ thị.

Điểm đáng chú ý thứ hai là world wide web có thể được coi là một cơ sở dữ liệu đồ thị khổng lồ. Các trang web chứa siêu liên kết và tham chiếu siêu liên kết, trong số những thứ khác, các trang web khác. Tham chiếu là thông qua URL, hoạt động giống như con trỏ.

Khi một trang web được chuyển đến một URL khác mà không để lại địa chỉ chuyển tiếp ở URL cũ, một số lượng siêu liên kết không xác định sẽ bị hỏng. Những liên kết bị hỏng này sau đó dẫn đến thông báo đáng sợ, "Lỗi 404: không tìm thấy trang" làm gián đoạn niềm vui của rất nhiều người lướt web.

Với cơ sở dữ liệu quan hệ, chúng ta có thể lập mô hình và truy vấn một biểu đồ bằng cách sử dụng các khóa ngoại và tự nối. Chỉ vì RDBMS 'chứa từ quan hệ không có nghĩa là chúng giỏi xử lý các mối quan hệ. Từ quan hệ trong RDBMS bắt nguồn từ đại số quan hệ chứ không phải từ quan hệ. Trong RDBMS, bản thân mối quan hệ không tồn tại như một đối tượng theo đúng nghĩa của nó. Nó cần được biểu diễn rõ ràng dưới dạng khóa ngoại hoặc ngầm định dưới dạng một giá trị trong bảng liên kết (khi sử dụng phương pháp mô hình hóa chung / phổ quát). Liên kết giữa các tập dữ liệu được lưu trữ trong chính dữ liệu.

Chúng ta càng tăng độ sâu tìm kiếm trong cơ sở dữ liệu quan hệ thì chúng ta cần thực hiện nhiều phép tự kết hợp hơn và hiệu suất truy vấn của chúng ta càng bị ảnh hưởng. Chúng ta càng đi sâu trong hệ thống phân cấp của mình, chúng ta cần tham gia nhiều bảng hơn và truy vấn của chúng ta càng chậm. Về mặt toán học, chi phí tăng theo cấp số nhân trong cơ sở dữ liệu quan hệ. Nói cách khác, các truy vấn và mối quan hệ của chúng ta càng phức tạp thì chúng ta càng nhận được nhiều lợi ích từ biểu đồ so với cơ sở dữ liệu quan hệ. Chúng tôi không gặp vấn đề về hiệu suất trong cơ sở dữ liệu biểu đồ khi điều hướng biểu đồ. Điều này là do cơ sở dữ liệu đồ thị lưu trữ các mối quan hệ dưới dạng các đối tượng riêng biệt. Tuy nhiên, hiệu suất đọc vượt trội đi kèm với chi phí ghi chậm hơn.

Trong một số tình huống nhất định, việc thay đổi mô hình dữ liệu trong cơ sở dữ liệu đồ thị dễ dàng hơn so với trong RDBMS, ví dụ: trong RDBMS nếu tôi thay đổi mối quan hệ bảng từ 1: n sang m: n Tôi cần áp dụng DDL với thời gian chết tiềm ẩn.

Mặt khác, RDBMS có lợi thế trong các lĩnh vực khác, chẳng hạn như tổng hợp dữ liệu hoặc thực hiện kiểm soát phiên bản có dấu thời gian trên dữ liệu.

Tôi thảo luận một số ưu và nhược điểm khác trong bài đăng trên blog của mình về cơ sở dữ liệu biểu đồ để lưu trữ dữ liệu

Trong khi mô hình quan hệ có thể dễ dàng biểu diễn dữ liệu được chứa trong mô hình đồ thị, chúng ta phải đối mặt với hai vấn đề quan trọng trong thực tế:

1. SQL thiếu cú ​​pháp để dễ dàng thực hiện việc duyệt đồ thị, đặc biệt là các lần duyệt mà độ sâu không xác định hoặc không bị ràng buộc. Ví dụ, sử dụng SQL để xác định bạn bè của bạn bè của bạn là đủ dễ dàng, nhưng rất khó để giải quyết vấn đề "mức độ tách biệt".
2. Hiệu suất giảm nhanh chóng khi chúng ta xem qua biểu đồ. Mỗi cấp độ truyền tải thêm đáng kể vào thời gian phản hồi truy vấn.

Tham khảo: Cơ sở dữ liệu thế hệ tiếp theo

Cơ sở dữ liệu đồ thị đáng để điều tra cho các trường hợp sử dụng mà chúng vượt trội, nhưng tôi có lý do để đặt câu hỏi về một số khẳng định trong các câu trả lời ở trên. Đặc biệt:

Cơ sở dữ liệu quan hệ nhanh hơn nhiều khi hoạt động trên số lượng lớn các bản ghi (gạch đầu dòng đầu tiên của dan1111)

Cơ sở dữ liệu đồ thị nhanh hơn nhiều so với cơ sở dữ liệu quan hệ cho dữ liệu được kết nối - một điểm mạnh của mô hình cơ bản. Hệ quả của điều này là độ trễ truy vấn trong cơ sở dữ liệu đồ thị tỷ lệ với mức độ của biểu đồ bạn chọn để khám phá trong một truy vấn và không tỷ lệ với lượng dữ liệu được lưu trữ, do đó sẽ loại bỏ bom tham gia. (Dấu đầu dòng đầu tiên của Jim Webber)

Nói cách khác, các truy vấn và mối quan hệ của chúng ta càng phức tạp thì chúng ta càng nhận được nhiều lợi ích từ biểu đồ so với cơ sở dữ liệu quan hệ. (Đoạn 2 của Uli Bethke)

Mặc dù những khẳng định này có thể có giá trị, nhưng tôi vẫn chưa tìm ra cách để trường hợp sử dụng cụ thể của mình phù hợp với chúng. Tham khảo: Cơ sở dữ liệu đồ thị hoặc Cơ sở dữ liệu quan hệ Phần mở rộng bảng thông thường: So sánh hiệu suất truy vấn đồ thị xoay vòng