目录
一、关系型数据库(Relational Database)
当我们准备把数千份不同的文件放在一起，用来执行有效搜索、制定业务决策、进行数据分析和创建数据可视化的时候，肯定会用到数据库。
在众多不同的数据模型里，关系数据模型自20世纪80年代就处于统治地位，而且出现了不少巨头，如Oracle、MySQL，它们也被称为：关系数据库管理系统（RDBMS）。
然而，随着关系数据库使用范围的不断扩大，也暴露出一些它始终无法解决问题，其中最主要的是数据建模中的一些缺陷和问题，以及在大数据量和多服务器之上进行水平伸缩的限制。同时，互联网发展也产生了一些新的趋势变化： 用户、系统和传感器产生的数据量呈指数增长，数据量不断增加，大数据的存储和处理；
新时代互联网形势下的问题急迫性，这一问题因互联网+、社交网络，智能推荐等的大规模兴起和繁荣而变得越加紧迫。
在研究过程中发现，关系数据库 (RDB) 并不适合我们。当然，我们的本能反应就是使用这种数据库，毕竟我们已经用了这么长时间。但关系数据库需要固定的架构，并且创建数据库时就要设置好这一固定架构。用户必须创建各种表，确定关系，然后创建 JOIN 连接。此时，我们需要的是比关系模型更为灵活的数据库。
二、非关系型数据库（NoSQL）
而在应对这些趋势时，关系数据库产生了更多的不适应性，从而导致大量解决这些问题中某些特定方面的不同技术出现，它们可以与现有RDBMS相互配合或代替它们。过去的几年间，出现了大量新型数据库，它们被统称为非关系型数据库(NoSQL)，NoSQL = Not Only SQL，意即“不仅仅是SQL”。
NoSQL 是一类范围非常广泛的持久化解决方案，它们不遵循关系数据库模型，也不使用SQL作为查询语言。其数据存储可以不需要固定的表格模式，也经常会避免使用SQL的JOIN操作，一般有水平可扩展的特征。
简言之，NoSQL数据库可以按照它们的数据模型分成4类：
- 键-值存储库（Key-Value-stores）;
- BigTable实现（BigTable-implementations）;
- 文档库（Document-stores）;
- 图形数据库（Graph Database）;
三、XML 数据库
我曾经接触过 NoSQL 数据库。那时我在 MarkLogic 公司工作。MarkLogic 是一家企业级模式自由型 XML 数据库公司，该公司还存储文档并提供 JSON 格式。这种数据库无论在上传信息还是执行搜索时，速度都较快，并且模式自由。
我们确实从这一初始概念点(POC)学到了一些东西，但顾名思义，概念点本身就是一种不够全面的看法。我们依次对这一看法的各个子集进行测试，然后选取部分样本集，发现能够进行快速搜索和导航。我们认识到，文档之间的隐含信息比存储在每个文档内的信息要有意思得多。于是我们试着弄清楚能不能创建一个数据库好让我们利用这些关系。我们再次将信息建模，形成文档，后者非常适合我们的数据集。但使用文档数据库时，用户真正关心的当然是文档了。因此，尽管我们可以进行 JOIN 连接，但仍然不适用于大型数据集。我们可以在文档内进行快速搜索，但不能对文档之间的关系进行快速搜索。对于这项操作而言，这一数据库并不合适。
四、资源描述框架 (RDF) / 三元组存储
为了解决问题，MarkLogic 把我们的所有文档从 XML 迁移到资源描述框架 (RDF)，这一框架又被称为三元组存储。这无疑是个大手笔，也是非常与众不同的对待数据的方式，我们决定，就是它了。
这不算太难，因为我们很小心地从架构的剩余部分解耦了持久层。最后花了大约两个月时间，然后我们终于能在不影响应用程序剩余部分的情况下进行迁移。我们为什么选择资源描述框架？因为它是专为连接带有统一资源标识符的信息而设计的，还拥有一种叫做 SPARQL 的标准化查询语言。
简而言之，资源描述框架是有关主/谓/宾关系的，从下面看得出来，其模型非常简单：
下面是资源描述框架概念的简单象形图：
如果我想说 Clark 认识 John Forrest，那么 Clark 就是资源。资源具有名字、姓氏和类型等属性，也具有关系。下面这些资源描述框架的三元组可以体现这一示意图：
我们的数据库确实很给力，总体来说我们也相当满意。利用资源描述框架，我们不仅重建了整个概念点，还实现了对数据库的更多操作 —— 包括探索各种关系。虽然在各个机构和行业之间进行大范围的数据分享时非常方便，但这并不是我们使用数据库的主要目的。
资源描述框架非常冗长，它是一种基于非属性的图形。由于所有内容都表现为节点，要想进行复杂的关系查询，必须先到达目的地然后再一同返回，这给我们带来了一些性能问题。虽然资源描述框架没有成为我们的最终选择，但它确实帮我们看清了专注于数据关系的希望。
作为一家小型初创公司，在这么短的时间里经历了这么多种数据库，我们有些担心。即使这样，我们仍然明白，从一开始就要选择合适的数据库是多么的重要，于是我们顶着重重压力，在没有做好充分的数据库工作的情况下，我们决定尝试图形数据库。
五、图形数据库（Graph Database）
定义：图形数据库是NoSQL数据库的一种类型，它应用图形理论存储实体之间的关系信息。图形数据库是一种非关系型数据库，它应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期，而图形数据库的独特设计恰恰弥补了这个缺陷。
我们不能使用关系数据库，因为它们在关系上的表现不够出色。JOIN 连接、外键和索引既不真实，也不具体；它们只是我们画在纸上用来方便理解的图案。反过来说，在图形数据库中，关系被表达成具体实体。
5.1 TitanDB 数据库
我们先研究了 TitanDB，它各项强大的功能和极佳的可扩展性一开始让我们非常振奋。可惜的是，TitanDB 的启动和维护都非常复杂，必须得从 Cassandra 或 HBase 后台运行。
我们关心的另一个功能是最终一致存储，它并不符合 ACID 原理。这表示，如果我们要长时间运行大型图形数据库，最后可能会出现不一致现象。
TitanDB 确实提供了一个基本可长期运行的流程，能够始终如一地穿行整个图形，以期探测和修复不一致问题。除了这些不一致之外，TitanDB 还可以作为不基于图形的本地存储之上的层。
5.2 OrientDB 数据库
接下来我们又了解了 OrientDB。OrientDB 启动起来似乎简单得多，还具备大量针对文档的功能。但从社区的评论来看，性能和可扩展性是个问题。另外，OrientDB 把自己宣传成多模式数据库 ——图形和 SQL。这种宣传缺乏对纯图形操作的针对性，让我很是忧心，我们不仅想要做图形，还要做好图形。
5.3 Neo4j 数据库
然后我们发现了 Neo4j。Neo4j 可高度扩展，对节点、关系或索引的数量没有限制。同时 Neo4j 入门也相当简单，这对我们是很大的诱惑；在使用第三个数据库时，必须得迅速投入运行。
性能表现极佳，扩增也非常广泛，并且只专注于图形用例。Titan 确实提供映射（作为本地节点类型）支持，但我们知道，即使没有这一支持我们也可以继续下去。
总的来说，我们之所以选择 Neo4j，有以下原因：
在面对社交型关系存储的时候，数据之间的关系会变得十分复杂。举个例子，新浪微博一个大V少则十几万，多则几千万的粉丝，这些关注关系要怎么存呢？在MySql中，一条关注关系（大V id，大V的一个粉丝 id）存为一条数据，那么当用户数量上来的时候，关注关系轻松破亿，破十亿，甚至上百亿，并且为了保证每条数据的唯一性，还需要设置联合索引，MySql就有些力不从心了。那么有人要说了：分表呀。嗯，没错，分表的确可以在插入端和读取端提升一些速度。比如我们可以根据id哈希到100张表中。查询一个用户有哪些粉丝是快了，但是查询一个用户关注了哪些人时仍然需要遍历全表。好，这时候我们还可以以（id，其关注的一个用户的id）再构造100张表，于是两种查询都快了。然而，后面那100张表是冗余数据，并且生成一张子图也不方便（需要多次写SQL查表）。
于是，在搜索更好的方案时，发现了图形数据库是个不错的选择，毕竟业界已经有很多应用了，如twitter，Adobe等。
先简要介绍一下Neo4j。Neo4j是由Java和Scala写成的一个NoSql数据库，专门用于网络图的存储。更详细的内容可见官网。作为一个图形数据库，Neo4j有以下优点：
- 更快的数据库操作。当然，有一个前提条件，那就是数据量较大，在MySql中存储的话需要许多表，并且表之间联系较多（即有不少的操作需要join表）。
- 数据更直观，相应的SQL语句也更好写（Neo4j使用Cypher语言，与传统SQL有很大不同）。
- 更灵活。不管有什么新的数据需要存储，都是一律的节点和边，只需要考虑节点属性和边属性。而MySql中即意味着新的表，还要考虑和其他表的关系。
- 数据库操作的速度并不会随着数据库的增大有明显的降低。这得益于Neo4j特殊的数据存储结构和专门优化的图算法。
两大明显的优势：
1、数据存储
Neo4j对于图的存储自然是经过特别优化的。不像传统数据库的一条记录一条数据的存储方式，Neo4j的存储方式是：节点的类别，属性，边的类别，属性等都是分开存储的，这将大大有助于提高图形数据库的性能。
2、数据读写
在Neo4j中，存储节点时使用了"index-free adjacency"，即每个节点都有指向其邻居节点的指针，可以让我们在O(1)的时间内找到邻居节点。另外，按照官方的说法，在Neo4j中边是最重要的,是"first-class entities"，所以单独存储，这有利于在图遍历的时候提高速度，也可以很方便地以任何方向进行遍历。
未完待续。。。
【参考文献】
[1] From Good to Graph: Choosing the Right Database
[3] 是时候放弃关系型数据库了