Nebula Graph 技术分享野谈———不得不说，世界是很奇妙的。这次能有幸参加Nebula Graph的技术分享，大概是源自于在前一段时间参加的“中国开源年会”上的接触，借着这次技术分享，也在我的认知图谱里点亮了“图数据库”。这篇文章，主要是总结自己对图数据库理解的总结。
1. 什么是图数据库
我们先来wiki一下 what is the ‘图数据库’？
图数据库：Graph Database 一个使用图结构进行语义查询的数据库
可以看到，在中文维基百科上，关于图数据库的介绍篇幅，相比于其他技术，还是比较小的，这也从侧面说明，这部分技术还在发育期。
一般技术的发展，可以分为婴儿期、发育期、成熟期和衰退期
传统的数据库，包括Sql和其他NoSql对于数据之间的关系，是隐式存储的，图数据库则明确列出了数据间的关系，使其对于高度互连的数据非常有用。
现有的数据库都是基于某一种数据模型而建立起来的, 数据模型是定义数据如何输入和与输出的一种模型。简单来说，就是定义数据的格式。
这种格式要满足三方的需求：表达的需求（能直观、简便的模拟现实世界），计算机的实现需求，以及人们的理解需求。
需求典型的数据模型有：层次模型，网状模型、关系模型，面向对象模型。
每一种数据模型都有三要素（和普通的数据结构一样）：
- 层次模型：有向树 - 网状模型：关系网，结构复杂 - 关系模型：二维表结构，- 面向对象模型：代码+数据=对象，通过逻辑包含维护联系
可见，网状模型数据库和图数据库是有些类似的，他们都是图结构的。那么，它们有什么区别呢？
一般而言，网状模型是在较低层次抽象上运行，整体结构复杂，很难遍历得到某一节点数据的所有关系。
相对的，图数据库以简单快速地检索难以在关系系统中建模的复杂层次结构。
说到这里，我们大概清楚，图数据库在数据库界的定位了，不可否认，它不是必须的，同样的问题，可以通过传统的数据库解决，虽然解决的不够好。图数据库作为传统数据库的辅助，可以更高效地应用于高度互联的数据。
2. 图数据库的应用
在此之前，我以为，图数据库是一个新生儿，但是具体了解后，才发现，它由来已久，而且很多大公司都会用的到，虽然没有独立到自成一派，但也起着不小的作用。那么图数据库到底应用在哪些方面呢？其实上面我们已经说了最关键的地方了——它适用于高度互联的数据。
深入了解发现，图数据库的应用还紧密联系了另一个领域——语义网。所幸，我对它不陌生甚至还很熟悉，又减少了我的学习成本。（我曾经上了一学期研讨语义网的课程，对此方面还是有一定的了解，有时间会专门写一篇关于语义网的文章。）
下面，我们通过几款较为完善的图数据库进行深入了解。
A. Allegro Graph
https://allegrograph.com/
技术点：语义+图
Allegro Graph为开发复杂的语义图应用程序提供了一个全面的生态系统。它的开发团队是Franz Inc.，基于全球财团和行业标准组织，供给很多500强的大公司解决方案，提供高级数据查询，使企业能从高度复杂的分布式数据库中提取复杂的决策见解和预测分析（常规数据库无法解决的问题）。
大规模语义———— Hadoop + AllegroGraph
目标：处理TB级别的名称和数据，解析作者、共同作者、TB相关出版物以及共享的存储关系。
遇到的问题：
无法消除任命歧义：变体、昵称、拼写错误、缩写
半结构化数据
TB级内容
传统名称匹配无法发现
#补充，数据量1B（Byte字节）=8bit1KB (Kilobyte 千字节)=1024B，1MB (Mega byte 兆字节 简称“兆”)=1024KB，1GB (Giga byte 吉字节 又称“千兆”)=1024MB，1TB (Tera byte 万亿字节 太字节)=1024GB，其中1024=2^10 ( 2 的10次方)，1PB（Peta byte 千万亿字节 拍字节）=1024TB，1EB（Exa byte 百亿亿字节 艾字节）=1024PB，1ZB (Zetta byte 十万亿亿字节 泽字节)= 1024 EB,1YB (Yotta byte 一亿亿亿字节 尧字节)= 1024 ZB,1BB (Bronto byte 一千亿亿亿字节)= 1024 YB1NB(Nona byte )= 1024BB1DB(Dogga byte)= 1024NB说实话，TB级的数据量并不大，这个问题的难点不是数据量的问题，而是数据结构的问题
解决方案：
| Hadoop | Allegro Graph |
|---|
| 大型数据集处理 | RDF、三重存储和本体平台 |
| 半结构化数据处理 | 解析不明确的名称、缩写 |
| 数据存储和处理的经济可扩展性 | 识别隶属关系 |
| Map-Reduce框架 | 基于阈值的人际关系匹配 |
| 创建语义三元组 | 分析联系性、人群和中心性 |
Mahout机器学习平台：
从大型XML字段中提取元数据块、
机器学习领域信息、
输入流式传输到Hadoop文件系统（HDFS）、
Map-Reduce框架 |
|
B. Amazon Neptune
Amazon Neptun是亚马逊的图数据库，应用于亚马逊云计算。 下表是Amazon的数据库服务：
| 数据库类型 | 使用案例 | AWS服务 |
|---|
| 关系 | 传统应用程序、ERP、CRM、电子商务 | Amazon Aurora、Amazon RDS、Amazon Redshift |
| 键值 | 高流量web应用、电子商务系统、游戏应用程序 | Amazon DynamoDB |
| 内存 | 缓存、会话管理、游戏排行榜、地理空间应用程序 | Amazon ElastiCache for Memcached/Redis |
| 文档 | 内容管理、目录、用户配置文件 | Amazon DocumentDB |
| 宽列 | 用于设备维护、队列管理和路线优化的大规模工业应用程序 | Amazon Managed Apache Cassandra Service |
| 图形 | 欺诈检测、社交网络、建议引擎 | Amazon Neptune |
| 时间序列 | Iot应用、开发运营和工业遥测 | Amazon Timestream |
| 分类账 | 系统记录、供应链、注册、银行事务 | Amazon QLDB |
从这里可以大致窥探出图数据库的定位和地位。Amazon的服务是商业化的，也是较为稳定的，它有高性能、高可扩展、高可用性和持久性等等，最重要的，还是安全性。（毕竟是amazon，要可靠稳定很多）
传统数据库一样，neptune支持了传统数据库服务的基本功能：
然后又有其本身的特性：
高性能：高吞吐量、低延迟
支持Gremlin或SPARQL执行强效查询
（感觉还是有些单薄）
3. 查询语言
SQL/Gremlin/Sparql/RDF/Neo4j/Cypher/MonoDB/ElasticSearch
在查询语言方面，传统数据库有统一的SQL，但是图数据库在这方面，极度分裂，颇有五代十国的气势，然后作为平民老百姓的我们身如浮萍。
我们举一个例子来说明（明确地说，这里我是copy大佬的博文，然后我发现那篇博文也是copy的，然后我没有找到原版在哪儿~~~为原创默哀1秒钟）
问题：非洲国家的首都有哪些？
建两张表，一张表记录国家和洲；另一张表记录国家的具体情况
| Table：continent | type | comment |
|---|
| id | int | 一般是自增的id，本应用中无意义 |
| country_id | int | 国家id，外键 |
| name | varchar | 洲的名字 |
| Table：country | type | comment |
|---|
| id | int | 自增的id，表国家的id |
| capital | varchar | 国家的首都 |
| name | varchar | 国家的名字 |
传统SQL是这样的
SELECTcountry.capitalFROMcontinentJOINcountryONcontinent.country_id=country.idWHEREcontinent.name='Afica'
(感觉原例子给出的表是有问题的：应该是洲表中，一个记录表示一个洲，然后再国家表中记录洲id，但这里为了下面的举例，我没有作改变，只是强行理解)
SPARQL是这样的
PREFIXex:<http://example.com/exampleOntology#>SELECT?capital?countryWHERE{?xex:cityname?capital;ex:isCapitalOf?y.?yex:countryname?country;ex:isInContinentex:Africa.}
Gremlin是这样的
g.--graph start , always!!V().has('continent','name','Afica')--The continent node，which name is Africa.out('capital')--Instead of an id foreign key, it just added a capital edge.values('name')--take the name of the country node
参考链接
1.维基百科：图数据库
2.跨越鸿沟——图数据库查询语言的八个先决条件
3.Amazon Neptune
4.Allegro Graph
