开发者学堂课程【高校精品课-上海交通大学-企业级应用体系架构：Neo4J 1】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/75/detail/15850
Neo4J 1（一）
内容介绍：
一、Neo4J and RockDB
二、What is a Graph？
三、Graph Database
四、Options for Storing Connected Date
五、Data Modeling with Graphs
六、Building a Graph Database Application
七、总结
一、Neo4J and RockDB
本课程讲解图数据库和日志数据库，主要讲解它的基本原理。图数据库以 Neo4J 为例，Neo4J 是图数据库的一种，并不是唯一的一个，就像在讲 MongoDB 的时候讲 MongoDB 是nosql 的一种一样；
· Neo4J
- Graph Database
-Options for Storing Connected Data
- Data Modeling with Graphs
- Building a Graph Database Application
-Graph Database Internals
RockDB 是另外一种日志类的数据库。
·RocksDB
-LevelDB & RocksDB
-SSTable Structure
数据可以在关系型数据库存储，实际上在一个系统里，数据不是只能存储在关系型数据库里，还可以存到 mongo db 里，mongo db 本质上是 kv的数据。除了这两种之外还有其他的选择，图数据库跟前两种有很大的差异，日志数据库跟前面的也不一样
在一个系统里，数据不一定要存储在某一种里，设计 DAO 的层，通过它屏蔽数据源的差异，而底下真正的数据应该存储在它适合的数据库里。也许一个系统里的数据库包含了这四种都有，他们在支撑不同的应用。尤其是企业级应用，规模比较大，所以不可能是一种数据库，有很多种数据库，但是要通过 DAO 层做屏蔽，对上看到的是一个一个的对象，对下要把数据库调做对象到数据的转换。
在 spring 里面，用 spring 的 mango db 的 template 进行访问，或者用 spring JPA 的关系型数据库。同样，spring 对图数据库也有 template，几乎会以同样的方式生成 repository 来访问。如果经常使用 person 这样的数据，存储到了图数据库里，然后用 spring template 来访问；person 本身存关系型数据库也可以，但是存了一些适合图数据库存储的信息，信息是什么。
二、What is a Graph？
1、图是由节点和边构成的，在图数据库里要描述的数据是什么？
首先，先看节点，节点有一个 label，label 可以认为像数据的类型一样，这三个都是 user。下面是 Message，是它们之间互相发的信息，假如是一个社交网站。
除了 label 它里面有一些属性，这些属性都是键值对的构成，比如说在第一个节点里可以看到它有一个 name 属性（Billy），下面两个也是一样。节点和节点之间有边，这个边是有向的，边也可以有属性，这上面没有写，但是它有一个 name，也可以认为这就是它的 label，或者叫它 name，这是表示两个节点之间的关系它的名字是什么。FOLLOWS 可以理解为twitter 或微博上面的谁 FOLLOWS 谁的关系，这是一个带方向的，所以边是有向的，边上面带名字表示关系的名字，描述节点和节点之间的关系，另外可以带属性。上面图在描述三个人互相的关系，billy 在社交网站上跟 Harry 是互相 FOLLOWS 的，Harry 跟Ruth 是互相 FOLLOWS，Ruth 单方向 FOLLOWS Billy。
2、如果把他们发的推文或微博加进去，Ruth 发了一条新的消息，这个消息就是 CURRENT 当前的新消息，消息的 label 是message，他的 ID 是101，他会用 previous 的关系跟上一条消息关联。他会把所有的 message 串起来，这里面就有 message 和 message 之间的 previous 关系，人 user 和 message 之间的 CURRENT 关系，以及 user 和 user 之间的follows 关系，这是表达一个图数据，用关系型数据库也能表达。上半部分的关系完全可以设计出来一张 user 的表，它本身会有 id、name、follow，如果一个人要 follow 多个的话，可以再建一张 follow 的表。
三、Graph Database
1、为什么要用图数据库存储呢？如果节点和节点之间的关系数据用关系型数据库存储会出现什么样的问题？
·Agraph database management system (henceforth, a graph
database)is
- an online database management system with CreateRead,Update,and Delete (CRUD) methods that expose a graph data model.
-Graph databases are generally built for use with transactional (OLTP) systems.
- Accordingly, they are normally optimized for transactional performance,and engineered with transactional integrity and operational availability in mind.
·There are two properties of graph databases we should consider when investigating graph database technologies:
- The underlying storage
- The processing engine
图数据库就是专门用来存储图的，它里面存的节点和边这种实体和关系，里面有增删改查的动作，也能够支持事务模型对单个节点进行操作。
2、图书据库不止 Neo4J 一种，实际上有好几种，根据底层的存储，到底怎样存储这些图，以及怎样处理这些图数据，比如说要在里面做搜索是怎样来实现的？根据这两点有两个维度的划分，下面是给出的一些图数据库主流的一些产品。
Neo4J 只是其中一种，并不是只有它。图的数据的处理从两个维度上去看，原点表明是非native 的数据，Native 越高，用本地化自己的语言去编写自己的一套支撑东西，比如他的搜索语言，像 HKwai 一样有自己的 sex，有自己的东西 native 程度较高。从这里的排序可以看出 Neo4J 最成熟、丰富，用起来最好用，所以以他为例来讲。
四、Options for Storing Connected Date
1、下图是写电子商城一般应该具有的表，大概会有四张表。
一张表示用户，用户和 order 之间是一对多的，所以 order 会有一个外键关联 user 的 id，user ID 是他的主键。一个订单里面每次可能会买两样或三样的东西不等，所以要有一个 lineltem，1234这个订单买了两样东西，765买了两个，787买了一个，映射底下的 product，映射765 potatoes，987是意大利面。这就是整个设计，在关系型数据库里就是这样设计的。关系型数据库有一个问题，正常情况下想知道单个表的数据没什么问题，但是涉及到复杂问题时，很难一次性得到数据，要做多次 join，举一个场景，如果别人问你电子商城里哪一样物品最好卖，到 order item，按 producti ID 做统计，每一种 product ID 数量加起来，累加起来之后看谁最大，比如765最多，然后拿到765再到 product 表中做 join 操作，才知道是土豆拿的最多。如果问你 Alice 买什么东西最多，就是所有的表串在一起做 join，先拿到 Alice 知道他的 user ID，在到 order 里面找 Alice 所有的订单，在拿 Alice 所有的订单信息到 lineltem 找每个订单都买了什么东西，再把不同的东西数量加起来看谁最大，然后到 product 中在去做 join。所以有四次 join，join 操作是比较耗时的，碰到这种搜索的时候效率不是很高，可能是因为表很多，再举一个表较少的例子。
2、比如说想把刚才的好友关系存一下，首先先把人存一下，每个人有一个ID，其次存好友关系。
第一个人 Alice 的好友有第二个 Bob，Bob 的好友有1，就是 Alice，2，99是 Zach，Zach 的好友有1，那就是 Alice。他存的是下面的结果，
Alice 跟 Bob 互相关注，Bob 还有好友是 Zach。表存好了，想要找 Bob 的朋友都有谁，下面是写出的逻辑。
SELECT p1.Person
FROM Person p1 JOIN PersonFriend
ON PersonFriend.FriendID=p1.ID
JOIN Person p2
ON PersonFriend.PersonlD=p2ID
WHERE p2.Person='Bob'
要找出符合条件的人p1，拿 person 表跟 personfriend 做一次连接，在 personfriend 里面FriendID 要等于 p1.ID；p2 是在 personID 里面等于 p2. ID。也就是 Bob 这个人是 person2，拿着他到 PersonFriend 表里把 personID 等于 Bob ID 的所有人拿出来，拿他们的 person ID，要再到 person 里把人拿出来。这里面有两次 JOIN，第一次是 Bob 到 Person 里拿人的 ID，再到 PersonFriend 关联，找出关联的人；第二次是拿 PersonFriend 里的friend ID 到 Person 里再关联一次，找到他的好友到底是谁
3、如果问 Alice 朋友的朋友是谁？跟刚才一样，Join 比刚才还多一次，因为要找朋友的朋友，要做多次 join 的操作。
SELECT p1.Person AS PERSON,
p2.Person AS FRIENDOF_FRIEND
FROM PersonFriend pf1 JOIN Person p1
ON pf1.PersonlD=p1.ID
JOIN PersonFriend pf2
ON pf2.PersonID=pf1.FriendID
JoIN Person p2
ON pf2.FriendID=p2.ID
WHERE p1.Person='Alice'AND pf2.FriendID<> p1.ID
还有一个例子，代码是一样的，但是问法不一样，问法是：谁是Bob的朋友？不管怎样，都要做多次 join，join 非常废时，表的数量如果很长的话，非常废时力等操作，所以效率会很低
4、如果不这样做，把它存到 mongo db 里是否可行？
存的有一个 Document，现在是 user，值是 Alice，有 friends 键，值是数组，但是只有一个 Bob。第二个，document，表示 Bob；第三个document，表示 Zach。Bob 是 Alice 和 Zach 同时的朋友，现实生活中很难解释这是什么意思，这里只是为了说明问题。对于 Bob 来说，刚才要找 Bob 的朋友，找到的是 Alice，Zach。Alice 和 Zach 之间是朋友吗？
没有办法直接知道，要在去找 Alice，找 Zach，看他俩之间的关系。也就是说这存储的并不是很直观，不能从这个结果中直接推导出来 Alice 和 Zach 是朋友关系，要再去搜索 document 处理。
5、在 mango db 里订单的存储要这样存，下面是一个 document，他买的订单在不断增加，每一个订单都是一个 document，里面会显示他买了什么东西，每一行都会显示具体买的什么。拿到它之后可以想想刚才的问题是否能解决，什么东西卖的最多，是这样一个引用关系，
要想知道 Alice 买的什么东西最多，还需要经历搜索，如果是问什么东西卖的最多，要暴力法遍历所有的订单，然后到里面找所有的 item，看哪样东西卖的最多。
用非关系型数据库，NOSQL Mango db join 这个动作也需要做，虽然他在 NOSQL 数据库中不叫 JOIN，但是类似的操作必须要有。
6、换个思维，用图数据库描述刚才的动作会怎么样？
Alice、Bob、Zach 都是一个 user，他们互相之间有朋友的关系。如果把边和节点做存储，就没有必要像关系型数据库那样，所有的人要有相同的属性，朋友关系必须用 person friend 表存，可以直接把朋友关系表示成一个实体。对user 来说只存他的键值对，不用存储关系，对于 Friend_of 这种关系也做了一个存储，跟 user 区分开存储，所以把关系隐含在表里或者是 Document 里面，不同的是他把节点和边是分别存储的，但是它的存储方式互相之间有关联，但是分开存的。
一个 user 可以有若干个朋友关系，甚至一个都没有，没有约定都要有相同数量的 friend_of 这种关系，都可以存储到同一个库中进行处理。而且通过这种关系的方式可以来回导入。
7、Alice 在存储刚才的订单信息是这样存的。
Alice 下过两个订单，为了记住下订单的顺序，增加了一个最近下订单的关系，以及这个订单前一个订单 previous 的关系，每个订单包含什么东西存到 item 中。
现在想知道 Alice 经常买东西是什么的时候，可以通过 placed 的关系知道他下了哪些订单，这些关系是归属 Alice 的，所以他没有做任何 join 的操作就可以直接得到这两个订单的信息，通过place 的边，导航就可以得到这两个订单的信息，通过 contains 关系得到所有的 item 关系，这里面不存在任何 join 的动作，不需要 join 这个动作。想知道哪个卖的最多的时候，导航到他下的订单上，然后导航到节点上看节点的入度，一下就能知道哪个卖的最多，拿入度乘以属性就能知道买了多少。
这个过程中不需要做任何 join 操作，所以很快，而且和 mongo db 中不一样的是，mongo db 在引用的时候，如果有两个订单买了同样一个东西，可能会生成两个 Document，不是一个，是一个就意味着这个 document 会被复用，它的性能最多跟刚才入度为二的一样。但是他是边和节点分开存储的，直接访问边就能拿到，而在 mongo db 中，先拿到 order，拿到 order 之后再解析里面的items，拿到 json 对象之后，解析里面有哪些item，拿这些 item 到 item：efab、item：abcd 便利查找。而图数据库只需要根据 contents 关系直接可以发现引用了哪些，不需要在所有的 item 里找符合要求的哪些，所以它的速度一定会快。
8、所以在图数据库中需要涉及到怎样建模，这些数据由节点、关系以及它们的属性和 label 来构成。节点里面包含属性，认为一个 document 是一个节点，document 里面的键值队就是节点的属性。节点实际上就是实体，里面会带一些属性，节点可以有一个或者多个 label，是群组节点的一种手段，类似于 table，一类的节点都具有相同的 label。节点和节点之间的关系就是把节点连接起来，并且把图做一个结构化，这就是考虑图数据库怎样设计他的依据。
·The Labeled Property Graph Model
·A labeled property graph is made up of nodes, relationships，properties, and labels.
-Nodes contain properties.Think of nodes as documents that store properties in the form of arbitrary key-value pairs. In Neo4j, the keys are strings and the values are the Java string and primitive data types, plus arrays of these types.
- Nodes can be tagged with one or more labels. Labels group nodes together, and indicate the roles they play within the dataset.
-Relationships connect nodes and structure the graph.A relationship always has a direction, a single name and a start node and an end node-there are no dangling relationships.Together，a relationship's direction and name add semantic clarity to the structuring of nodes.
