图数据库查询语言Cypher、Gremlin和SPARQL

写在前面：第一部分仍然是心得和胡扯相关的内容，可以直接跳过。

维基上面是这么介绍图数据库的：

A graph database is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data.

这里有个关键词”semantic queries”，与之相对应的可能是形式语言（Formal Language）中只关心句法。最让人心碎的是：

As of 2016, no single graph query language has been universally adopted in the same way as SQL was for relational databases, and there are a wide variety of systems, most often tightly tied to one product. Some standardization efforts have occurred, leading to multi-vendor query languages like Gremlin, SPARQL, and Cypher. In addition to having query language interfaces, some graph databases are accessed through APIs.

我在这上面吃了大亏。问题的根本在于图数据库本身市场就不大而且还没有统一的查询标准，极度分裂。各自优化的目标可能不一样，一般的实现大多是聚集于自家的API，对于相对通用的Gremlin和SPARQL的支持可能只是有而已，功能支持少缺胳膊少腿，各种让人难受。

我既然能有机会在这里扯淡至少我个人是相信这一点肯定会有所改进的——文本信息抽取工具逐渐成熟和以维基百科为基础的知识库(Freebase/DBPedia等)的相继出现，会对存储及查询提出更多的要求，也会有更多的人投入到改善查询和存储效率上的。

1. SQL/Gremlin/Sparql简单对比

很多人会问一个问题是图查询能不能用SQL做，首先可以肯定这个是能做的，如果效率也非常高的话也就没有必要再多做探讨。用SQL查询是需要对表设计有一些要求的，同样的Gremlin和SPARQL两种查询标准都是对存储模式是有一定假设（或者要求）的。这篇文章只讨论查询模式上的差异，并且对每一种的查询给出相应的例子，学习学习基本的语法、做做对比即可。效率问题以及问题产生的根本需要还是再开一篇来讲好了，这篇文章还是将内容限定在对于同样的问题，数据应该如何存储与查询上。

1. SQL：数据以表形式存在，有比较强的schema定义，表间的数据关联以联接(join)的方式实现。这是一种事实标准，大部分人都想把其它问题也转换回SQL或类SQL的方式上来。
2. SPARQL：面向RDF(Resource Description Framework)的三元组数据，W3C标准，无schema，在研究中应用非常广泛。SPARQL的查询与RDF是一致的，RDF是图，SPARQL查询是子图匹配。
3. Gremlin：数据以属性图的形式存在，可以认为是上面两种的混合体，属性仍然在表中，但是联接关系是直接以链接（比如指针）的形式存在的。查询的本质是图遍历，擅长解决求图的直径、点到点之间的路径，比如刘德华连接奥巴马需要几度关系。

2. 分解示例

问题：非洲国家的首都有哪些？

2.1 SQL

首先设计两张表，洲和国家两张表。

TABLE: continent