数据分片和 NoSQL

 关注
发布于: 2020 年 07 月 15 日
数据分片分片目标
当单个表的体积太大（比如淘宝或者微信的用户表），单个主机的数据库无法承载时，就需要数据分片，将单个表分散到多个主机的数据库进行存储，提供了水平扩展的能力。
分片实现方式
硬编码实现数据分片，比如基于键值的分片，举例将id作为key映射到服务器编号；基于范围的分片，举例将产品按照价格范围划分；基于目录的分片，
映射表外部存储,基于映射表实现 ，2次数据查找 ，使用较少，可以划为基于目录的分片。
分布式中间件，对应用程序无侵入，最强大的一种分片方式
比如sharding-jdbc，mycat前身为 Amoeba/Cobar，利用mysql的schema实现集群扩容
数据分片面对的挑战-分布式中间件解决
需要大量的额外代码，处理逻辑因此变得更加复杂
无法执行多分片的联合查询
无法使用数据库的事务
随着数据的增长，如何增加更多的服务器
为解决分片的挑战，引入了分布式中间件。
mycat一个彻底开源的，面向企业应用开发的大数据库集群，数据库中间件，介于数据库与应用之间的中间服务。
支持事务、ACID、可以替代MySQL的加强版数据库
一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
一个新颖的数据库中间件产品
mycat原理Mycat 基于sql协议，它拦截了用户发送过来的 SQL 语句，首先对 SQL 语句做了 一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此 SQL 发往后端的真实数据库， 并将返回的结果做适当的处理，最终再返回给用户。复杂的是代码，比如Order by limit等，需要二次处理，最复杂的是join处理，mycat提出了创新性的 ER 分片、全局表、HBT（Human Brain Tech)人工智能的 Catlet、ShareJoin， 以及结合 Storm/Spark 引擎等十八般武艺的解决办法，从而成为目前业界最强大的方案。
应用场景• 单纯的读写分离，此时配置最为简单，支持读写分离，主从切换；
• 分表分库，对于超过 1000 万的表进行分片，最大支持 1000 亿的单表分片；
• 多租户应用，每个应用一个库，但应用程序只连接 Mycat，从而不改造程序本身，实现多租户化；
• 报表系统，借助于 Mycat 的分表能力，处理大规模报表的统计；
• 替代 Hbase，分析大数据；
• 作为海量数据实时查询的一种简单有效方案，比如 100 亿条频繁查询的记录需要在 3 秒内查询出来结果。可以解决如下图中的问题：
﻿
﻿
mycat架构图﻿
﻿
NoSQLNoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的 时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储 （memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、 面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。以下为一个对比图
﻿CassandraCassandra 是一个来自 Apache 的分布式数据库，具有高度可扩展性，可用于管理大量的结构化数据。它提供了高可用性，没有单点故障（无中心），P2P协议Gossip。系统架构由亚马逊的Dynamo与Google 的BigTable两部分组成。
﻿
主要特性分布式
基于column的结构化
高伸展性
Cassandra架构
﻿
适用场景快速开发应用程序：Schema Free的特点，让Cassandra可以快速适应你的初期变更；如果你使用关系型数据库，那么就不得不从数据表、DAO层、Logic/Service层到UI层进行层层变更，哪怕只是一个小小的列名或字段类型变化；
大量写入、统计和分析：Cassandra的列族设计是囊括数据关联和排序的，并且可以不存储不需要的数据，这极大减省了表联接和冗余字段带来的性能开销，后者恰恰是高并发写入操作、统计分析时关系型数据库的瓶颈；
需要扩展的部署结构：Cassandra是面向分布式的设计，这让它可以灵活地水平扩展，以在运维阶段满足你的需求，而不必考虑“将数据迁往更高性能的服务器”这样的问题。
﻿
Cassandra以投票的方式的方式达到最终一致性（弱一致性），成功写入后，读取的并不一定是最新数据，但过一段时间（毫秒级别，跨机房时间会更长）所有副本才会达成一致。
Cassandra是最终一致性原因：优化写入性能，支持ONE、Qurum、ALL等。
Cassandra支持致性调节：当要求成功写入节点数与副本数一致时，即ALL时，认为是强一致性的。
与关系型数据库对比
﻿
HbaseHBase– Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”，是谷歌BigTable的开源实现
Hbase是一个开源的分布式的非关系的数据库，使用Java开发，它可以在集群上托管非常大的表——数十亿行×数百万列，并对这些大数据表提供随机的，实时读/写访问。Hbase运行在HDFS（Hadoop分布式文件系统）之上。
为什么需要HBase?adoop已经有了HDFS和MapReduce，为什么需要HBase?
Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于HadoopMapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求。
HDFS面向批量访问模式，不是随机访问模式。
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）。
传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间。
﻿
HBase架构
Hbase的架构由ZooKeeper,HMaster,HRegionServer,HRegion,HDFS部分组成。下面分别介绍一下各个部分的作用
ZooKeeper
通过Zoopkeeper来保证集群中只有1个master在运行，如果master异常，会通过竞争机制产生新的master提供服务
通过Zoopkeeper来监控RegionServer的状态，当RegionSevrer有异常的时候，通过回调的形式通知Master RegionServer上下限的信息
通过Zoopkeeper存储元数据的统一入口地址
HMaster
为RegionServer分配Region
维护整个集群的负载均衡
维护集群的元数据信息发现失效的Region，并将失效的Region分配到正常的RegionServer上
当RegionSever失效的时候，协调对应Hlog的拆分
HRegionServer
管理master为其分配的Region
处理来自客户端的读写请求负责和底层HDFS的交互，存储数据到HDFS
负责Region变大以后的拆分
负责Storefile的合并工作
HDFS
HDFS为Hbase提供最终的底层数据存储服务，同时为Hbase提供高可用（Hlog存储在HDFS）的支持
提供元数据和表数据的底层分布式存储服务数据多副本
保证的高可靠和高可用性
﻿
与Cassandra对比
﻿
ZooKeeper﻿
分布式系统脑裂在一个分布式系统中，不同服务器获得了互相冲突的数据信息或执行指令，导致整个集群陷入混乱，数据损坏，称作分布式系统脑裂。
﻿
为什么用zookeeper？首先，把各个节点比作各种小动物，那协调者，就是动物园管理员，这也就是Zookeeper名称的由来。
我们搭建了一个数据库集群，里面有一个Master，多个Slave，Master负责写，Slave只读，我们需要一个系统，来告诉客户端，哪个是Master，如果用java的Map实现一个映射关系，会有单点问题，而zookeeper用了n+1/2的选举方式，选出master（leader）来进行协调，这样看似单机，其实是一个集群。满足CAP定理中的CP，因而广泛使用。
很多中间件，比如Kafka、Hadoop、HBase，都用到了 Zookeeper，它作为一个分布式协调系统，能够提供数据强一致性，但是其实背后是多台机器构成的集群，不会有单点故障。
﻿
定义ZooKeeper是一个集中服务，用于维护配置信息、命名、提供分布式同步和提供组服务。
在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议（Zookeeper Atomic Broadcast（Zookeeper 原子广播协议））。
﻿
分布式一致性算法Paxos
在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。
﻿
三个角色leader:领导者
follower:追随者
observer:观察者,观察者和追随者功能一样,但是区别在于观察者不会参与投票环节
﻿
zab协议ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复和原子广播协议，Zookeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间 的数据一致性。
﻿
崩溃恢复模式：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。
消息广播模式：当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，进入消息广播模式。
树状结构
znode的分类:1)临时节点-ephemeral:临时节点由某个客户端创建,如果该客户端断开了和zookeeper服务器的链接,则该临时节点就会被自动删除。注意:临时节点不能有子节点。
2)持久性节点-persistent:持久化的节点会永久存在于文件系统中,除非客户端显示的删除该节点。该节点是最常见的节点。
3)临时顺序节点-ephemeral_sequential:和临时节点拥有相同的特点,唯一的却别在于该节点名称会自动维护一个编号。
4)持久性顺序节点-persistent_sequential:和持久性节点拥有相同的特点,唯一的却别在于该节点名称会自动维护一个编号。
﻿
Zookeeper的运用场景﻿
1)配置文件统一管理-根据watcher的监听机制来实现。
2)集群管理——根据临时目录节点，有机器挂掉该目录节点删除，其它机器收到通知，加入类似
3)分布式锁
4) 命名服务 -创建一个目录，唯一的path。通过约定好的path互相发现。
﻿
zookeeper架构
﻿
随着互联网的发展，分布式系统已经热火朝天，其构成的基本理论CAP和BASE也大放光彩，几乎所有的分布式技术都会划分到CAP定理中，互联网技术的发展也是一个”分久必合合久必分“的过程，中间用新的技术（基于CAP或BASE实现）慢慢把它们糅合了一起，对外提供高可用性，高性能的服务。
﻿
reference
https://blog.csdn.net/mao_2110901055/java/article/details/72723739
https://www.jianshu.com/p/53864dc3f7b4http://www.mycat.org.cn/https://zhuanlan.zhihu.com/p/64702090
﻿