我使用了很多关系数据库,并决定冒险尝试其他可用的类型。
这个特殊的产品看起来不错而且很有前途: http: //neo4j.org/
有人用过基于图的数据库吗?可用性方面的优缺点是什么?
你在生产环境中使用过这些吗?促使您使用它们的要求是什么?
我使用了很多关系数据库,并决定冒险尝试其他可用的类型。
这个特殊的产品看起来不错而且很有前途: http: //neo4j.org/
有人用过基于图的数据库吗?可用性方面的优缺点是什么?
你在生产环境中使用过这些吗?促使您使用它们的要求是什么?
我在以前的工作中使用了图形数据库。我们没有使用 neo4j,它是建立在 Berkeley DB 之上的内部产品,但它是相似的。它被用于生产(现在仍然如此)。
我们之所以使用图数据库,是因为系统存储的数据以及系统对数据所做的操作,正是关系型数据库的弱点,也正是图型数据库的强项。系统需要存储缺乏固定模式并通过关系链接在一起的对象集合。为了对数据进行推理,系统需要执行大量操作,这些操作将是图数据库中的几次遍历,但这将是 SQL 中相当复杂的查询。
图模型的主要优点是快速的开发时间和灵活性。我们可以在不影响现有部署的情况下快速添加新功能。如果潜在客户想要导入他们自己的一些数据并将其移植到我们的模型之上,通常可以由销售代表在现场完成。当我们设计新功能时,灵活性也有所帮助,使我们免于尝试将新数据压缩到僵化的数据模型中。
拥有一个奇怪的数据库让我们可以构建许多其他奇怪的技术,为我们提供许多秘密调味料,以将我们的产品与竞争对手的产品区分开来。
主要缺点是我们没有使用标准的关系数据库技术,当您的客户是企业时,这可能是一个问题。我们的客户会问为什么我们不能只在他们的巨型 Oracle 集群上托管我们的数据(我们的客户通常拥有大型数据中心)。其中一个团队实际上重写了数据库层以使用 Oracle(或 PostgreSQL,或 MySQL),但它比原来的速度稍慢。至少有一家大型企业甚至制定了仅甲骨文的政策,但幸运的是甲骨文收购了 Berkeley DB。我们还必须编写很多额外的工具——例如,我们不能只使用 Crystal Reports。
我们的图形数据库的另一个缺点是我们自己构建了它,这意味着当我们遇到问题(通常是可伸缩性)时,我们必须自己解决它。如果我们使用关系数据库,供应商在十年前就已经解决了这个问题。
如果您正在为企业客户构建产品并且您的数据适合关系模型,请尽可能使用关系数据库。如果您的应用程序不适合关系模型,但适合图形模型,请使用图形数据库。如果它只适合其他东西,请使用它。
如果您的应用程序不需要适应当前的 blub 架构,请使用图形数据库、CouchDB 或 BigTable,或者任何适合您的应用程序并且您认为很酷的东西。它可能会给您带来优势,并且尝试新事物很有趣。
无论您选择什么,都尽量不要自己构建数据库引擎,除非您真的喜欢构建数据库引擎。
我们已经与 Neo 团队合作了一年多,并且非常高兴。我们对学术工件及其关系进行建模,这对于图形数据库来说是很重要的,并在网络上运行推荐算法。
如果您已经在使用 Java,我认为使用 Neo4j 进行建模非常简单,并且在我们尝试过的任何其他解决方案中,它具有最平坦/最快的 R/W 性能。
老实说,我很难不考虑图形/网络,因为它比设计复杂的表结构来保存对象属性和关系要容易得多。
话虽如此,我们确实在 MySQL 中存储了一些信息,只是因为业务方面更容易对其运行快速 SQL 查询。要使用 Neo 执行相同的功能,我们需要编写我们现在根本没有带宽的代码。不过,一旦我们这样做了,我就会将所有这些数据转移到 Neo 上!
祝你好运。
两点:
首先,关于我过去 5 年在 SQL Server 中处理的数据,我最近在 SQL 中遇到了我们需要运行的查询类型的可伸缩性墙(嵌套关系...你知道...图表)。我一直在玩 neo4j,当我需要这种查找时,我的查找时间要快几个数量级。
其次,图数据库已经过时了。不。早期,当人们试图弄清楚如何有效地存储和查找数据时,他们创建并使用了图形和网络风格的数据库模型。这些都是为了物理模型反映逻辑模型而设计的,所以它们的效率并没有那么高。这种类型的数据结构适用于半结构化数据,但不适用于结构化密集数据。因此,这个名叫 Codd 的 IBM 家伙正在研究安排和存储结构化数据的有效方法,并提出了关系数据库模型的想法。这很好,人们很高兴。
我们有什么在这里?两种工具用于两种不同的目的。图数据库模型非常适合表示半结构化数据和实体之间的关系(可能存在也可能不存在)。关系数据库适用于具有非常静态模式的结构化数据,并且连接深度不会很深。一种适用于一种数据,另一种适用于其他类型的数据。
为了创造这句话,没有银弹。说图数据库模型已经过时并且使用一个放弃了 40 年的进步是非常短视的。这就像说使用 C 放弃了我们为获得 Java 和 C# 之类的东西而经历的所有技术进步。但这不是真的。C 是某些任务所需的工具。Java 是用于其他任务的工具。
多年来我一直在使用 MySQL 来管理工程数据,它运行良好,但我们遇到的问题之一(但没有意识到我们遇到的问题)是我们总是必须预先规划架构。我们知道我们遇到的另一个问题是将数据映射到域对象并返回。
现在我们刚刚开始尝试 neo4j,看起来它为我们解决了这两个问题。为每个节点(和关系)添加不同属性的能力使我们能够重新思考我们处理数据的整个方法。它就像动态语言与静态语言(Ruby 与 Java),但针对的是数据库。在数据库中构建数据模型可以以更加灵活和动态的方式完成,这极大地简化了我们的代码。
而且由于代码中的对象模型通常是图结构,从数据库映射也更简单,代码更少,因此错误更少。
作为额外的奖励,我们用于将数据加载到 neo4j 的初始原型代码实际上比以前的 MySQL 版本执行得更快。我对此(还)没有可靠的数字,但这是一个很好的附加功能。
但归根结底,选择可能应该主要基于您的域模型的性质。它是否更好地映射到表格或图表?决定做一些原型,加载数据并使用它。使用 neoclipse 查看数据的不同视图。一旦你这样做了,希望你知道你是否在做一件好事。
这是一篇很好的文章,讨论了非关系数据库满足的需求:http ://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
它很好地指出(除了名称)关系数据库没有缺陷或错误,只是现在人们开始在主流软件和网站中处理越来越多的数据,而关系数据库只是不会扩展对于这些需求。
我正在我的公司建立一个内部网。
我有兴趣了解如何加载存储在表(Oracle、MySQL、SQL Server、Excel、Access、各种随机列表)中的数据并将其加载到 Neo4J 或其他一些图形数据库中。具体来说,当公共数据与系统中已有的数据重叠时会发生什么。
是的,我知道在 RDBMS 中最好对某些数据进行建模,但是我有一个想法让我很痒,当您需要叠加几个不同的表时,图模型比表结构更好。
例如,我在制造环境中工作。我们正在进行一个重大项目,由于其复杂性,每个部门都创建了一个单独的 Excel 电子表格,该电子表格在左侧的一列中有一个BOM(材料清单)层次结构,然后是几列由个人进行的注释和检查谁制作了这些床单。
所以问题之一是将所有这些注释合并到一个“视图”中,以便有人可以看到任何特定部分需要解决的所有问题。
第二个问题是,当一个通用组件用于多个子装配时,Excel 电子表格在表示分层 BOM 时很糟糕。这意味着,如果有人在点火子组件中写了关于 P34 继电器的注释,那么相同的注释应该与电机驱动器子组件中使用的 P34 继电器相关联。这不会发生在 Excel 电子表格中。
对于公司内部网,我希望能够轻松搜索任何内容。例如与零件编号、BOM 结构、电话号码、电子邮件地址、公司政策或程序相关的数据。我什至想扩展它来管理计算机硬件资产和安装的软件。
我设想,一旦信息网络开始填充,您就可以开始进行很酷的遍历,例如“我想给从事 XYZ 项目的每个人写一封电子邮件”。人们将与该项目相关联,因为他们将被标记为在 XYZ 项目中创建和修改数据。因此,通过使用 XYZ 项目作为搜索键,将创建一个包含与 XYZ 项目相关的所有内容的巨大集合。包括指向构建 XYZ 项目的人员的链接。人员链接将连接到他们的电子邮件地址。因此,通过他们参与 XYZ 项目,他们将包含在我的电子邮件中。这与一些试图维护参与该项目的人员名单的秘书形成鲜明对比。我们生成了很多列表。我们花费大量时间维护列表并确保它们是最新的。
另一个很酷的遍历可以按版本报告所有安装了某个软件的计算机。该报告可用于生成任务以删除旧软件的额外副本并更新需要最新副本的人。它对于许可证跟踪也很有用。
可能有点晚了,但是使用 Neo4j 的项目越来越多,在Neo4j中列出的更广为人知的项目。Neo4j 背后的公司 NeoTechnology 在其客户页面上也有一些参考资料
注意:我是 Neo4j 团队的一员