8

this is a question on best practice, i understand that there are a lot of different options for doing this, but i would like your opinions as to how you would approach solving this problem. Please take it as though performance is critical in this system, in other words scalable.

I have recently found the wonders of graph database, so i came up with a theoretical situation where a company wants to manage it's customers relationships, and in order to do so they are going to use neo4j which is great, and allows for really great management of the customers, different staff members and their relationships, which is all great, however the company now wants to create a web based interface which will need authentication, and anyone in the neo4j database should be able to login to the system in order to see how they are related to other people in the company's database, so each user must have a password/email/id associated with their name.

So my question is, in this case scenario, is it best to store the password_hash/password_salt/id/email in a mysql database and then based on the node look it up on the mysql database. Or is it better to store the password_hash/password_salt/id/email in the hash tables inside the nodes.

Also each store has 1000s of products, and they can be stored in the graph database or i can store the products in the mysql database and then look up the product there, and do the changes there, because the products are not related to each other, so no point in storing them in the graph database, so should they be not stored there to improve performance?

So my question boils down to this: is it best for large projects to use a graph database along with the more common rdms database such as mysql? if not, then what is the point at which you start to use these two database systems?

apologies in advance for my lack of knowledge regarding database terminology.

4

3 回答 3

13

Graph DB 主要用于维护关系。如果应用程序有一个图形数据库，这并不意味着该应用程序需要将所有内容存储在图形数据库中。

Graph 上的每个节点请求都在内存中，因此如果您的节点中有不必要的属性，它将变得臃肿，并且可能会使事情变慢并占用更多内存。我通常决定什么需要进入图表，什么需要进入 DB简单的规则。

高级属性（定义关系和定义节点的其他重要属性）进入图形，而附加信息进入 RDMS。

例如，在 FB 中可能是 FBID，名称在 Graph 中，因为它定义了一个节点与另一个节点的关系。但是当用户点击某人的 Facebook ID 时，他/她会看到其他用户的出生日期、年龄、大学。所有这些都可以进入 RDBMS。

PS：RDMS还有一个优势，可以用来做快速分析。我知道图形也可以做到这一点，但我不确定它是否像 RDBMS 一样可扩展和简单。

这种方法的缺点是：你需要维护两个DBS。

于 2014-01-03T17:51:37.617 回答
3

除非您有一个经过验证的双数据库解决方案案例，否则我会说更少的移动部件会让您更敏捷，更能够快速改变事物。如果稍后您发现一个难以使用的用例，请权衡引入第二个存储的成本/收益。双数据库架构并非闻所未闻，但会带来开销。

具体到安全性，Neo4j 或任何其他合理的 NOSQL 解决方案没有理由不能做到这一点：http ://spring.neo4j.org/docs#tutorial_security

于 2012-07-04T09:52:00.893 回答
1

如果存在将数据存储在诸如 neo4j/orientDB 之类的图形数据库中没有多大意义的数据，则应该同时使用两者（与关系数据库相比，有些数据在图形数据库中会更好）。在一个平台上强制数据可能会导致性能/可扩展性问题。

于 2012-07-04T00:27:38.607 回答