neo4j - đồ thị cơ sở dữ liệu cùng với một cơ sở dữ liệu quan hệ?

Question

đây là câu hỏi về thực hành tốt nhất, tôi hiểu rằng có rất nhiều tùy chọn khác nhau để thực hiện việc này, nhưng tôi muốn ý kiến ​​của bạn về cách bạn tiếp cận giải quyết vấn đề này. Hãy lấy nó như thể hiệu suất là rất quan trọng trong hệ thống này, nói cách khác là khả năng mở rộng. Gần đây tôi đã tìm thấy những điều kỳ diệu của cơ sở dữ liệu đồ thị, vì vậy tôi đã đưa ra một tình huống lý thuyết, nơi một công ty muốn quản lý mối quan hệ khách hàng của mình, và để làm như vậy họ sẽ sử dụng neo4j đó là tuyệt vời, và cho phép để quản lý thực sự tuyệt vời của khách hàng, nhân viên khác nhau và mối quan hệ của họ, tất cả đều tuyệt vời, tuy nhiên công ty hiện muốn tạo giao diện dựa trên web cần xác thực và bất kỳ ai trong cơ sở dữ liệu neo4j đều có thể đăng nhập vào hệ thống để xem chúng liên quan đến những người khác trong cơ sở dữ liệu của công ty như thế nào, vì vậy mỗi người dùng phải có mật khẩu/email/id được liên kết với tên của họ. Vì vậy, câu hỏi của tôi là, trong trường hợp này kịch bản, là tốt nhất để lưu trữ password_hash/password_salt/id/email trong một cơ sở dữ liệu mysql và sau đó dựa trên nút tìm nó trên cơ sở dữ liệu mysql. Hoặc là tốt hơn để lưu trữ password_hash/password_salt/id/email trong bảng băm bên trong các nút.

Ngoài ra, mỗi cửa hàng có 1000 sản phẩm và có thể lưu trữ trong cơ sở dữ liệu đồ thị hoặc tôi có thể lưu trữ sản phẩm trong cơ sở dữ liệu mysql và sau đó tìm sản phẩm ở đó và thực hiện thay đổi ở đó liên quan đến nhau, do đó, không có điểm trong việc lưu trữ chúng trong cơ sở dữ liệu đồ thị, do đó, chúng sẽ không được lưu trữ ở đó để cải thiện hiệu suất?

Vì vậy, câu hỏi của tôi nắm này: nó là tốt nhất cho các dự án lớn sử dụng một cơ sở dữ liệu đồ thị cùng với cơ sở dữ liệu rdms phổ biến hơn như mysql? nếu không, thì điểm mà tại đó bạn bắt đầu sử dụng hai hệ thống cơ sở dữ liệu này là gì?

xin lỗi trước vì sự thiếu hiểu biết của tôi về thuật ngữ cơ sở dữ liệu.

Answer 1

Graph DB được sử dụng chủ yếu cho việc duy trì mối quan hệ. Nếu ứng dụng có biểu đồ DB không có nghĩa là ứng dụng cần lưu trữ mọi thứ trong Đồ thị DB.

Mọi yêu cầu nút trên biểu đồ nằm trong bộ nhớ và do đó nếu bạn có các thuộc tính không cần thiết trong nút, nó sẽ bị cồng kềnh và có thể làm mọi việc chậm hơn và chiếm nhiều bộ nhớ hơn. Tôi thường quyết định xem cần gì trong DB theo quy tắc rất đơn giản.

Thuộc tính cấp cao (xác định mối quan hệ và các thuộc tính quan trọng khác xác định nút) đi vào biểu đồ trong khi thông tin bổ sung đi vào RDMS.

Ví dụ trong FB có thể là FBID, Tên đi vào biểu đồ vì nó xác định mối quan hệ của một nút với nút khác.Nhưng khi người dùng nhấp vào ID facebook ai đó, anh/cô ấy sẽ được nhìn thấy người dùng khác DOB, Tuổi tác, Cao đẳng. Tất cả những điều này có thể đi vào RDBMS.

PS: RDMS có lợi thế khác, nó có thể được sử dụng để phân tích nhanh. Tôi biết với đồ thị cũng bạn có thể làm điều đó nhưng tôi không chắc chắn nếu nó như là khả năng mở rộng và dễ dàng như RDBMS.

Nhược điểm của phương pháp này là: Bạn cần duy trì hai DBS.

Answer 2

Bạn nên sử dụng cả hai trong trường hợp có dữ liệu mà không có ý nghĩa nhiều để lưu trữ nó trong một DB đồ thị như neo4j/orientDB (và một số dữ liệu sẽ tốt hơn trong một DB đồ thị trái ngược với một DB quan hệ). Việc buộc dữ liệu trên một nền tảng có thể gây ra các vấn đề với hiệu suất/khả năng mở rộng xuống dòng.

Answer 3

Trừ khi bạn có một trường hợp chứng minh cho một giải pháp hai-DB, tôi muốn nói ít bộ phận chuyển động sẽ giữ cho bạn nhanh nhẹn hơn, có khả năng hơn để thay đổi mọi thứ một cách nhanh chóng. Nếu sau đó bạn tìm thấy một trường hợp sử dụng đó là khó khăn, sau đó cân nhắc chi phí/lợi ích của việc giới thiệu một lưu trữ thứ hai. Một kiến ​​trúc hai DB không phải là chưa từng nghe, nhưng đi kèm với một chi phí.

cụ thể đối với an ninh, không có lý do tại sao Neo4j hoặc bất kỳ giải pháp NoSQL hợp lý khác không thể làm được điều đó: http://spring.neo4j.org/docs#tutorial_security