基于图的数据库(http://neo4j.org/)的用例是什么? [英] What are the use cases of Graph-based Databases (http://neo4j.org/)?

问题描述

我已经使用了Relational DB很多，因此决定尝试其他可用类型.

I have used Relational DB's a lot and decided to venture out on other types available.

这个特殊的产品看起来不错，而且很有前途: http://neo4j.org/

This particular product looks good and promising: http://neo4j.org/

有人使用过基于图形的数据库吗?从可用性角度来看，优缺点是什么?

Has anyone used graph-based databases? What are the pros and cons from a usability prespective?

您在生产环境中使用过这些吗?促使您使用它们的要求是什么?

Have you used these in a production environment? What was the requirement that prompted you to use them?

推荐答案

我在上一份工作中使用了图形数据库.我们没有使用neo4j，它是在Berkeley DB之上构建的内部工具，但它是相似的.它用于生产(现在还是).

I used a graph database in a previous job. We weren't using neo4j, it was an in-house thing built on top of Berkeley DB, but it was similar. It was used in production (it still is).

我们使用图数据库的原因是系统存储的数据以及系统对数据进行的操作恰好是关系数据库的弱点，而恰恰是图数据库的强项.该系统需要存储缺少固定模式并通过关系链接在一起的对象的集合.为了对数据进行推理，系统需要执行很多操作，这些操作将在图形数据库中进行几次遍历，但这在SQL中将是非常复杂的查询.

The reason we used a graph database was that the data being stored by the system and the operations the system was doing with the data were exactly the weak spot of relational databases and were exactly the strong spot of graph databases. The system needed to store collections of objects that lack a fixed schema and are linked together by relationships. To reason about the data, the system needed to do a lot of operations that would be a couple of traversals in a graph database, but that would be quite complex queries in SQL.

图模型的主要优点是开发速度快和灵活性高.我们可以在不影响现有部署的情况下快速添加新功能.如果潜在客户想要导入自己的一些数据并将其嫁接到我们的模型上，通常可以由销售代表在现场完成.当我们设计新功能时，灵活性也有所帮助，使我们免于尝试将新数据压缩为严格的数据模型.

The main advantages of the graph model were rapid development time and flexibility. We could quickly add new functionality without impacting existing deployments. If a potential customer wanted to import some of their own data and graft it on top of our model, it could usually be done on site by the sales rep. Flexibility also helped when we were designing a new feature, saving us from trying to squeeze new data into a rigid data model.

拥有一个怪异的数据库，使我们能够构建许多其他怪异的技术，从而为我们提供了许多秘密的佐料，以使我们的产品与竞争对手的产品区分开来.

Having a weird database let us build a lot of our other weird technologies, giving us lots of secret-sauce to distinguish our product from those of our competitors.

主要缺点是我们没有使用标准的关系数据库技术，当您的客户是企业客户时，这可能是一个问题.我们的客户会问为什么我们不能仅将数据托管在其庞大的Oracle集群上(我们的客户通常拥有大型数据中心).团队之一实际上重写了数据库层以使用Oracle(或PostgreSQL，或MySQL)，但是它比原始数据库慢一些.至少有一个大型企业甚至拥有仅Oracle的策略，但是幸运的是Oracle收购了Berkeley DB.我们还必须编写许多其他工具-我们不能仅使用Crystal Reports.

The main disadvantage was that we weren't using the standard relational database technology, which can be a problem when your customers are enterprisey. Our customers would ask why we couldn't just host our data on their giant Oracle clusters (our customers usually had large datacenters). One of the team actually rewrote the database layer to use Oracle (or PostgreSQL, or MySQL), but it was slightly slower than the original. At least one large enterprise even had an Oracle-only policy, but luckily Oracle bought Berkeley DB. We also had to write a lot of extra tools - we couldn't just use Crystal Reports for example.

图数据库的另一个缺点是我们自己构建它，这意味着当我们遇到问题(通常具有可伸缩性)时，我们必须自己解决它.如果我们使用关系数据库，那么供应商早在十年前就已经解决了这个问题.

The other disadvantage of our graph database was that we built it ourselves, which meant when we hit a problem (usually with scalability) we had to solve it ourselves. If we'd used a relational database, the vendor would have already solved the problem ten years ago.

如果您要为企业客户构建产品，并且数据适合关系模型，请尽可能使用关系数据库.如果您的应用程序不适合关系模型，但是适合图形模型，请使用图形数据库.如果只适合其他用途，则使用它.

If you're building a product for enterprisey customers and your data fits into the relational model, use a relational database if you can. If your application doesn't fit the relational model but it does fit the graph model, use a graph database. If it only fits something else, use that.

如果您的应用程序不需要适合当前的blub架构，请使用图数据库，CouchDB，BigTable或任何适合您的应用程序的应用程序，您认为这很酷.它可能会给您带来优势，并且尝试新事物也很有趣.

If your application doesn't need to fit into the current blub architecture, use a graph database, or CouchDB, or BigTable, or whatever fits your app and you think is cool. It might give you an advantage, and its fun to try new things.

无论选择什么，除非您真的喜欢构建数据库引擎，否则请不要自己构建数据库引擎.

Whatever you chose, try not to build the database engine yourself unless you really like building database engines.

这篇关于基于图的数据库(http://neo4j.org/)的用例是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！