Kha*_*oth 127 database neo4j graph-databases
我经常使用Relational DB,并决定冒险使用其他类型的.
这个特别的产品看起来很好,很有希望:http://neo4j.org/
有没有人使用基于图形的数据库？可用性的优点和缺点是什么？
您是否在生产环境中使用过这些产品？提示您使用它们的要求是什么？
Wil*_*ris 183
我在之前的工作中使用了图形数据库.我们没有使用neo4j,它是一个建立在Berkeley DB之上的内部事物,但它是相似的.它被用于生产(它仍然是).
我们使用图形数据库的原因是系统存储的数据和系统对数据执行的操作正是关系数据库的弱点,而且恰好是图数据库的强点.系统需要存储缺少固定模式并通过关系链接在一起的对象集合.为了推断数据,系统需要进行大量的操作,这些操作可能是图形数据库中的几个遍历,但这在SQL中是非常复杂的查询.
图模型的主要优点是快速的开发时间和灵活性.我们可以快速添加新功能,而不会影响现有部署.如果潜在客户想要导入他们自己的一些数据并将其移植到我们的模型之上,那么通常可以由销售代表在现场完成.当我们设计新功能时,灵活性也有所帮助,使我们无法将新数据压缩到严格的数据模型中.
拥有一个奇怪的数据库让我们构建了许多其他奇怪的技术,为我们提供了许多秘诀,以区分我们的产品和竞争对手的产品.
主要的缺点是我们没有使用标准的关系数据库技术,当您的客户是企业时,这可能是一个问题.我们的客户会问为什么我们不能只在他们庞大的Oracle集群上托管我们的数据(我们的客户通常拥有大型数据中心).其中一个团队实际上重写了数据库层以使用Oracle(或PostgreSQL,或MySQL),但它比原来稍慢.至少有一家大型企业甚至有一个仅限Oracle的政策,但幸运的是Oracle收购了Berkeley DB.我们还必须编写许多额外的工具 - 例如,我们不能只使用Crystal Reports.
我们的图形数据库的另一个缺点是我们自己构建它,这意味着当我们遇到问题(通常具有可伸缩性)时,我们必须自己解决它.如果我们使用关系数据库,那么供应商十年前就已经解决了这个问题.
如果您正在为企业客户构建产品并且您的数据适合关系模型,请尽可能使用关系数据库.如果您的应用程序不适合关系模型,但它确实适合图形模型,请使用图形数据库.如果它只适合其他东西,请使用它.
如果您的应用程序不需要适应当前的blub架构,请使用图形数据库,CouchDB或BigTable,或任何适合您的应用程序,您认为很酷.它可能会给你一个优势,也有尝试新事物的乐趣.
无论你选择什么,尽量不要自己构建数据库引擎,除非你真的喜欢构建数据库引擎.
Dat*_*iot 32
我们已经与Neo团队合作了一年多,并且非常开心.我们模拟学术工件及其关系,这是图表数据库的点,并通过网络运行推荐算法.
如果您已经在使用Java,我认为使用Neo4j进行建模非常简单,并且对于我们尝试的任何其他解决方案的R/W,它具有最平坦/最快的性能.
说实话,我很难不考虑图形/网络,因为它比设计复杂的表结构来保存对象属性和关系要容易得多.
话虽这么说,我们确实在MySQL中存储了一些信息,因为业务方面更容易运行快速SQL查询.要使用Neo执行相同的功能,我们需要编写我们现在根本没有带宽的代码.但是,一旦我们这样做,我就把所有数据都移到了Neo!
祝好运.
Tur*_*rbo 23
两点:
首先,关于我在SQL Server中过去5年一直在使用的数据,我最近使用SQL来获取我们需要运行的查询类型的可伸缩性墙(嵌套关系...你知道...图).我一直在玩neo4j,当我需要这种查找时,我的查找时间要快几个数量级.
其次,图表数据库已经过时了.不.早期,当人们试图找出如何有效地存储和查找数据时,他们创建并使用图形和网络风格的数据库模型.这些设计是为了使物理模型反映出逻辑模型,因此它们的效率并不高.这种类型的数据结构适用于半结构化数据,但对结构化密集数据不太好.因此,这位名叫Codd的IBM老兄正在研究安排和存储结构化数据的有效方法,并提出了关系数据库模型的想法.这很好,人们很开心.
我们有什么在这里？两种工具用于两种不同的目的.图数据库模型非常适合表示半结构化数据和实体之间的关系(可能存在也可能不存在).关系数据库适用于具有非常静态模式的结构化数据,并且连接深度不会很深.一种适用于一种数据,另一种适用于其他类型的数据.
为了说明这句话,没有银弹.很容易看出图形数据库模型已经过时并使用它会放弃40年的进展.这就像说使用C放弃了我们所经历的所有技术进步,以获得Java和C#等内容.但事实并非如此.C是某些任务所需的工具.Java是其他任务的工具.
Cra*_*ner 15
我多年来一直使用MySQL来管理工程数据,并且运行良好,但我们遇到的一个问题(但我们没有意识到)是我们总是必须预先规划架构.我们知道的另一个问题是将数据映射到域对象并返回.
现在我们刚开始尝试neo4j,看起来它正在为我们解决这两个问题.为每个节点(和关系)添加不同属性的能力使我们能够重新思考我们的整个数据方法.它就像动态语言与静态语言(Ruby与Java),但对于数据库而言.在数据库中构建数据模型可以以更加灵活和动态的方式完成,这大大简化了我们的代码.
由于代码中的对象模型通常是图形结构,因此从数据库映射也更简单,代码更少,因此错误更少.
作为额外的奖励,我们用于将数据加载到neo4j的初始原型代码实际上比以前的MySQL版本执行得更快.我(还)没有固定的数字,但这是一个很好的附加功能.
但在一天结束时,选择可能应该主要基于域模型的性质.它是否更好地映射到表格或图形？通过做一些原型决定,加载数据并使用它.使用neoclipse查看数据的不同视图.一旦你做完了,希望你知道你是否做了好事.
小智 5
这里有一篇很好的文章，讨论了非关系数据库满足的需求：http : //www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
它很好地指出（除了名称之外）关系数据库没有缺陷或错误，只是现在人们开始在主流软件和网站中处理越来越多的数据，而关系数据库只是无法扩展对于这些需求。