- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章聊聊分布式数据库的 Sharding,你了解吗?由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
最近我们团队的D-SMART在做蚂蚁的OCEANBASE的适配,因此又把OB的资料拿出来,重新做研究。要想让D-SMART纳管OCEANBASE,不像一些传统的监控软件那么简单,只要把一些关键指标接入进来,搞几个基线模板就可以做做简单的报警了。必须对OB的基本原理、配置信息、运维要点、常见故障、巡检要点等做大量的归纳总结,并找到一些实际的用户,进行大量的测试,才能完成初步的适配,随后不断积累运维经验,才能让这个工具的能力越来越强。这也是做数据库的智能运维工具的不易之处。要重新学习OB,所以近期我会和大家分享一些我学习OB的心得.
。
研究OB数据库,我们首先需要从这张OB架构图上开始分析。上面这张三个ZONE的OB架构图来自于OB的官方手册。从这张图上来看,OB除了总控服务(Root Service)是主备模式,采用一主N备的模式,其他的组件都可以看成是分布式去中心化的。其SQL引擎、事务引擎、存储引擎是采用分区分片的方式的。每个OBSERVER都包含一个SQL引擎,一个事务引擎、一个存储引擎和一组数据分区.
这种SHARDING架构的数据库系统十分适合高并发的小型交易,其中最为典型的就是支付宝业务。因为可以根据用户的ID,将大并发量的用户通过算法分散到各个对等的OBSERVER上去,通过扩展OBSERVER的数量就可以横向扩展OB的并发处理能力.
OB的ZONE具备远程部署能力,因此OB原生态具有支持同城双活的能力,可以将不同的ZONE部署在不同的数据中心里。OB的数据是采用多副本的,在每个ZONE里存储一份,并通过PAXOS分布式选举算法选举LEADER。OB的数据副本粒度可以到分区级.
SHARE NOTHING架构的分布式数据库一般被称为MPP数据库,集群上不共享任何数据,因此这种架构很容易横向扩展。作为MPP分布式数据库的设计理念,主要在高可用(采用多副本存储数据,单点故障不影响数据库)、可横向扩展(因为采用SHARE NOTHING,因此不存在缓冲区融合的问题,增加节点就可以增加处理能力)、使用简单(自动分库分表、自动数据路由,研发人员比较容易掌握)、运维方便等.
高可用这条毋庸置疑,比如OB这种架构,一份数据会在多个ZONE里有多个副本存储,甚至有的ZONE还可以位于远程或者异地,可用性方面是绝对没有问题的。不过OB这种靠一套数据库实现同城双活的方案,对于一般的系统来说可能够用了,不过对于一些可靠性要求十分高的系统来说,也是不够的。虽然ZONE可以跨数据中心,但是数据库本身也是一个单点,一旦整个数据库出问题了,那么业务也就中断了。使用可跨数据中心的分布式数据库之后,还需要不需要再搞高可用,还是只依赖于单一数据库的高可用,这一点就仁者见仁智者见智了.
可横向扩展也是没问题的,现在的网络能力下,SHARE NOTHING集群可以很方便的扩展到数十个甚至数百个。可以构建十分庞大的数据库集群。这是MPP数据库的优势所在。不过对于大多数传统架构的业务系统来说,大集群的MPP所提供的处理能力不一定是必须的,有可能一台2路服务器就已经远远超出你的业务处理能力的需求了,这时候选择MPP数据库的目的应该就不是横向扩展了。在我遇到的很多用户的应用场景中,选择具有横向扩展能力的架构实际上是一个伪命题.
运维方便这一点目前来看要从两个方面来看,对于日常运维来说,如果不出一些特别的问题,那么MPP分布式数据库总体来说运维还是比较简单的,日常运维主要看看SQL优化就可以了,因为高可用架构屏蔽了大量的硬件单点故障带来的系统问题,因此日常运维的压力是会得到缓解的。如果出现一些大一点的问题,那么运维人员也是无能为力的,MPP数据库的复杂性决定了,一旦出问题,很可能数据库原厂都不一定能很快搞定,因此故障处理的主力就是原厂了。从这一点上来讲,使用MPP数据库,运维人员的压力会比较小.
使用简单这一点,是MPP数据库最令客户喜欢的一点,不过这一点上往往争议也最大。实际上分布式数据库的最早雏形是互联网企业的分库分表,这方面在世纪之初我们在给运营商做优化的时候也大量的使用。把一个数据库按照业务分拆成多个,无法分拆的库做复制,进行读写分离处理,从而让已经达到纵向扩展极限的系统能够分拆负载,这个方法被称为分库.
对于开发人员来说,分库还是比较容易实现的,只要开发厂家的水平不是太差,分库后的聚合计算方面的研发能力稍微好一点,分库还是比较容易实现的,因为分库是按照业务去分的,大部分的计算都会集中在库里,只有少量的计算才需要跨库的聚合计算。不过我也遇到过很极端的情况,一个数据库被分为6个小库后,开发人员不愿意自己程序里实现聚合计算,只能创建OGG复制链路,把部分分出去的数据再复制回来。这套系统上线不到半年,这种OGG复制链路已经有好几十条了。对于MPP数据库来说,分库就更为简单了,SQL引擎可以自动实现跨库的表连接,开发人员也就不需要再去复制表数据了.
MPP架构应用的另外一种模式是分表,当分库已经不能满足要求的时候,就需要分表了。可能大家刚开始的时候觉得分表不就是比分库分的更细一点吗,既然分库没问题,那么分表也不应有有问题了.
实际上并不是这样的,分表有两种形式,一种是把一个库里的多张表分不到不同的OBSERVER中去,一种是把一张表分为多个片,存储到不同的OBSERVER中去。第一种分表对于应用开发来说还比较好办,MPP数据库的SQL引擎会做聚合计算,因此对于开发来说并没有什么不同。有差异的是性能,跨多个OBSERVER的聚合查询的性能和单机数据库比,在很多方面都是存在差异的,这和分布式数据库的优化器和执行器的水平有很大的关系。跨库数据的聚合计算肯定会比单机有更多的延时,这些延时主要是在网络上的。不过这些都不是最主要的因素,最主要的是算子下推的操作。分布式数据库的算子下推可以利用并行执行的优势来加速,不过算子下推的粒度和能力,在不同的数据库厂商实现方面存在技术差距,这一点往往需要经过严格的对比才能看得出来.
分片是一个更复杂的问题,我们要把一张表分成多个片段分布到多个OBSERVER中去,那么我们必须要按照某个SHARDING KEY来分表。如果分表后,我们对这张表的查询语句上都带有这个SHARDING KEY的过滤条件,那么优化器在分解执行算子的时候,可以很方便的进行分区裁剪,从而降低执行成本。如果我们的SQL中不带SHARDING KEY过滤条件,那么这条SQL就会分布到所有的这张表所在的OBSERVER上去执行,这样可能会放大SQL执行的资源消耗,也会影响SQL的执行效率.
分库分表另外一个对性能影响较大的因素是多表关联查询方面的性能问题。比如某个表的某个分片在OBS1上,而关联表的分区在OBS2上,那么这个分布式关联操作的性能就不如二者都存放在OBS1上了。OB数据库引入了一个表组(table group)的逻辑结构。设置为同一个table group的多张表具有相同或者像类似的分区策略,其关联操作也比较多,这样可以确保这类业务的性能不会有太大的下降.
实际上我们还经常遇到一个问题就是一张分区的大表经常需要和一些小表进行关联,有些数据库也支持将一些小表复制到多个数据库分片中,从而提高这些关联操作的性能.
在很多分布式数据库的设计之初,数据库研发人员是希望分布式数据库能够很方便的让人使用,而实际上分布式数据库和集中式数据库在架构上的不同决定了,用好分布式数据库肯定需要有更高水平的设计,利用分布式数据库的特性,做精心的设计,尽可能避免分布式数据库中的那些坑,才能把应用做的更好。如果我们的数据库厂商总是避开这些不谈,等用户在他们的数据库上开发出了不那么令人满意的系统来,那时候再去说用户不会用分布式数据库,那就不够地道了.
原文地址:https://mp.weixin.qq.com/s/r-jn_Lfg91lq1CanVr7tVw 。
最后此篇关于聊聊分布式数据库的 Sharding,你了解吗?的文章就讲到这里了,如果你想了解更多关于聊聊分布式数据库的 Sharding,你了解吗?的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
1、SQL解析 当Sharding-JDBC接受到一条SQL语句时,会陆续执行 SQL解析 => 查询优化 => SQL路由 => SQL改写 => SQL执行 =>结
1、读写分离简介 对于同一时刻有大量并发读操作和较少写操作类型的应用系统来说,将数据库拆分为主库和从库,主库负责处理事务性的增删改操作,从库负责处理查询操作,能够有效的避免由数据更新导致的行锁,使得
将从各个数据节点获取的多数据结果集,组合成为一个结果集并正确的返回至请求客户端,称为结果归并。也是Sharding 执行过程 SQL解析 => 执行器优化 => SQL路由 => S
ShardingSphere采用一套自动化的执行引擎,负责将路由和改写完成之后的真实SQL安全且高效发送到底层数据源执行。 它不是简单地将SQL通过JDBC直接发送至数据源执行;也并非直接将执行请求放
Sharding-jdbc 官方文档讲的不是很全面和清楚,学习的时候特意再记录补充下 官方文档地址:http://shardingsphere.apache.org/index_zh.html 一
1.详细报错信息: Caused by: org.apache.ibatis.exceptions.PersistenceException: ## Error updating database.
I'm building a niche social media DB on planetscale that spans users living in multiple countries
在 keras/tensorflow 中训练模型时: 代码片段: strategy = tf.distribute.experimental.MultiWorkerMirroredStrategy()
背景:之前的项目做读写分离的时候用的 MybatisPlus的动态数据做的,很多地方使用的@DS直接指定的读库或者写库实现的业务;随着表数据量越来越大,现在打算把比较大的表进行水平拆分,准备使用
基础分库 以下实例基于shardingsphere 4.1.0 + SpringBoot 2.2.5.RELEASE版本 依赖导入: UTF-8 UTF-8 2.2.5.RE
我有兴趣在多个服务器上分割我的网站用户数据。 例如,用户将从同一位置登录。但登录脚本需要弄清楚用户数据驻留在哪个服务器上。因此,登录脚本将在主注册表中查询该用户名,并且可能会返回该用户名位于服务器 B
最近我们团队的D-SMART在做蚂蚁的OCEANBASE的适配,因此又把OB的资料拿出来,重新做研究。要想让D-SMART纳管OCEANBASE,不像一些传统的监控软件那么简单,只要把一些关键指标接
本文基于shardingsphere-jdbc-core-spring-boot-starter 5.0.0,请注意不同版本的sharding-jdbc配置可能有不一样的地方,本文不一定适用于其它版本
我想在 arangoDB 中使用分片。我已经制作了协调器,如文档 2.8.5 中提到的 DBServers。但是仍然有人仍然可以详细解释它,以及我如何能够在分片前后检查查询的性能。 最佳答案 可以测试
我读到每个 kinesis 流可以有多个消费者应用程序。 http://docs.aws.amazon.com/kinesis/latest/dev/developing-consumers-with
我正在使用一个预先存在的 bash 文件为开源数据服务器(Zotero)设置一系列数据库,但我遇到了一个我不熟悉的 mysql 结构: MASTER="mysql -h localhost -P 33
我们遇到了一个生产事件,Elasticsearch 集群健康检查返回了 red 状态。健康检查报告显示 marvel-2019.06.20 有 2 个 unassigned_shards,这似乎是根本
我在分布式系统中遇到分片移动问题。 【问题】 最初每个分区负责任意数量的分片。 (这个数字可以是任意的,因为系统支持将分片从一个分区移动到另一个分区) 然后一个新的分区来了,系统需要重新分片。目标是使
Sharding-JDBC中的分片策略有两个维度,分别是: 数据源分片策略(DatabaseShardingStrategy) 表分片策略(TableShardingStrategy)
1、Sharding 的应用场景一般都那些? 当数据库中的数据量越来越大时,不论是读还是写,压力都会变得越来越大。试想,如果一张表中的数据量达到了千万甚至上亿级别的时候,不管是建索引,优化缓存等,
我是一名优秀的程序员,十分优秀!