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

问题描述

我经常使用关系数据库，并决定尝试使用其他可用的类型.

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屋！