实际上为了更好的描述实体之间的关系，我们要是再继续使用Redis的话，是不是感觉实体之间的关系不够那么的明显，虽然也是属于NoSQL的一种，但是相对来说，Redis，表现实体之间的关系就没有那么清晰了，为了更好的描述实体之间的关系，就会使用图形数据库来进行了，那么今天阿粉介绍的，就是一个图形化的数据可，Neo4J。
创新互联建站主要从事成都网站建设、网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务汤原,十多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108
Neo4j是一个世界领先的开源的基于图的数据库。 它是使用Java语言完全开发的。那么什么是图数据库呢？图数据库是以图结构的形式存储数据的数据库。 它以节点，关系和属性的形式存储应用程序的数据。正如RDBMS以表的“行，列”的形式存储数据，GDBMS以图的形式存储数据。
RDBMS与图数据库的区别
1.Tables 表Graphs 图表
2.Rows 行Nodes 节点
3.Columns and Data 列和数据 Properties and its values属性及其值
4.Constraints 约束Relationships 关系
5.Joins 加入Traversal 遍历
说完了图形数据库，我们就来看看这个 Neo4J 数据库吧
neo4j是用Java语言编写的图形数据库，运行时需要启动JVM进程，因此，需安装JAVA SE的JDK。关于 Java 怎么安装，我就不用再多废话了吧，到时候别忘了检测一下 Java 的版本就好了， java -version
接下来我们就是要进行一个安装了，我们先去官网，下载社区版，企业版要收费的，注意哈。
官网地址
下载完成，直接开始安装，傻瓜式操作即可。
Neo4j应用程序有如下主要的目录结构：
注意，如果你使用的是Zip的压缩包来进行的使用的话，那么你就需要注意一些地方，比如你如果是用 Zip 的包解压之后，并且想要通过 bat 的命令启动，直接在目录下进行 cmd ，然后 neo4j.bat ,这时候可能会出现一个问题，就是版本可能会出现问题，你如果下载使用的是最新版的 Neo4J ,那么就可能会让你使用 JDK 11 ，而阿粉就是踩过了这个大坑之后，才发现，bat 闪退的原因。
这样就是说明我们的 JDk 的版本对应的和 Neo4J 需要的 JDK 是不匹配的，我们就需要换一下我们的 JDK 了。把他换成 JDK 11 就好了，再次启动。
这时候，我们就直接访问 localhost：7474 的端口，直接就能看到如下的画面， 1.jpg
刚进入的时候可能需要大家输入帐号密码，默认的帐号密码就是，neo4j 修改成你想要的就行了。
这样登录进去我们就能开始正式学习 Neo4J 的所有内容了。
Neo4j - CQL语法
我们在讲语法之前首先我们先得看看 Neo4J 的构建模块，不然之后的查询都是无意义的。
Neo4j图数据库主要有以下构建块 -
节点是图表的基本单位。 它包含具有键值对的属性，如下所示
属性是用于描述图节点和关系的键值对
关系是图形数据库的另一个主要构建块。 它连接两个节点，如下所示。
Label将一个公共名称与一组节点或关系相关联。 节点或关系可以包含一个或多个标签。 我们可以为现有节点或关系创建新标签。 我们可以从现有节点或关系中删除现有标签。
Neo4j数据浏览器 一旦我们安装Neo4j，我们可以访问Neo4j数据浏览器使用以下URL
http：// localhost：7474 / browser /
CREATE 语法
CREATE ( : )
它是我们要创建的节点名称。
它是一个节点标签名称
我们可以创建一个节点，然后给他安排上一个标签
CREATE (emp:Employee)
当我们看到
Added 1 label, created 1 node, completed after 74 ms.
这就创建成功了，
那么怎么查看呢？
MATCH语法
MATCH ( : ) return xxx
是这个样子的
但是看到里面竟然没有东西，就相当于是一个空的对象，那是不是就应该给里面放入属性的操作呢？没错，肯定有
CREATE (emp:Employee{ id : 1001 ,name :"lucy", age : 10})
Added 1 label, created 1 node, set 3 properties, completed after 163 ms. 创建成功。
我们再次查看就能看到
如果我们想只要其中的一些对象的属性，而不是全部属性，那应该怎么操作呢？
RETURN语法
RETURN 可以返回的是一个对象，也可以是对象中的属性，比如：
结果就是下面这个样子的，大家看一下，是不是感觉还是挺好用的。
** WHERE语法**
WHERE
为什么在前面的位置阿粉说，CQL 是和 SQL 类型的，这完全是因为很多东西和 SQL 是类似的。
结果如下：
相同的还有
布尔运算符 描述 AND 和 OR 或者 NOT 非 XOR 异或
比较运算符 描述 = “等于”运算符 “不等于”运算符 “小于”运算符 “大于”运算符 = “小于或等于”运算符。 = “大于或等于”运算符。
DELETE语法
删除语法必然是有的，因为有创建，肯定有删除。
DELETE
但是这个命令也不是单独使用的哈，
MATCH (e: Employee) DELETE e
直接删除成功。
基础的东西讲完了，阿粉就得说说这个比较重要的内容了，关系，
我们之前创建节点的时候，那叫一个简单舒适加愉快，但是创建关系就比较复杂了，因为需要考虑如何匹配到有关系的两个节点，以及关系本身的属性如何设置。这里我们就简单学一下如何建立节点之间的关系。
由于Neo4j CQL语法是以人类可读的格式。 Neo4j CQL也使用类似的箭头标记来创建两个节点之间的关系。
每个关系（ ）包含两个节点
在Neo4j中，两个节点之间的关系是有方向性的。 它们是单向或双向的。
如果我们尝试创建一个没有任何方向的关系，那么就会报错。
关系创建语法
CREATE ( )-[ ]-( )
我们这里直接使用创建新的节点来创建关系。
提示创建成功
这里关系名称是“CONTAINS”
关系标签是“contains”。
这么看是看不出有啥关系的，但是，我们可以从另外的一个位置
这样看下来，这个 Neo4J 简单操作是不是就学会了，阿粉接下来的文章中讲怎么使用 Java 来操作 Neo4J 数据库。欢迎大家来观看。
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：
A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。
难点：
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。
Hadoop
文件系统：文件系统是用来存储和管理文件，并且提供文件的查询、增加、删除等操作。
直观上的体验：在shell窗口输入 ls 命令，就可以看到当前目录下的文件夹、文件。
文件存储在哪里？硬盘
一台只有250G硬盘的电脑，如果需要存储500G的文件可以怎么办？先将电脑硬盘扩容至少250G，再将文件分割成多块，放到多块硬盘上储存。
通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件，就像本地的ls命令一样。
HDFS在客户端上提供了查询、新增和删除的指令，可以实现将分布在多台机器上的文件系统进行统一的管理。
在分布式文件系统中，一个大文件会被切分成块，分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子，这500G的文件会按照一定的大小被切分成若干块，然后分别存储在若干台机器上，然后提供统一的操作接口。
看到这里，不少人可能会觉得，分布式文件系统不过如此，很简单嘛。事实真的是这样的么？
潜在问题
假如我有一个1000台机器组成的分布式系统，一台机器每天出现故障的概率是0.1%，那么整个系统每天出现故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一个容错机制来保证发生差错时文件依然可以读出，这里暂时先不展开介绍。
如果要存储PB级或者EB级的数据，成千上万台机器组成的集群是很常见的，所以说分布式系统比单机系统要复杂得多呀。
这是一张HDFS的架构简图：
client通过nameNode了解数据在哪些DataNode上，从而发起查询。此外，不仅是查询文件，写入文件的时候也是先去请教NameNode，看看应该往哪个DateNode中去写。
为了某一份数据只写入到一个Datanode中，而这个Datanode因为某些原因出错无法读取的问题，需要通过冗余备份的方式来进行容错处理。因此，HDFS在写入一个数据块的时候，不会仅仅写入一个DataNode，而是会写入到多个DataNode中，这样，如果其中一个DataNode坏了，还可以从其余的DataNode中拿到数据，保证了数据不丢失。
实际上，每个数据块在HDFS上都会保存多份，保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。
接下来我们来看一下完整的文件写入的流程：
大文件要写入HDFS，client端根据配置将大文件分成固定大小的块，然后再上传到HDFS。
读取文件的流程：
1、client询问NameNode，我要读取某个路径下的文件，麻烦告诉我这个文件都在哪些DataNode上？
2、NameNode回复client，这个路径下的文件被切成了3块，分别在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3个文件块，通过stream读取并且整合起来
文件写入的流程：
1、client先将文件分块，然后询问NameNode，我要写入一个文件到某个路径下，文件有3块，应该怎么写？
2、NameNode回复client，可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上，记住，每个块重复写3份，总共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把数据写到他们上面
出于容错的考虑，每个数据块有3个备份，但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力，这个点是否有更好的解决方案呢？回忆一下mysql主备之间是通过binlog文件进行同步的，HDFS当然也可以借鉴这个思想，数据其实只需要写入到一个datanode上，然后由datanode之间相互进行备份同步，减少了client端的写入压力，那么至于是一个datanode写入成功即成功，还是需要所有的参与备份的datanode返回写入成功才算成功，是可靠性配置的策略，当然这个设置会影响到数据写入的吞吐率，我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。
潜在问题
NameNode确实会回放editlog，但是不是每次都从头回放，它会先加载一个fsimage，这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照，然后再在这个基础上回放editlog，完成后，会清空editlog，再把当前文件元数据的内存状态写入fsimage，方便下一次加载。
这样，全量回放就变成了增量回放，但是如果NameNode长时间未重启过，editlog依然会比较大，恢复的时间依然比较长，这个问题怎么解呢？
SecondNameNode是一个NameNode内的定时任务线程，它会定期地将editlog写入fsimage，然后情况原来的editlog，从而保证editlog的文件大小维持在一定大小。
NameNode挂了， SecondNameNode并不能替代NameNode，所以如果集群中只有一个NameNode，它挂了，整个系统就挂了。hadoop2.x之前，整个集群只能有一个NameNode，是有可能发生单点故障的，所以hadoop1.x有本身的不稳定性。但是hadoop2.x之后，我们可以在集群中配置多个NameNode，就不会有这个问题了，但是配置多个NameNode，需要注意的地方就更多了，系统就更加复杂了。
俗话说“一山不容二虎”，两个NameNode只能有一个是活跃状态active，另一个是备份状态standby，我们看一下两个NameNode的架构图。
两个NameNode通过JournalNode实现同步editlog，保持状态一致可以相互替换。
因为active的NameNode挂了之后，standby的NameNode要马上接替它，所以它们的数据要时刻保持一致，在写入数据的时候，两个NameNode内存中都要记录数据的元信息，并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的，并且standby NameNode实现了SecondNameNode的功能。
进行数据同步操作的过程如下：
active NameNode有操作之后，它的editlog会被记录到JournalNode中，standby NameNode会从JournalNode中读取到变化并进行同步，同时standby NameNode会监听记录的变化。这样做的话就是实时同步了，并且standby NameNode就实现了SecondNameNode的功能。
优点：
缺点：
按照你的需求来购买，比如 ： 数据库选型（mysql，nosql） 内存多大 磁盘多大 等等
重庆分公司
重庆分公司
