社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
随着社交、电商、金融、零售、物联网等行业的快速发展，现实社会织起了了一张庞大而复杂的关系网，传统数据库很难处理关系运算。大数据行业需要处理的数据之间的关系随数据量呈几何级数增长，亟需一种支持海量复杂数据关系运算的数据库，
图数据库应运而生。
世界上很多著名的公司都在使用图数据库。比如：
既然图数据库应用这么广泛，越来越多的企业和开发者开始使用它，那它究竟什么过人之处呢，下面我们来揭开它的神秘面纱。
学过数据结构这么课程的同学脑海中应该或多或少有图的概念。
图由两个元素组成：节点 Vertices和关系(边) Edge。
每个节点代表一个实体（人，地，事物，类别或其他数据），每个关系代表两个节点的关联方式。这种通用结构可以对各种场景进行建模 - 从道路系统到设备网络，到人口的病史或由关系定义的任何其他事物。
图数据库(Graph database)并非指存储图片的数据库，而是以图这种数据结构存储和查询数据。
图形数据库是一种在线数据库管理系统，具有处理图形数据模型的创建，读取，更新和删除（CRUD）操作。
与其他数据库不同，关系在图数据库中占首要地位。这意味着应用程序不必使用外键或带外处理（如MapReduce）来推断数据连接。
与关系数据库或其他NoSQL数据库相比，图数据库的数据模型也更加简单，更具表现力。
图形数据库是为与事务（OLTP）系统一起使用而构建的，并且在设计时考虑了事务完整性和操作可用性。
根据存储和处理模型不同，市面上图数据库也有一些区分。
比如：Neo4J就是属于原生图数据库，它使用的后端存储是专门为Neo4J这种图数据库定制和优化的，理论上说能更有利于发挥图数据库的性能。
而JanusGraph不是原生图数据库，而将数据存储在其他系统上，比如Hbase。
一些图数据库使用原生图存储，这类存储是经过优化的，并且是专门为了存储和管理图而设计的。并不是所有图数据库都是使用原生图存储，也有一些图数据库将图数据序列化，然后保存到关系型数据库或者面向对象数据库，或其他通用数据存储中。
原生图处理（也称为无索引邻接）是处理图数据的最有效方法，因为连接的节点在数据库中物理地指向彼此。非本机图处理使用其他方法来处理CRUD操作。
NoSQL数据库大致可以分为四类：
| 分类 | 数据模型 | 优势 | 劣势 | 举例 |
|---|---|---|---|---|
| 键值数据库 | 哈希表 | 查找速度快 | 数据无结构化，通常只被当作字符串或者二进制数据 | Redis |
| 列存储数据库 | 列式数据存储 | 查找速度快；支持分布横向扩展；数据压缩率高 | 功能相对受限 | HBase |
| 文档型数据库 | 键值对扩展 | 数据结构要求不严格；表结构可变；不需要预先定义表结构 | 查询性能不高，缺乏统一的查询语法 | MongoDB |
| 图数据库 | 节点和关系组成的图 | 利用图结构相关算法(最短路径、节点度关系查找等) | 可能需要对整个图做计算，不利于图数据分布存储 | Neo4j、JanusGraph |
与关系型数据库和 NoSQL 数据库相比，定义良好的图数据库都有着明显优势。具体如下：
更好、更快速的查询和分析
无论数据大小，图数据库均可出色查询相关数据。图模型提供了内置的索引数据结构，它无需针对给定查询而 加载或接触无关数据。图模式的高效率使其成为出色的解决方案，能够更好更快地进行实时大数据分析查询。这与 NoSQL 数据库（如 MongoDB、HBase/HDFS (Hadoop) 和 Cassandra）相反，NoSQL 数据库的架构针对数据湖、 顺序扫描和新数据附加（不随机查找）而构建。在此类系统中，每次查询都会涉及大部分的数据文件，关系型数据 库则更加糟糕，处理全量数据很慢，并且需要给表建立连接才能呈现表间的关系。
更简化、更自然的数据建模
任何学习过关系型数据库建模的人都了解，满足数据库标准化和参照完整性需要遵循严格规则。某些 NoSQL 架构走向了另一极端，将所有类型的数据放在一个大型表中。而在图数据库中，您可以定义所需的任意点类型，并 定义任意边类型来表示点之间的关系。图模型则是按需定义，没有冗余的标准化和浪费。
由点及面地挖掘知识体系
知识图当然也是图。知识图是以 < 主语 >< 谓语 >< 宾语 >（如 <Pat>< 有 >< 船 >）的形式表示的各个事实的集合。 以 < 主语 > 和 < 宾语 > 为点，< 谓语 > 为点之间的边，这构成了图。知识图的实际功能是查看整体：遵循一系列边、 分析邻域或分析整个图。这样，您可以推断或推理出新的关系。
面向对象的思维
在图中，每个点和边都是自包含对象实例。在基于模式的图数据库中，用户定义点类型和边类型，就像对象类一 样。此外，将点关联至其他点的边有点类似于对象方法，因为边说明点可以“做”什么。要处理图中的数据，需要 “遍历”边，在概念上是指从一个点遍历到相邻点，保持数据的完整性。比较而言，在关系型数据库中，要关联两个记录， 必须将它们相连并创建新的数据记录类型。
更强大的问题解决能力
图数据库能够解决对于关系查询不切实际和切合实际的问题。例如迭代算法（如 PageRank、梯度下降）以及 其他数据挖掘和机器学习算法。某些图查询语言是图灵完备的，这意味着您可以使用它编写任何算法。不过在市场 中有许多表达能力有限的查询语言。
迅速的实时扩展
如上所述，图数据库提供更出色的建模功能，从而能更好地为互联数据提供问题解决能力。但图数据库一直以 来有一项劣势，那就是可扩展性不佳 ：以往的图数据库无法加载或存储超大数据集、无法实时处理查询，并且 / 或 者无法遍历查询中两个以上的连续关联（两步以上）。
不过，现在有了新一代图数据库。基于原生并行图架构，此第三代图数据库拥有出色的速度和可扩展性，可提 供以下优势 ：
并发查询和实时数据更新
许多以前的图系统无法实时获取新数据，因为它们构建在以牺牲写入性能来换取良好读取性能的 NoSQL 数据 存储之上。但许多应用都需要实时更新，例如欺诈检测、个性化实时推荐以及任何交易或流数据应用。原生并行图 可实时处理读取和写入。并行通常与并发控制相结合，以便为读取查询和图更新提供很高的每秒查询量。
深度关联分析
原生并行图设计提供的最重要优势之一就是能够在超大图上实时处理遍历多步（10 步以上）的查询。原生图存储 （加快每次数据访问速度）和并行处理（同时处理多个操作）相结合，可将许多用例从不可能变为可能。
动态模式更改
原则上，图模型允许您通过定义新的点类型和边类型来描述新的数据类型和新的关系类型。或者您可能需要添 加或减少属性。您可以关联多个数据集，只需加载数据集并添加一些新边即可关联。具体难易程度根据实际情况有 所不同。原生并行图是彻彻底底的图，在设计时考虑了图模式发展，因此可动态处理模式更改，即在图处于使用状 态时进行处理。
简单的多维度数据表示
假设您想要向实体添加地理位置属性，或者想要记录时间序列数据。您当然可以使用关系型数据库来完成。但 通过图数据库，您可以选择将位置和时间视为点类型和属性。或者使用带有权重的边来明确关联在空间或时间上彼 此接近的实体。可以创建一系列边以表示因果变化。与关系模型不同，无需创建多维数据集来表示多个维度。每个 新点类型和边类型均表示潜在的新维度 ；实际边表示实际关系。让多维度表现关系成为无限可能。
高级聚合及分析
除了传统的按组划分聚合之外，原生并行图数据库还可以执行更复杂的聚合，这些聚合在关系型数据库中是不 可想象或不切实际的。由于采用表模型，关系型数据库上的聚合查询受到数据分组方式的极大限制。与此相反，图 的多维度性质和新型图数据库的并行处理功能可让用户高效地分割、切分、汇总、转换甚至更新数据，而无需预处 理数据或使数据进入强模式。
增强的机器学习和人工智能
我们已经说过，图可以用做知识图，使人能进一步推理间接事实和知识。此外，任何图都是优化机器学习的强 大武器。首先，对于无监督学习，图模型可出色检测集群和异常，因为您只需关注关联。监督学习始终需要更多、 更好的训练数据，而图能够提供先前被忽视的特性，是出色的提供源。例如，实体出度或两实体之间的最短路径等 简单特性可提供缺失部分以提高预测准确性。如果机器学习 / 人工智能应用需要实时决策，我们需要快速的图数据 库。图数据库成功用作实时人工智能数据基础架构的关键在于 ：
横向扩展和纵向扩展以管理大型图
原生图数据库具有诸多优势，它可管理传统关系型数据库无法处理的大数据。不过，与替代旧技术的任何新技 术一样，图数据库的应用仍存在障碍。这包括图数据库查询语言的非标准化。有一些不成熟的产品导致性能和实用 性低于标准，减慢了图模型的应用速度。
关系型数据库实际上是不擅长处理关系的。很多场景下，你的业务需求完全超出了当前的数据库架构。
举个栗子：假设某关系型数据库中有这么几张用户、订单、商品表：
当我们要查询：“用户购买了那些商品？” 或者 “该商品有哪些客户购买过？” 需要开发人员JOIN几张表，效率非常低下。
而“购买该产品的客户还购买了哪些商品？”类似的查询几乎不可能实现。
关系查询性能对比
在数据关系中心，图形数据库在查询速度方面非常高效，即使对于深度和复杂的查询也是如此。在《Neo4j in Action》这本书中，作者在关系型数据库
和图数据库(Neo4j)之间进行了实验。
他们的实验试图在一个社交网络里找到最大深度为5的朋友的朋友。他们的数据集包括100万人，每人约有50个朋友。实验结果如下：
| 深度 | MySQL执行时间(s) | Neo4J执行时间(s) | 返回记录数 |
|---|---|---|---|
| 2 | 0.016 | 0.01 | ~2500 |
| 3 | 30.267 | 0.168 | ~110 000 |
| 4 | 1543.505 | 1.359 | ~600 000 |
| 5 | 未完成 | 2.132 | ~800 000 |
在深度为2时（即朋友的朋友），两种数据库性能相差不是很明显；深度为3时(即朋友的朋友的朋友)，很明显，关系型数据库的响应时间30s，已经变得不可接受了；深度到4时，关系数据库需要近半个小时才能返回结果，使其无法应用于在线系统；深度到5时，关系型数据库已经无法完成查询。而对于图数据库Neo4J，深度从3到5，其响应时间均在3秒以内。
可以看出，对于图数据库来说，数据量越大，越复杂的关联查询，约有利于体现其优势。从深度为4/5的查询结果我们可以看出，图数据库返回了整个社交网络一半以上的人数。
Graph DBMS, also called graph-oriented DBMS or graph database, represent data in graph structures as nodes and edges, which are relationships between nodes. They allow easy processing of data in that form, and simple calculation of specific properties of the graph, such as the number of steps needed to get from one node to another node.
Graph DBMSs usually don't provide indexes on all nodes, direct access to nodes based on attribute values is not possible in these cases.
Find more systems in our graph DBMS ranking.
https://db-engines.com/en/ranking/graph+dbms
优点在于省去了你把关系模型翻译成关系型数据库schema的痛苦，而且界面友好，入手门槛低，做个小应用非常适合。
缺点在于性能差，无法分库分表，并发量上去分分钟死给你看。加缓存也顶不住。而且缓存本身大多是KV结构，不是图结构，存在转换问题。图数据库适合用访问量不大的2B金融数据分析，知识图谱等场景。对于高并发的社交类场景，如果要使用，需要自己做很多很多很多的优化，非常麻烦。不知道Facebook和Twitter是怎么解决这类问题的。
图数据库适合存储修改较少、查询较多、没有超大节点的图数据结构。
Java, Scala 语言开发，支持Linux、OS X、Solaris、Windows等平台的开源图数据库。
Bolt protocol
Cypher query language
Java API
Neo4j-OGM info
RESTful HTTP API
Spring Data Neo4j
TinkerPop 3
.Net
Clojure
Elixir
Go
Groovy
Haskell
Java
JavaScript
Perl
PHP
Python
Ruby
Scala
Neo4j is a native graph database platform that is built to store, query, analyze and manage highly connected data more efficiently than other databases. The Neo4j database is highly scalable both vertically and horizontally, without introducing data integrity or consistency issues using its Causal Clustering architecture, which now supports mulit-clustering. Customers have deployed graphs with 10's of Billions of nodes and relationships. Data relationships are first class entities and can be traversed in constant time without index lookups (high-performance native indexes can be set.) That allows even complex queries to deliver results in milliseconds rather than in minutes. Architected from bare-metal upwards for the property graph model from the point that the graph is conceived, drawn or visualized, to how it is coded in graph-specific syntax to how it computes and executes queries all the way to how it persists connections in storage. Neo4j is charting the path to the graph paradigm by focusing on data connectedness, rather than how relational and NoSQL databases focus on how data is collected. Graph use cases are everywhere, and Neo4j covers them all.
Neo4j database is the only transactional database that combines everything you need for performance and trustability in applications that bring data relationships to the fore: native graph storage, native graph processing, graph scalability, high availability, graph clustering, graphs in the cloud, graphs on Spark, built-in ETL, and integration support, plus Cypher, a powerful and expressive language for queries using vastly less code than SQL.
https://neo4j.com/developer/guide-data-modeling/
Neo4j’s Property Graphs are composed of nodes and relationships, either of which may have properties. Nodes represent entities, for example concepts, events, places and things. Relationships connect pairs of nodes.
Nodes are often used to represent entities. The simplest possible graph is a single node.
Consider the graph below, consisting of a single node.
Labels are used to shape the domain by grouping nodes into sets where all nodes that have a certain label belongs to the same set.
For example, all nodes representing users could be labeled with the label :User. With that in place, you can ask Neo4j to perform operations only on your user nodes, such as finding all users with a given name.
Since labels can be added and removed during runtime, they can also be used to mark temporary states for nodes. A :Suspended label could be used to denote bank accounts that are suspended, and a :Seasonal label can denote vegetables that are currently in season.
A node can have zero to many labels.
In the example above, the nodes have the labels Person and Movie, which is one possible way of describing the data. But assume that we want to express different dimensions of the data. One way of doing that is to add more labels.
Below is an example showing the use of multiple labels:
A relationship connects two nodes. Relationships organize nodes into structures, allowing a graph to resemble a list, a tree, a map, or a compound entity — any of which may be combined into yet more complex, richly inter-connected structures.
Our example graph will make a lot more sense once we add relationships to it:
A relationship must have exactly one relationship type.
Our example uses ACTED_IN and DIRECTED as relationship types. The roles property on the ACTED_IN relationship has an array value with a single item in it.
Below is an ACTED_IN relationship, with the Tom Hanks node as the source node and Forrest Gump as the target node.
We observe that the Tom Hanks node has an outgoing relationship, while the Forrest Gump node has an incoming relationship.
Relationships always have a direction. However, you only have to pay attention to the direction where it is useful. This means that there is no need to add duplicate relationships in the opposite direction unless it is needed in order to properly describe your use case.
Note that a node can have relationships to itself. If we want to express that Tom Hanks KNOWS himself, that would be expressed as:
Properties are name-value pairs that are used to add qualities to nodes and relationships.
Cypher is a declarative graph query language that allows for expressive and efficient querying, updating and administering of the graph. It is designed to be suitable for both developers and operations professionals. Cypher is designed to be simple, yet powerful; highly complicated database queries can be easily expressed, enabling you to focus on your domain, instead of getting lost in database access.
Cypher is inspired by a number of different approaches and builds on established practices for expressive querying. Many of the keywords, such as WHERE and ORDER BY, are inspired by SQL. Pattern matching borrows expression approaches from SPARQL. Some of the list semantics are borrowed from languages such as Haskell and Python. Cypher’s constructs, based on English prose and neat iconography, make queries easy, both to write and to read.
Structure
Cypher borrows its structure from SQL — queries are built up using various clauses.
Clauses are chained together, and they feed intermediate result sets between each other. For example, the matching variables from one MATCH clause will be the context that the next clause exists in.
The query language is comprised of several distinct clauses. These are discussed in more detail in the chapter on Clauses.
The following are a few examples of clauses used to read from the graph:
MATCH: The graph pattern to match. This is the most common way to get data from the graph.WHERE: Not a clause in its own right, but rather part of MATCH, OPTIONAL MATCH and WITH. Adds constraints to a pattern, or filters the intermediate result passing through WITH.RETURN: What to return.Let’s see MATCH and RETURN in action.
Let’s create a simple example graph with the following query:
CREATE (john:Person {name: 'John'})
CREATE (joe:Person {name: 'Joe'})
CREATE (steve:Person {name: 'Steve'})
CREATE (sara:Person {name: 'Sara'})
CREATE (maria:Person {name: 'Maria'})
CREATE (john)-[:FRIEND]->(joe)-[:FRIEND]->(steve)
CREATE (john)-[:FRIEND]->(sara)-[:FRIEND]->(maria)
For example, here is a query which finds a user called 'John' and 'John’s' friends (though not his direct friends) before returning both 'John' and any friends-of-friends that are found.
MATCH (john {name: 'John'})-[:FRIEND]->()-[:FRIEND]->(fof)
RETURN john.name, fof.name
Resulting in:
+----------------------+
| john.name | fof.name |
+----------------------+
| "John" | "Maria" |
| "John" | "Steve" |
+----------------------+
2 rows
Next up we will add filtering to set more parts in motion:
We take a list of user names and find all nodes with names from this list, match their friends and return only those followed users who have a 'name' property starting with 'S'.
MATCH (user)-[:FRIEND]->(follower)
WHERE user.name IN ['Joe', 'John', 'Sara', 'Maria', 'Steve'] AND follower.name =~ 'S.*'
RETURN user.name, follower.name
Resulting in:
+---------------------------+
| user.name | follower.name |
+---------------------------+
| "Joe" | "Steve" |
| "John" | "Sara" |
+---------------------------+
2 rows
And these are examples of clauses that are used to update the graph:
CREATE (and DELETE): Create (and delete) nodes and relationships.SET (and REMOVE): Set values to properties and add labels on nodes using SET and use REMOVE to remove them.MERGE: Match existing or create new nodes and patterns. This is especially useful together with unique constraints.
相信您和我一样，在使用关系型数据库时常常会遇到一系列非常复杂的设计问题。例如一部电影中的各个演员常常有主角配角之分，还要有导演，特效等人员的参与。通常情况下这些人员常常都被抽象为Person类型，对应着同一个数据库表。同时一位导演本身也可以是其它电影或者电视剧的演员，更可能是歌手，甚至是某些影视公司的投资者(没错，我这个例子的确是以赵薇为模板的)。而这些影视公司则常常是一系列电影，电视剧的资方。这种彼此关联的关系常常会非常复杂，而且在两个实体之间常常同时存在着多个不同的关系：
在尝试使用关系型数据库对这些关系进行建模时，我们首先需要建立表示各种实体的一系列表：表示人的表，表示电影的表，表示电视剧的表，表示影视公司的表等等。这些表常常需要通过一系列关联表将它们关联起来：通过这些关联表来记录一个人到底参演过哪些电影，参演过哪些电视剧，唱过哪些歌，同时又是哪些公司的投资方。同时我们还需要创建一系列关联表来记录一部电影中哪些人是主角，哪些人是配角，哪个人是导演，哪些人是特效等。可以看到，我们需要大量的关联表来记录这一系列复杂的关系。在更多实体引入之后，我们将需要越来越多的关联表，从而使得基于关系型数据库的解决方案繁琐易错。
这一切的症结主要在于关系型数据库是以为实体建模这一基础理念设计的。该设计理念并没有提供对这些实体间关系的直接支持。在需要描述这些实体之间的关系时，我们常常需要创建一个关联表以记录这些数据之间的关联关系，而且这些关联表常常不用来记录除外键之外的其它数据。也就是说，这些关联表也仅仅是通过关系型数据库所已有的功能来模拟实体之间的关系。这种模拟导致了两个非常糟糕的结果：数据库需要通过关联表间接地维护实体间的关系，导致数据库的执行效能低下;同时关联表的数量急剧上升。
这种执行效能到底低下到什么程度呢?就以建立人和电影之间的投资关系为例。一个使用关联表的设计常常如下所示：
如果现在我们想要通过该关系找到一部电影的所有投资人，关系型数据库常常会执行哪些操作呢?首先，在关联表中执行一个Table Scan操作(假设没有得到索引支持)，以找到所有film域的值与目标电影id相匹配的记录。接下来，通过这些记录中的person域所记录的Person的主键值来从Person表中找到相应的记录。如果记录较少，那么这步就会使用Clustered Index Seek操作(假设是使用该运算符)。整个操作的时间复杂度将变为O(nlogn)：
可以看到，通过关联表组织的关系在运行时的性能并不是很好。如果我们所需要操作的数据集包含了非常多的关系，而且主要是在对这些关系进行操作，那么可以想象到关系数据库的性能将变得有多差。
除了性能之外，关联表数量的管理也是一个非常让人头疼的问题。刚刚我们仅仅是举了一个具有四个实体的例子：人，电影，电视剧，影视公司。现实生活中的例子可不是这么简单。在一些场景下，我们常常需要对更多的实体进行建模，从而完整地描述某一领域内的关联关系。这种关联关系所涵盖的可能包含影视公司的控股关系，各控股公司之间复杂的持股关系以及各公司之间的借贷款情况及担保关系等，更可能是人之间的关系，人与各个品牌之间的代言关系，各个品牌与所属公司之间的关系等。
可以看到，在需要描述大量关系时，传统的关系型数据库已经不堪重负。它所能承担的是较多实体但是实体间关系略显简单的情况。而对于这种实体间关系非常复杂，常常需要在关系之中记录数据，而且大部分对数据的操作都与关系有关的情况，原生支持了关系的图形数据库才是正确的选择。它不仅仅可以为我们带来运行性能的提升，更可以大大提高系统开发效率，减少维护成本。
相对于关系数据库中的各种关联表，图形数据库中的关系可以通过关系能够包含属性这一功能来提供更为丰富的关系展现方式。因此相较于关系型数据库，图形数据库的用户在对事物进行抽象时将拥有一个额外的武器，那就是丰富的关系：
因此在为图形数据库定义数据展现时，我们应该以一种更为自然的方式来对这些需要展现的事物进行抽象：首先为这些事物定义其所对应的结点集，并定义该结点集所具有的各个属性。接下来辨识出它们之间的关系并创建这些关系的相应抽象。
因此一个图形数据库中所承载的数据最终将有类似于下图所示的结构：
A high level look of the architecture looks like:
Drivers are used to connect to the database. At the moment these come in three variants: Embedded, HTTP and the binary protocol Bolt. The latter uses the official Neo4j Java driver.
Neo4j Object Graph Mapper (Neo4j-OGM)
Spring Data Neo4j provides code on top of Neo4-OGM to help quickly build Spring based Neo4j apps.
Those coming from other Spring Data projects or are familiar with ORM products like JPA or Hibernate may quickly recognise this architecture.
https://spring.io/projects/spring-data-neo4j
Spring Data support for the Neo4j Graph Database, including annotated POJOs, SD-Repositories and Neo4j-Template.
Spring Data Neo4j offers advanced features to map annotated entity classes to the Neo4j Graph Database. The template programming model is equivalent to other Spring templates and builds the basis for interaction with the graph and is also used for the Spring Data repository support. Spring Data Neo4j is core part of the Spring Data project which aims to provide convenient data access for NoSQL databases.
Support for property graphs (nodes connected via relationships, each with arbitrary properties)
Object-Graph-Mapping of annotated POJO entities
extensive Spring Data Commons Repositories Support, including annotated and derived finder methods
Arbitrary result projections for finder methods
Supports the Cypher Graph Quey Language Support for Neo4j causal clusters Based on the Neo4j-OGM library Supports binary (bolt), http and embedded transports to connect to Neo4j Available with Spring Boot
https://github.com/spring-projects/spring-data-examples/tree/master/neo4j
Spring Data Neo4j 使用：https://www.jianshu.com/p/2b7cfb002bd9
图数据库应对的是当今一个宏观的商业世界的大趋势：凭借高度关联、复杂的动态数据（人工智能、知识图谱等等），获得洞察力和竞争优势。
国内越来越多的公司开始进入图数据库领域，研发自己的图数据库系统。
对于任何达到一定规模或价值的数据，图数据库都是呈现和查询这些关系数据的最好方式。而理解和分析这些图的能力将成为企业未来最核心的竞争力。
https://db-engines.com/en/ranking/graph+dbms
https://neo4j.com/docs/getting-started/current/cypher-intro/patterns/
https://neo4j.com/docs/cypher-manual/4.0/introduction/#cypher-introduction
https://spring.io/projects/spring-data-neo4j
https://www.cnblogs.com/loveis715/p/5277051.html
https://neo4j.com/developer/guide-data-modeling/
https://www.w3cschool.cn/neo4j/neo4j_cql_introduction.html
https://www.cnblogs.com/jpfss/p/10874001.html
https://www.cnblogs.com/mantoudev/p/10414495.html
https://www.zhihu.com/question/19916683
国内第一Kotlin 开发者社区公众号，主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。
越是喧嚣的世界，越需要宁静的思考。、
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
