SQL không hoạt động tốt với 3+ bước nhảy. GraphDB thì có. Hãy tưởng tượng việc tìm tất cả các tài khoản trong vòng 3 bước nhảy từ một giao dịch nghi ngờ. Hoặc liên kết các hồ sơ khách hàng bị phân mảnh giữa các hệ thống bằng email và số điện thoại chung. Đây là các truy vấn duyệt đồ thị. SQL có thể xử lý các mối quan hệ nhưng không thể xử lý độ sâu. Chắc chắn, bạn có thể viết CTE đệ quy và tự kết nối. Điều đó hoạt động ở 1-2 bước nhảy. Nhưng khi đi sâu hơn, hai điều xảy ra: - Truy vấn trở nên khó đọc - Và hiệu suất giảm sút Mỗi bước nhảy thêm một kết nối tự thân. Đến bước nhảy 5-6, bạn đang nhìn vào các truy vấn chạy trong vài phút và sụp đổ dưới tải. Cùng một truy vấn trong Cypher: 𝗠𝗔𝗧𝗖𝗛 (𝘁:𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 {𝗶𝗱: '𝗧𝗫𝗡-𝟬𝟬𝟭'})-[:𝗜𝗡𝗩𝗢𝗟𝗩𝗘𝗦*𝟭..𝟯]-(𝗮:𝗔𝗰𝗰𝗼𝘂𝗻𝘁) 𝗥𝗘𝗧𝗨𝗥𝗡 𝗗𝗜𝗦𝗧𝗜𝗡𝗖𝗧 𝗮.𝗻𝗮𝗺𝗲, 𝗮.𝗽𝗵𝗼𝗻𝗲 3 dòng. Đọc như câu hỏi bạn đang đặt ra. Có thể mở rộng đến bất kỳ độ sâu nào. Đây là điều mà cơ sở dữ liệu đồ thị được xây dựng để làm. FalkorDB là một cái đáng để biết đến. Nó là mã nguồn mở. Và nó có cách tiếp cận kiến trúc khác so với hầu hết các DB đồ thị. Hầu hết các cơ sở dữ liệu đồ thị theo đuổi các con trỏ từ nút này sang nút khác trong quá trình duyệt. FalkorDB không làm như vậy. Nó được xây dựng trên GraphBLAS, một khung đại số tuyến tính mà đại diện cho các phép toán đồ thị dưới dạng các phép toán ma trận thưa. Mỗi bước nhảy trở thành một phép toán ma trận tối ưu hóa thay thế. Kết quả: - Hành vi bộ nhớ đệm tốt hơn - Tính toán song song qua các bước nhảy...