Vài suy nghĩ về điều này:
Tôi sẽ thử mô hình hóa mô hình miền Neo4j của bạn để bao gồm các thuộc tính của mỗi nút trong biểu đồ. Bằng cách tách dữ liệu của bạn thành hai kho dữ liệu khác nhau, bạn có thể hạn chế một số thao tác mà bạn có thể muốn thực hiện.
Tôi đoán nó phụ thuộc vào những gì bạn sẽ làm với biểu đồ của bạn. Ví dụ:nếu bạn muốn tìm tất cả các nút được kết nối với một nút cụ thể có thuộc tính (ví dụ:tên, tuổi .. bất kỳ) là các giá trị nhất định, trước tiên bạn phải tìm ID nút chính xác trong cơ sở dữ liệu MySQL của mình và sau đó đi vào Neo4j? Điều này chỉ có vẻ chậm và quá phức tạp khi bạn có thể làm tất cả những điều này trong Neo4j. Vì vậy, câu hỏi đặt ra là:bạn có cần các thuộc tính của một nút khi duyệt qua biểu đồ không?
Dữ liệu của bạn sẽ thay đổi hay là dữ liệu tĩnh? Bằng cách có hai kho lưu trữ dữ liệu riêng biệt, nó sẽ phức tạp hóa vấn đề.
Mặc dù việc tạo thống kê bằng cách sử dụng cơ sở dữ liệu MySQL có thể dễ dàng hơn so với thực hiện mọi thứ trong Neo4j, nhưng mã cần thiết để duyệt qua biểu đồ để tìm tất cả các nút đáp ứng một tiêu chí xác định không quá khó. Những số liệu thống kê này sẽ thúc đẩy giải pháp của bạn.
Tôi không thể nhận xét về hiệu suất của truy vấn MySQL để chọn id nút. Tôi đoán điều đó phụ thuộc vào số lượng nút bạn sẽ cần chọn và chiến lược lập chỉ mục của bạn. Mặc dù vậy, tôi đồng ý về khía cạnh hiệu suất của mọi thứ khi xem qua biểu đồ.
Đây là một bài viết hay về điều này: MySQL so với Neo4j trên một Truyền tải biểu đồ quy mô lớn và trong trường hợp này, khi chúng nói lớn, chúng chỉ có nghĩa là một triệu đỉnh / nút và bốn triệu cạnh. Vì vậy, nó thậm chí không phải là một biểu đồ đặc biệt dày đặc.
