作者：WilliamLyon译者：OneAPM
你会怎么选择数据库，是关系数据库、XML数据库、资源描述框架(RDF)，还是图形数据库?这篇演讲深入而生动地探讨了各种选择。
备注：在去年十月于旧金山举办的GraphConnect大会上，FactGem公司首席技术官ClarkRichey发表了这篇演讲，解释了他决定选择Neo4j数据的原因。
在这里我想说一说我们是怎么开始接触数据库技术的，然后我们做出了哪些改变，我们还需要做出哪些决定，哪些东西影响了我们的决策流程。我还会介绍我们调查研究过的各种数据库和技术，以及我们在使用Neo4j过程中发现的一些最佳做法和最差做法。
年夏天之后，很多事情都发生了变化，我也会对我们在这段时期测试的各种数据库做出一个仔细的评估。
选择数据库关系数据库
最初，我们的创始人准备把数千份不同的文件放在一起，用来执行有效搜索、制定业务决策、进行数据分析和创建数据可视化。
我们在研究过程中发现，关系数据库(RDBMS)并不适合我们。当然，我们的本能反应就是使用这种数据库，毕竟我们已经用了这么长时间。但关系数据库需要固定的架构，并且创建数据库时就要设置好这一固定架构。用户必须创建各种表，确定关系，然后创建JOIN连接：
而我们需要的是比关系模型更为灵活的数据库。
XML数据库
我曾经接触过NoSQL数据库。那时我在MarkLogic公司工作。MarkLogic是一家企业级模式自由型XML数据库公司，该公司还存储文档并提供JSON格式。这种数据库无论在上传信息还是执行搜索时，速度都较快，并且模式自由。
我们确实从这一初始概念点(POC)学到了一些东西，但顾名思义，概念点本身就是一种不够全面的看法。我们依次对这一看法的各个子集进行测试，然后选取部分样本集，发现能够进行快速搜索和导航。
我们认识到，文档之间的隐含信息比存储在每个文档内的信息要有意思得多。于是我们试着弄清楚能不能创建一个数据库好让我们利用这些关系。
我们再次将信息建模，形成文档，后者非常适合我们的数据集。但使用文档数据库时，用户真正关心的当然是文档了。因此，尽管我们可以进行JOIN连接，但仍然不适用于大型数据集。
我们可以在文档内进行快速搜索，但不能对文档之间的关系进行快速搜索。对于这项操作而言，这一数据库并不合适。
资源描述框架(RDF)/三元组存储为了解决问题，MarkLogic把我们的所有文档从XML迁移到资源描述框架(RDF)，这一框架又被称为三元组存储。这无疑是个大手笔，也是非常与众不同的对待数据的方式，我们决定，就是它了。
这不算太难，因为我们很小心地从架构的剩余部分解耦了持久层。最后花了大约两个月时间，然后我们终于能在不影响应用程序剩余部分的情况下进行迁移。
我们为什么选择资源描述框架?因为它是专为连接带有统一资源标识符的信息而设计的，还拥有一种叫做SPARQL的标准化查询语言。
简而言之，资源描述框架是有关主/谓/宾关系的，从下面看得出来，其模型非常简单：
下面是资源描述框架概念的简单象形图：
如果我想说Clark认识JohnForrest，那么Clark就是资源。资源具有名字、姓氏和类型等属性，也具有关系。下面这些资源描述框架的三元组可以体现这一示意图：
我们的数据库确实很给力，总体来说我们也相当满意。利用资源描述框架，我们不仅重建了整个概念点，还实现了对数据库的更多操作——包括探索各种关系。虽然在各个机构和行业之间进行大范围的数据分享时非常方便，但这并不是我们使用数据库的主要目的。
资源描述框架非常冗长，它是一种基于非属性的图形。由于所有内容都表现为节点，要想进行复杂的关系查询，必须先到达目的地然后再一同返回，这给我们带来了一些性能问题。虽然资源描述框架没有成为我们的最终选择，但它确实帮我们看清了专注于数据关系的希望。
作为一家小型初创公司，在这么短的时间里经历了这么多种数据库，我们有些担心。即使这样，我们仍然明白，从一开始就要选择合适的数据库是多么的重要，于是我们顶着重重压力，在没有做好充分的数据库工作的情况下，我们决定尝试图形数据库。
改变从这里开始：图形数据库最初我们认为图形数据库和资源描述框架一个样。但我们知道，要描述两个人之间的关系，用资源描述框架太复杂了。我们希望能有一个非常非常简单的工具，让我们能够给节点分配属性，然后我们在一个属性图形模型里找到了以下内容：
于是我们又明白了，我们不能使用关系数据库，因为它们在关系上的表现不够出色。JOIN连接、外键和索引既不真实，也不具体;它们只是我们画在纸上用来方便理解的图案。反过来说，在图形数据库中，关系被表达成具体实体。
TitanDB数据库我们先研究了TitanDB，它各项强大的功能和极佳的可扩展性一开始让我们非常振奋。可惜的是，TitanDB的启动和维护都非常复杂，必须得从Cassandra或HBase后台运行。
我们关心的另一个功能是最终一致存储，它并不符合ACID原理。这表示，如果我们要长时间运行大型图形数据库，最后可能会出现不一致现象。
TitanDB确实提供了一个基本可长期运行的流程，能够始终如一地穿行整个图形，以期探测和修复不一致问题。除了这些不一致之外，TitanDB还可以作为不基于图形的本地存储之上的层。
OrientDB数据库接下来我们又了解了OrientDB。OrientDB启动起来似乎简单得多，还具备大量针对文档的功能。但从社区的评论来看，性能和可扩展性是个问题。另外，OrientDB把自己宣传成多模式数据库——图形和SQL。这种宣传缺乏对纯图形操作的针对性，让我很是忧心，我们不仅想要做图形，还要做好图形。
发现Neo4j然后我们发现了Neo4j。Neo4j可高度扩展，对节点、关系或索引的数量没有限制。同时Neo4j入门也相当简单，这对我们是很大的诱惑;在使用第三个数据库时，必须得迅速投入运行。
性能表现极佳，扩增也非常广泛，并且只专注于图形用例。Titan确实提供映射(作为本地节点类型)支持，但我们知道，即使没有这一支持我们也可以继续下去。
总的来说，我们之所以选择Neo4j，有以下原因：
我们使用Neo4j企业版已有大约16个月，体验一直非常美好。Neo4j易于使用，设置和维护也很简单，实现甚至超出了我们的预期。它让我们超越了我们的概念点，非常非常迅速地投入运行和构建新事物。
在本文的第二部分，将详细介绍使用Neo4j之后，作者学习到的经验教训，敬请期待。
原文
End.
聚焦车联网时代｜解读车联网产业发展
中科白癜风医院治白癜风的中药方