基于图形的数据库( http://neo4j.org/)有哪些用例？

我在以前的作业中使用了图形数据库。我们没有使用 neo4j，它是建立在 Berkeley DB 之上的一个内部的东西，但是它很类似。它曾经用于生产(现在仍然是)。

我们之所以使用图形数据库，是因为系统存储的数据和系统对数据的操作正是关系数据库的弱点，也正是图形数据库的强点。系统需要存储缺乏固定模式且通过关系链接在一起的对象集合。为了对数据进行推理，系统需要执行大量操作，这些操作需要在图形数据库中进行几次遍历，但在 SQL 中这将是相当复杂的查询。

该图模型的主要优点是开发速度快、灵活性强。我们可以在不影响现有部署的情况下快速添加新功能。如果一个潜在客户想要导入一些他们自己的数据并将其移植到我们的模型上，这通常可以由销售代表在现场完成。灵活性也有助于我们设计一个新功能，避免我们试图将新数据压缩到一个僵化的数据模型中。

拥有一个奇怪的数据库可以让我们构建很多其他奇怪的技术，给我们很多秘密武器来区分我们的产品和竞争对手的产品。

主要的缺点是我们没有使用标准的关系数据库技术，如果你的客户是企业级的，这可能是一个问题。我们的客户会问我们为什么不能把我们的数据放在他们巨大的 Oracle 集群上(我们的客户通常有大型的数据中心)。其中一个团队实际上重写了数据库层，使用 Oracle (或 PostgreSQL，或 MySQL) ，但是比原来的稍慢一些。至少有一家大型企业甚至有一个只针对 Oracle 的策略，但幸运的是 Oracle 收购了 Berkeley DB。我们还必须编写许多额外的工具——例如，我们不能仅仅使用 Crystal Reports。

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

如果你正在为企业客户开发一个产品，你的数据符合关系模型，尽可能使用关系数据库。如果你的应用程序不符合关系模型，但它符合图形模型，使用图形数据库。如果只适合别的东西，就用那个。

如果您的应用程序不需要适应当前的 blub 架构，可以使用图形数据库、 CouchDB 或 BigTable，或者任何适合您的应用程序并且您认为很酷的东西。这可能会给你一个优势，而且尝试新事物也很有趣。

不管您选择什么，尽量不要自己构建数据库引擎，除非您真的喜欢构建数据库引擎。

我已经使用 MySQL 管理工程数据很多年了，它工作得很好，但是我们有一个问题(但是没有意识到我们有)就是我们总是需要预先计划模式。我们知道的另一个问题是将数据映射到域对象并返回。

现在我们刚刚开始尝试新4j，看起来它为我们解决了这两个问题。为每个节点(和关系)添加不同属性的能力使我们能够重新思考整个数据处理方法。它就像动态语言对静态语言(Ruby 对 Java) ，但是对于数据库而言。在数据库中构建数据模型可以以更加敏捷和动态的方式完成，这极大地简化了我们的代码。

由于代码中的对象模型通常是一个图形结构，从数据库映射也更简单，代码更少，因此缺陷也更少。

另外，我们用于将数据加载到 neo4j 的初始原型代码实际上比以前的 MySQL 版本执行得更快。我还没有关于这个的确切数字，但是这是一个很好的附加特性。

但是最终，选择可能应该主要基于您的领域模型的性质。它是更好地映射到表格还是图表？通过做一些原型来决定，加载数据并使用它。使用 neoclipse 查看数据的不同视图。一旦你做到了这一点，希望你知道自己是不是在做一件好事。

我们已经和创生团队一起工作了一年多了，我们非常高兴。我们为学术工件及其关系建模，这对于一个图形数据库是正确的，并在网络上运行推荐算法。

如果您已经在 Java 中工作，我认为使用 Neo4j 进行建模是非常简单的，并且在我们尝试的任何其他解决方案中，它具有最平坦/最快的 R/W 性能。

老实说，我很难用图形/网络来思考 没有，因为它比设计复杂的表结构来保存对象属性和关系要容易得多。

也就是说，我们确实在 MySQL 中存储了一些信息，这仅仅是因为业务端更容易对其运行快速 SQL 查询。要在 Neo 上执行同样的功能，我们需要编写一些目前没有带宽的代码。只要我们做到了，我就把所有数据转移给尼欧！

祝你好运。

两点:

首先，根据我过去5年在 SQL Server 中使用的数据，我最近在 SQL 的可伸缩性方面遇到了瓶颈，因为我们需要运行的查询类型(嵌套关系... ... 你知道... ... 图表)。我一直在玩 neo4j，当我需要这种查找的时候，我的查找数量级快了好几倍。

第二，图形数据库已经过时了。没有。早期，当人们试图找出如何有效地存储和查找数据时，他们创建并使用图形和网络风格的数据库模型。它们的设计使物理模型反映了逻辑模型，因此它们的效率并不高。这种类型的数据结构适用于半结构化数据，但不适用于结构化密集数据。因此，这个名叫 Codd 的 IBM 家伙正在研究安排和存储结构化数据的有效方法，并提出了关系数据库模型的想法。这很好，大家都很开心。

这是什么？两种不同用途的工具。图形数据库模型非常适合表示半结构化数据和实体之间的关系(可能存在，也可能不存在)。关系数据库适用于具有非常静态模式的结构化数据，而且连接深度不会很深。一个适用于一类数据，另一个适用于其他类型的数据。

换句话说，根本就没有什么银弹。说图形数据库模型已经过时，用一个就放弃了40年的进步，这是非常短视的。这就像是说使用 C 放弃了我们已经经历过的所有技术进步来获得像 Java 和 C # 这样的东西。但这不是真的。C 是一个用于特定任务的工具。Java 是用于其他任务的工具。

这里有一篇很好的文章讨论了非关系数据库所满足的需求: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

它很好地指出了(除了名字)关系数据库没有缺陷或错误，只是这些天人们开始在主流软件和网站上处理越来越多的数据，而关系数据库不能满足这些需求。

可能有点晚了，但是使用 Neo4j 的项目越来越多，这是在 Neo4j上列出的较为知名的项目。此外，Neo4j 背后的公司 NeoTechnology 在 他们的客户页面也有一些参考资料

_{注意: 我是 Neo4j 团队的一员}

我正在我的公司建立一个内部网。

我感兴趣的是如何加载存储在表中的数据(Oracle、 MySQL、 SQL Server、 Excel、 Access、各种随机列表)并将其加载到 Neo4J 或其他图形数据库中。特别是，当公共数据与系统中已有的数据重叠时会发生什么情况。

是的，我知道有些数据在 RDBMS 是最好的建模方式，但是我有一个想法让我很兴奋，那就是当你需要叠加几个不同的表格时，图形模型比表格结构更好。

例如，我在一个生产环境中工作。我们正在做一个主要的项目，由于复杂性，每个部门都创建了一个单独的 Excel 电子表格，在左边的一列中有一个 材料清单层次结构，然后是由制作这些表格的个人制作的几列注释和检查。

因此，其中一个问题是将所有这些注释合并到一个“视图”中，以便有人可以看到需要在任何特定部分中解决的所有问题。

第二个问题是，当一个公共组件在多个子程序集中使用时，Excel 电子表格很难表示层次化 BOM。这意味着，如果有人写了一个关于点火组件的 P34继电器的注释，同样的注释应该与电机驱动器组件中使用的 P34继电器相关联。Excel 电子表格中不会出现这种情况。

对于公司内部网，我希望能够轻松地搜索任何东西。例如与零件编号、 BOM 结构、电话号码、电子邮件地址、公司政策或程序相关的数据。我甚至想扩展它来管理计算机硬件资产和安装的软件。

我设想，一旦信息网络开始填充，你可以开始做一些很酷的遍历，比如“我想写一封电子邮件给所有在 XYZ 项目工作的人”。人们将与该项目相关联，因为他们将被标记为在 XYZ 项目中创建和修改数据。因此，通过使用 XYZ 项目作为搜索关键字，将创建一个包含与 XYZ 项目相关的所有内容的巨大集合。包括构建 XYZ 项目的人员的链接。人员链接将连接到他们的电子邮件地址。因此，通过他们在 XYZ 项目的参与，他们将包括在我的电子邮件。这与一些秘书试图维持一份项目工作人员名单的做法形成鲜明对比。我们生成了很多列表。我们花了很多时间维护列表，并确保它们是最新的。而且大多数都不会给我们的产品增加任何价值。

另一个很酷的遍历可以按版本报告所有安装了特定软件的计算机。该报告可用于生成任务，以删除旧软件的额外副本，并更新需要最新副本的人员。它对于许可证跟踪也很有用。