Nebula Graph技术分享野谈———不得不说世界很棒。 这次能够参加Nebula Graph的技术共享，可能来自于前几天参加的“中国开源年会”上的接触，通过这次的技术共享，我的认知图像中也点亮了“图数据库”。 这篇文章主要总结了自己对图数据库的理解。
1. 什么是图数据库
首先来wiki看看what is the ‘图数据库’怎么样？ 图数据库：使用graph数据库图结构进行语义检索的数据库
中文维基百科可以看到，图数据库的介绍篇幅比其他技术小。 这也从侧面表明，这部分技术还处于发育期。
一般技术的发展可以分为婴儿期、发育期、成熟期和衰退期
传统数据库(包括Sql和其他NoSql )隐含地存储了数据之间的关系，图数据库清楚地显示了数据之间的关系，因此对高度互联的数据非常有用。
现有数据库基于数据模型，即定义数据输入和输出方法的模型。 简单地说，就是定义数据的格式。 该格式必须满足表达的需要(更直观、更简单的模拟现实世界)、计算机的实现需要和人们的理解需要。 需求的典型数据模型是层次模型、网格模型、关系模型和面向对象模型。 每个数据模型有三个要素。 与通常的数据结构相同。
结构数据操作数据约束-层次模型：有向树
网格模型：关系网络、结构复杂
– -关系模型：二维表结构、
– -面向对象模型：代码数据=对象，包含逻辑上的维护联系
网格模型的数据库和图的数据库有点像，他们都是图的结构的。 那么，有什么区别呢？ 一般来说，网格模型在较低级别的抽象上工作，整体结构复杂，因此难以遍历某节点数据的所有关系。 相比之下，图数据库可以方便快捷地检索出关系系统中难以建模的复杂层次结构。
说到这里，图数据库在数据库界的地位很明确。 不可否认那不是必须的。 同样的问题可以用传统的数据库解决。 虽然解决得不够。 图数据库作为传统数据库的辅助，可以更有效地应用于高度互联的数据。
在
2. 图数据库的应用
之前，我以为图表数据库是dydfh的孩子，但具体了解一下，它由来已久，很多大公司都在使用。 虽然不是独立自成一派，但起着不小的作用。 那么，图数据库用于哪些方面呢？ 其实，我们已经说了最重要的地方。 ——适用于高度互联的数据。
自然语言(自然语言检索、实体识别擦除dsdjr、知识地图大数据)社交网络预测)供应链风险预测、提案引擎、药物开发金融)在线银行、欺诈检测(深入了解发现、地图数据库的幸运的是，我不知道那个，也很了解，降低了学习成本。 我上了一个学期的探讨语义网的课，对这方面还有些了解。 如果有时间的话，我会专门写关于语义网的文章。 ）
现在，让我们从几个更高级的图数据库中详细看看。
A. Allegro Graph
https://Allegro图表.com /
技术点：语义图
Allegro Graph为开发复杂的语义图APP提供了一个全面的生态系统。 其开发团队是Franz Inc .基于全球基金会和行业标准化组织，提供了500多家大型解决方案，提供了高级数据查询，帮助企业从高度复杂的分布式数据库中进行复杂的决策和预测分析(常规数据库无法解决的问题，
大规模语义———— Hadoop Allegro图形
目标：处理TB级名称和数据，分析作者、联合作者、TB相关出版物、共享存储关系。
面临的问题：
任命不能消除dsdjr :不能发现变体、昵称、拼写错误、缩写半结构化数据TB级内容的传统名称一致#补充、数据量
1b (字节)=8位
1kb (千字节)=1024B，
1MB (兆字节简称为“兆字节”)=1024KB，
1GB (千兆字节别名“千兆”)=1024MB，
1TB(terabyte兆字节太字节)=1024GB，其中1024=2^10 (2) 2的10次方)、
1 Pb (1兆字节) 1兆字节拍字节)=1024TB，
1EB(exabyte百亿字节的exabyte )=1024PB、
1zb (zetta字节10兆字节的零字节)=1024 EB，
1yb (yotta字节1亿字节八尾字节)=1024 ZB、
1bb(brontobyte一千亿字节)=1024 YB
1nb (非字节)=1024BB
1db (谷歌字节)=1024NB
说实话，TB级的数据量不大。 这是
问题的难点不是数据量的问题，而是数据结构的问题
解决方案：
HadoopAllegro 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：continenttypecommentidint一般是自增的id，本应用中无意义country_idint国家id，外键namevarchar洲的名字
Table：countrytypecommentidint自增的id，表国家的idcapitalvarchar国家的首都namevarchar国家的名字
传统SQL是这样的
SELECT
country.capital
FROM
continent
JOIN
country
ON continent.country_id = country.id
WHERE
continent.name = ‘Afica’
(感觉原例子给出的表是有问题的：应该是洲表中，一个记录表示一个洲，然后再国家表中记录洲id，但这里为了下面的举例，我没有作改变，只是强行理解)
SPARQL：面向RDF(Resource Description Framework)的三元组数据，W3C标准，无schema，在研究中应用非常广泛。SPARQL的查询与RDF是一致的，RDF是图，SPARQL查询是子图匹配。
SPARQL是这样的
PREFIX ex: <http://example.com/exampleOntology#>
SELECT ?capital
?country
WHERE
{
?x ex:cityname ?capital ;
ex:isCapitalOf ?y .
?y ex:countryname ?country ;
ex:isInContinent ex:Africa .
}
Gremlin：数据以属性图的形式存在，可以认为是上面两种的混合体，属性仍然在表中，但是联接关系是直接以链接（比如指针）的形式存在的。查询的本质是图遍历，擅长解决求图的直径、点到点之间的路径，比如刘德华连接奥巴马需要几度关系。
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