如何查询一个网站的icp,大连seo顾问,杭州网站设计手机,营销型网站管理方案蚂蚁集团自研数据库OceanBase已经开源#xff0c;这对国产分布式数据库来说#xff0c;是一个重磅消息。一直以来OceanBase作为商业数据库#xff0c;披露的技术细节并不多,以后又多了一个可以拿来研究的优秀分布式数据库。参考1[1]根据官网描述#xff0c;在5月20日国际事… 蚂蚁集团自研数据库OceanBase已经开源这对国产分布式数据库来说是一个重磅消息。一直以来OceanBase作为商业数据库披露的技术细节并不多,以后又多了一个可以拿来研究的优秀分布式数据库。参考1[1]根据官网描述在5月20日国际事务处理性能委员会(TPCTransaction Processing Performance Council)官网发布最新的数据分析型基准测试(TPC-H)榜单中OceanBase以 1526 万 QphH 的性能总分排名 30,000 GB 第一。这意味着OceanBase 成为唯一在事务处理和数据分析两个领域测试中都获得第一的中国自研数据库。1 架构 主流的分布式数据库有两种架构PGXC和NewSql。1.1 PGXCPGXC是指PostgreSQL-XC指以PostgreSQL为内核的分布式数据库整体架构如下:PGXC架构是对传统单体数据库做了集群在集群的基础上加了协调节点协调节点具有如下作用客户端接入进程管理分布式事务管理查询处理同时还增加了分片管理和全局时钟。分片管理用来管理集群的分片信息全局时钟的介绍见下一节。虽然PGXC名字的由来是PostgreSQL组成的分布式数据库但是使用其他单体数据库组成的分布式数据库也可以理解为PGXC比如Golden使用的就是mysql作为内核。1.2 NewSQL跟PGXC采用传统单体数据库为内核相比NewSQL是在NoSQL基于分布式键值存储系统的基础上构建了分布式事务处理能力。架构如下图此外NewSQL还有两个改进对于HA放弃传统数据库的主从复制使用Paxos、Raft等共识算法来保证多副本的一致性。对于存储使用LSM树模型替换B树写入性能更高。2 全局时钟 2.1 线程一致性线性一致性(Linearizability)是分布式系统中最强的一致性模型总体思想是保证读取多个不同副本的客户端跟读取同一个副本读到的结果一样即整个系统看起来像只有一个副本。先看两个不符合线性一致性的示例。2.1.1 同一个客户端如下图client1第一次读取了x的值是0第二次读取时以为client3修改了x的值所以读到了新的值1但是第三次读取时因为读到了别的副本因为这个副本还没有同步完成所以读到了旧的值0。2.1.2 不同客户端如下图client1第一次读取了x的值是0第二次读取时因为client3修改了x的值所以读到了新的值1但是在client1第二次读取之后client2来读取x的值因为读到了别的副本因为这个副本还没有同步完成所以读到了旧的值0。线性一致性要求任何一个客户端读取返回新值后后面所有客户端(包括相同客户端和不同客户端)读取也必须返回新值下面这个图就是线性一致性的2.2 全局时钟从上面的描述可以看到线性一致性是建立在事件的先后顺序之上的。所有操作必须记录在一条时间线上任意两个事件都有先后顺序。但是集群中各个节点都有各自的时间线怎么实现时间上的顺序性呢。这时就需要一个全局的绝对时间就是这里讲的全局时钟。一般来说从一台时间服务器获取时间就可以实现全局时钟但是必须保证高可用。下面介绍几种全局时钟的实现方式2.2.1 TrueTimeGoogle Spanner采用GPS加原子钟来分配时间支持多点授时机制。有两个明显的优势多点授时去中心化实现了高可靠。支持全球化部署这样可以减少客户端和时间服务器的通信时长。但是也存在一些问题采用物理时钟可以出现时钟偏移和时钟回拨。多点授时可能出现系统整体的时间误差。从Spanner的介绍看时间误差在7毫秒以内。2.2.2 混合逻辑时钟(HLC)HLC(Hybrid Logical Clock)因为Truetime依赖于硬件设备来实现实现难度大所以有的数据库采用了混合逻辑时钟即物理时钟和逻辑时钟配合使用同样采多时间源、多点授时所以也会有系统整体的时间误差问题。2.2.3 Timestamp Oracle简称TSO中心化授时方案采用单时间源、单点授时实现全局时钟用一个全局唯一的时间戳作为xid(全局事务id)。优点实现简单单时间源单调递增可以减少事务冲突缺点也很明显单点授时性能会有瓶颈不适合大规模集群部署目前TiDB、OceanBase都使用了这个方案。2.2.4 总结Spanner需要借助物理设备来实现对其他开源数据库的参考价值并不大。其他无论采用HLC还是TSO都有各自的优缺点。还有一种介于两者之间的授时方案单时间源多点授时使用比较少。3 HTAP HTAP英文全称是 Hybrid Transaction and Analytical Processing即混合事务和分析处理能够将事务处理(OLTP)和数据分析(OLAP)请求在同一个数据库系统中完成。HTAP需要在计算和存储两个层面支持OLTP和OLAP存储是基础。OLTP通常使用行式存储OLAP则一般使用列式存储差异很大。HTAP解决这个差异的方式有两种Google Spanner的PAX一种新的融合性存储即在行存储的基础上融合列存储的特点。TiDB的思路借助Raft协议在OLTP与OLAP之间异步复制数据通过OLAP的特殊设计来弥补异步带来的数据不一致。OceanBase采用独创的分布式计算引擎能让系统中多个计算节点同时运行OLTP类型的应用和OLAP类型的应用实现了用一套计算引擎同时支持混合负载的能力。4 RANGE动态分区 下图有4条数据如果按照HASH进行分片一般会选择id作为key进行HASH计算之后根据计算结果把数据分配到不同的分片中。这样做的好处是实现简单但也存在两个问题分片不具备业务属性可能会存在业务热点访问的问题。分片规模变化时迁移数据问题。Range分片技术跟HASH相比很大的不同是数据并没有被打散。比如上表中我们可以把数据按照城市进行分片这样数据读取效率会更高。Range动态分区用在NewSQL架构的分布式数据库中一般具有下面的特性4.1 自动合并和拆分可以给分配的数据量设置阈值当某个分片的数据量超过最大阈值时可以自动拆分成2个分片当分片数据量小于最小阈值时进行分片合并。4.2 自动负载当某个分片上的热点数据较多时节点访问压力会很大系统可以自动地将这些热点数据访问调度到不同节点以均衡访问压力。4.3 减少分布式事务分布式事务的开销会远远大于本地事务分布式数据库可以把频繁参与同一个分布式事务的数据调度到同一个分片上这样就避开了分布式事务。Spanner支持4.4 就近访问在全球部署的场景下给用户分配最近节点的分片可以减少访问延时。Spanner支持4.5 高可靠分布式数据库的高可靠是分区级别的高可靠下图是OceanBase中一个Zone的架构图OceanBase基于Paxos算法来实现系统的高可用最小的粒度可以做到分区级别。集群中数据的每一个分区会被保存到所有的Zone上分区的多个副本采用Paxos协议进行日志同步。每个分区和它的副本构成一个独立的Paxos复制组其中一个分区为Leader其它分区为Follower。所有针对这个副本的写请求都会自动路由到对应的主分区上进行。主分区可以分布在不同的OBServer上这样对于不同副本的写操作也会分布到不同的数据节点上从而实现数据多点写入提高系统性能。5 percalator模型 分布式数据库是在BigTable基础上增加了分布式事务解决方案。而Percolator模型就是Google提出的构建在BigTable之上的分布式事务解决方案。参考2[2]percalator模型采用了2阶段提交的思想这里以银行汇款为例账户1给账户2汇款100元这2个账户位于不同的分区上。5.1 初始状态初始阶段假如初始时账户1上有300元账户2上有500元如下图上面表格中:前面是用时间戳表示的数据版本后面是数据值。第一列是表名第二列的低版本保存了数据第三列列保存了数据上加的锁。第四列的高版本保存了指向保存数据版本的指针比如6这个版本保存了指向了5这个版本数据的指针 6:data5。5.2 Prewrite事务管理器向两个分片发送了Prepare请求分片收到请求后为每个要修改的数据行写日志并且根据时间戳记录事务的私有版本这里的私有版本就是7这样就获得了锁其他事务就不能操作这两条数据了。如下图从第二列的数据可以看到账户1上减少了200元账户2上增加600元。从第三列可以看到账户1获得了primary lock账户2上是指向primary lock的锁指针。注意:primary lock的选择是随机的账户1和账户2都可以选择。5.3 commitcommit阶段协调节点只需要跟拥有primary lock的分片进行通信这里只需要跟账户1进行通信从而保证了commit指令的原子性。这时数据如下表可以看到账户1的primary lock已经清除了同时增加了8这个版本8这个版本的数据指向版本7。这样7、8两个版本都不是私有版本了其他事务就可以操作这条记录了。私有版本还有一个作用就是账户1提交失败后账户2可以根据私有版本进行回滚。5.4 事务结束commit成功后并没有同步清除账户2上的私有版本和锁指针而是会启动异步线程来清除异步线程清除完成后最终数据如下图可以看到最终账户2清除了锁指针和私有版本。账户2上的lock没有同步清除其他线程读取账户2时会根据primaryorder.bal查找primary lock如果发现primary lock已经清除就可以继续读取。读取的同时做一下secondary lock清理工作。6 总结 本文主要从5个方面入手讲了分布式数据库的关键知识欢迎大家批评指正。参考资料[1]参考1: https://open.oceanbase.com/[2]参考2: https://www.cs.princeton.edu/courses/archive/fall10/cos597B/papers/percolator-osdi10.pdf ·············· END ··············感谢阅读如果对你有帮助请点个再看。欢迎大家加我微信围观朋友圈做点赞之交一起进步。想要进技术交流群的朋友加我微信回复进群。
