精华内容
下载资源
问答
  • 2022-03-30 10:15:32

    ShardingSphere是一款起源于当当网内部的应用框架。2015年在当当网内部诞生,最初就叫ShardingJDBC。2016年的时候,由其中一个主要的开发人员张亮,带入到京东数科,组件团队继续开发。在国内历经了当当网、电信翼支付、京东数科等多家大型互联网企业的考验,在2017年开始开源。并逐渐由原本只关注于关系型数据库增强工具的ShardingJDBC升级成为一整套以数据分片为基础的数据生态圈,更名为ShardingSphere。到2020年4月,已经成为了Apache软件基金会的顶级项目。
    ShardingSphere包含三个重要的产品,ShardingJDBC、ShardingProxy和ShardingSidecar。其中sidecar是针对service mesh定位的一个分库分表插件,目前在规划中。

    ShardingJDBC:
    在这里插入图片描述
    shardingJDBC定位为轻量级 Java 框架,在 Java 的 JDBC 层提供的额外服务。它使⽤客户端直连数据库,以 jar 包形式提供服务,⽆需额外部署和依赖,可理解为增强版的 JDBC 驱动,完全兼容 JDBC 和各种 ORM 框架。

    ShardingProxy:
    在这里插入图片描述
    ShardingProxy定位为透明化的数据库代理端,提供封装了数据库⼆进制协议的服务端版本,⽤于完成对异构语⾔的⽀持。⽬前提供 MySQL 和 PostgreSQL 版本,它可以使⽤任何兼容 MySQL/PostgreSQL 协议的访问客⼾端
    在这里插入图片描述
    ShardingJDBC只是客户端的一个工具包,可以理解为一个特殊的JDBC驱动包,所有分库分表逻辑均由业务方自己控制,所以他的功能相对灵活,支持的数据库也非常多,但是对业务侵入大,需要业务方自己定制所有的分库分表逻辑。而ShardingProxy是一个独立部署的服务,对业务方无侵入,业务方可以像用一个普通的MySQL服务一样进行数据交互,基本上感觉不到后端分库分表逻辑的存在,但是这也意味着功能会比较固定,能够支持的数据库也比较少。这两者各有优劣。

    ShardingJDBC核心概念:
    逻辑表:水平拆分的数据库的相同逻辑和数据结构表的总称
    真实表:在分片的数据库中真实存在的物理表。
    数据节点:数据分片的最小单元。由数据源名称和数据表组成
    绑定表:分片规则一致的主表和子表。
    广播表:也叫公共表,指素有的分片数据源中都存在的表,表结构和表中的数据在每个数据库中都完全一致。例如字典表。
    分片键:用于分片的数据库字段,是将数据库(表)进行水平拆分的关键字段。
    SQL中若没有分片字段,将会执行全路由,性能会很差。
    分片算法:通过分片算法将数据进行分片,支持通过=、BETWEEN和IN分片。
    分片算法需要由应用开发者自行实现,可实现的灵活度非常高。
    分片策略:真正用于进行分片操作的是分片键+分片算法,也就是分片策略。在ShardingJDBC中一般采用基于Groovy表达式的inline分片策略,通过一个包含分片键的算法表达式来制定分片策略,如t_user_$->{u_id%8}标识根据u_id模8,分成8张表,表名称为t_user_0到t_user_7。

    application.properties配置文件

    #垂直分表策略
    # 配置真实数据源
    spring.shardingsphere.datasource.names=m1
    # 配置第 1 个数据源
    spring.shardingsphere.datasource.m1.type=com.alibaba.druid.pool.DruidDataSource
    spring.shardingsphere.datasource.m1.driver-class-name=com.mysql.cj.jdbc.Driver
    spring.shardingsphere.datasource.m1.url=jdbc:mysql://localhost:3306/coursedb?serverTimezone=GMT%2B8
    spring.shardingsphere.datasource.m1.username=root
    spring.shardingsphere.datasource.m1.password=root
    # 指定表的分布情况 配置表在哪个数据库里,表名是什么。水平分表,分两个表:m1.course_1,m1.course_2
    spring.shardingsphere.sharding.tables.course.actual-data-nodes=m1.course_$->{1..2}
    # 指定表的主键生成策略
    spring.shardingsphere.sharding.tables.course.key-generator.column=cid
    spring.shardingsphere.sharding.tables.course.key-generator.type=SNOWFLAKE
    #雪花算法的一个可选参数
    spring.shardingsphere.sharding.tables.course.key-generator.props.worker.id=1
    #使用自定义的主键生成策略
    #spring.shardingsphere.sharding.tables.course.key-generator.type=MYKEY
    #spring.shardingsphere.sharding.tables.course.key-generator.props.mykey-offset=88
    #指定分片策略 约定cid值为偶数添加到course_1表。如果是奇数添加到course_2表。
    # 选定计算的字段
    spring.shardingsphere.sharding.tables.course.table-strategy.inline.sharding-column= cid
    # 根据计算的字段算出对应的表名。
    spring.shardingsphere.sharding.tables.course.table-strategy.inline.algorithm-expression=course_$->{cid%2+1}
    # 打开sql日志输出。
    spring.shardingsphere.props.sql.show=true
    spring.main.allow-bean-definition-overriding=true
    

    1、首先定义一个数据源m1,并对m1进行实际的JDBC参数配置
    2、spring.shardingsphere.sharding.tables.course开头的一系列属性即定义了一个名为course的逻辑表。
    actual-data-nodes属性即定义course逻辑表的实际数据分布情况,他分布在m1.course_1和m1.course_2两个表。
    key-generator属性配置了他的主键列以及主键生成策略。
    ShardingJDBC默认提供了UUID和SNOWFLAKE两种分布式主键生成策略。
    table-strategy属性即配置他的分库分表策略。分片键为cid属性。分片算法为course_$->{cid%2+1},表示按照cid模2+1的结果,然后加上前面的course__ 部分作为前缀就是他的实际表结果。注意,这个表达式计算出来的结果需要能够与实际数据分布中的一种情况对应上,否则就会报错。sql.show属性表示要在日志中打印实际SQL
    3、coursedb的表结构见示例中sql文件夹中的sql语句。

    ShardingJDBC的分片算法
    ShardingJDBC的整个实战完成后,可以看到,整个分库分表的核心就是在于配置的分片算法。我们的这些实战都是使用的inline分片算法,即提供一个分片键和一个分片表达式来制定分片算法。这种方式配置简单,功能灵活,是分库分表最佳的配置方式,并且对于绝大多数的分库分片场景来说,都已经非常好用了。但是,如果针对一些更为复杂的分片策略,例如多分片键、按范围分片等场景,inline分片算法就有点力不从心了。所以,我们还需要学习下ShardingSphere提供的其他几种分片策略。

    ShardingSphere目前提供了一共五种分片策略:
    NoneShardingStrategy
    不分片。这种严格来说不算是一种分片策略了。只是ShardingSphere也提供了这么一个配置。

    InlineShardingStrategy
    最常用的分片方式
    配置参数: inline.shardingColumn 分片键;inline.algorithmExpression分片表达式
    实现方式: 按照分片表达式来进行分片。

    StandardShardingStrategy
    只支持单分片键的标准分片策略。
    配置参数:standard.sharding-column 分片键;standard.precise-algorithm-class-name 精确分片算法类名;standard.range-algorithm-class-name 范围分片算法类名
    实现方式:
    shardingColumn指定分片算法。
    preciseAlgorithmClassName 指向一个实现io.shardingsphere.api.algorithm.sharding.standard.PreciseShardingAl
    gorithm接口的java类名,提供按照 = 或者 IN 逻辑的精确分片 示例:
    com.roy.shardingDemo.algorithm.MyPreciseShardingAlgorithmrangeAlgorithmClassName 指向一个实现了
    io.shardingsphere.api.algorithm.sharding.standard.RangeShardingAlgorithm接口的java类名,提供按照Between 条件进行的范围分片。示例:
    com.roy.shardingDemo.algorithm.MyRangeShardingAlgorithm
    说明:
    其中精确分片算法是必须提供的,而范围分片算法则是可选的。

    ComplexShardingStrategy
    支持多分片键的复杂分片策略。
    配置参数:complex.sharding-columns 分片键(多个);
    complex.algorithm-class-name 分片算法实现类。
    实现方式:
    shardingColumn指定多个分片列。
    algorithmClassName指向一个实现了org.apache.shardingsphere.api.sharding.complex.ComplexKeysShardi
    ngAlgorithm接口的java类名。提供按照多个分片列进行综合分片的算法。
    示例:
    com.roy.shardingDemo.algorithm.MyComplexKeysShardingAlgorithm

    HintShardingStrategy
    不需要分片键的强制分片策略。这个分片策略,简单来理解就是说,他的分片键不再跟SQL语句相关联,而是用程序另行指定。对于一些复杂的情况,例如select count(*) from (select userid from t_user where userid in (1,3,5,7,9))这样的SQL语句,就没法通过SQL语句来指定一个分片键。这个时候就可以通过程序,给他另行执行一个分片键,例如在按userid奇偶分片的策略下,可以指定1作为分片键,然后自行指定他的分片策略。
    配置参数:hint.algorithm-class-name 分片算法实现类。
    实现方式:
    algorithmClassName指向一个实现了org.apache.shardingsphere.api.sharding.hint.HintShardingAlgorithm
    接口的java类名。 示例:
    com.roy.shardingDemo.algorithm.MyHintShardingAlgorithm在这个算法类中,同样是需要分片键的。而分片键的指定是通过HintManager.addDatabaseShardingValue方法(分库)和HintManager.addTableShardingValue(分表)来指定。使用时要注意,这个分片键是线程隔离的,只在当前线程有效,所以通常建议使用之后立即关闭,或者用try资源方式打开。

    ShardingSphere的SQL使用限制
    支持的SQL SQL 必要条件
    SELECT * FROM tbl_name
    SELECT * FROM tbl_name WHERE (col1 = ? or col2 = ?) and col3 = ?
    SELECT * FROM tbl_name WHERE col1 = ? ORDER BY col2 DESC LIMIT ?
    SELECT COUNT(*), SUM(col1), MIN(col1), MAX(col1), AVG(col1) FROM tbl_name WHERE col1 = ?
    SELECT COUNT(col1) FROM tbl_name WHERE col2 = ? GROUP BY col1 ORDER BY col3 DESC LIMIT ?, ?
    INSERT INTO tbl_name (col1, col2,…) VALUES (?, ?, ….)
    INSERT INTO tbl_name VALUES (?, ?,….)
    INSERT INTO tbl_name (col1, col2, …) VALUES (?, ?, ….),(?, ?, ….)
    INSERT INTO tbl_name (col1, col2, …) SELECT col1,col2, … FROM tbl_name WHERE col3 = ?
    REPLACE INTO tbl_name (col1, col2, …) SELECT col1,col2, … FROM tbl_name WHERE col3 = ?
    UPDATE tbl_name SET col1 = ? WHERE col2 = ?
    DELETE FROM tbl_name WHERE col1 = ?
    CREATE TABLE tbl_name (col1 int, …)
    ALTER TABLE tbl_name ADD col1 varchar(10)
    DROP TABLE tbl_name
    TRUNCATE TABLE tbl_name
    CREATE INDEX idx_name ON tbl_name
    DROP INDEX idx_name ON tbl_name
    DROP INDEX idx_name
    SELECT DISTINCT * FROM tbl_name WHERE col1 = ?
    SELECT COUNT(DISTINCT col1) FROM tbl_name
    SELECT subquery_alias.col1 FROM (selecttbl_name.col1 from tbl_name where tbl_name.col2=?)
    subquery_alias

    不支持的SQL
    INSERT INTO tbl_name (col1, col2, …) VALUES(1+2, ?, …)
    VALUES语句不支持运算表达式
    INSERT INTO tbl_name (col1, col2, …) SELECT * FROM tbl_name WHERE col3= ?
    SELECT子句暂不支持使用号简写及内置的分布式主键生成器
    REPLACE INTO tbl_name (col1, col2, …) SELECT * FROM tbl_name WHERE col3= ?
    SELECT子句暂不支持使用
    号简写及内置的分布式主键生成器
    SELECT * FROM tbl_name1 UNION SELECT * FROM tbl_name2
    UNION
    SELECT * FROM tbl_name1 UNION ALL SELECT * FROM tbl_name2
    UNION ALL

    分库分表带来的问题
    1、分库分表,其实围绕的都是一个核心问题,就是单机数据库容量的问题。我们要了解,在面对这个问题时,解决方案是很多的,并不止分库分表这一种。但是ShardingSphere的这种分库分表,是希望在软件层面对硬件资源进行管理,从而便于对数据库的横向扩展,这无疑是成本很小的一种方式。

    2、一般情况下,如果单机数据库容量撑不住了,应先从缓存技术着手降低对数据库的访问压力。如果缓存使用过后,数据库访问量还是非常大,可以考虑数据库读写分离策略。如果数据库压力依然非常大,且业务数据持续增长无法估量,最后才考虑分库分表,单表拆分数据应控制在1000万以内。当然,随着互联网技术的不断发展,处理海量数据的选择也越来越多。在实际进行系统设计时,最好是用MySQL数据库只用来存储关系性较强的热点数据,而对海量数据采取另外的一些分布式存储产品。例如PostGreSQL、VoltDB甚至HBase、Hive、ES等这些大数据组件来存储。
    3、从上一部分ShardingJDBC的分片算法中我们可以看到,由于SQL语句的功能实在太多太全面了,所以分库分表后,对SQL语句的支持,其实是步步为艰的,稍不小心,就会造成SQL语句不支持、业务数据混乱等很多很多问题。所以,实际使用时,我们会建议这个分库分表,能不用就尽量不要用。如果要使用优先在OLTP场景下使用,优先解决大量数据下的查询速度问题。而在OLAP场景中,通常涉及到非常多复杂的SQL,分库分表的限制就会更加明显。当然,这也是ShardingSphere以后改进的一个方向。
    4、如果确定要使用分库分表,就应该在系统设计之初开始对业务数据的耦合程度和使用情况进行考量,尽量控制业务SQL语句的使用范围,将数据库往简单的增删改查的数据存储层方向进行弱化。并首先详细规划垂直拆分的策略,使数据层架构清晰明了。而至于水平拆分,会给后期带来非常非常多的数据问题,所以应该谨慎、谨慎再谨慎。一般也就在日志表、操作记录表等很少的一些边缘场景才偶尔用用。

    更多相关内容
  • 功能: 通过配置文件以及sql模板文件自动生成 分库分表,单库分表的sql脚本 最新更新: 1、支持分库不分表的脚本生成 2、修正重复索引报错问题
  • 数据库分库分表中间件实践,降低单机负载 降低单点故障带来的影响 提高读写的性能
  • 更多内容关注微信公众号:fullstack888一、数据库瓶颈1、IO瓶颈2、CPU瓶颈二、分库分表1、水平分库2、水平分表3、垂直分库4、垂直分表三、分库分表工具四、分库分表步骤五、分库分表问题1、非partition key的查询...

    更多内容关注微信公众号:fullstack888

    一、数据库瓶颈

        1、IO瓶颈

        2、CPU瓶颈

    二、分库分表

        1、水平分库

        2、水平分表

        3、垂直分库

        4、垂直分表

    三、分库分表工具

    四、分库分表步骤

    五、分库分表问题

        1、非partition key的查询问题(水平分库分表,拆分策略为常用的hash法)

        2、非partition key跨库跨表分页查询问题(水平分库分表,拆分策略为常用的hash法)

        3、扩容问题(水平分库分表,拆分策略为常用的hash法)

    六、分库分表总结

    七、分库分表示例

    一、数据库瓶颈

    不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。

    1、IO瓶颈

    第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 ->  分库和垂直分表。

    第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 ->  分库。

    2、CPU瓶颈

    第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。

    第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 ->  水平分表。

    二、分库分表

    1、水平分库

    88d4545d38c044421af7d4ee03174536.png

    1. 概念:以 字段为依据 ,按照一定策略(hash、range等),将一个 库中的数据拆分到多个 库中。

    2. 结果:

    • 每个 库的 结构都一样;

    • 每个 库的 数据都不一样,没有交集;

    • 所有 库的 并集是全量数据;

    场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。

    分析:库多了,io和cpu的压力自然可以成倍缓解。

    2、水平分表

    fce9ed076dee75ac8e418e1e8a8c10f4.png

    1. 概念:以 字段为依据 ,按照一定策略(hash、range等),将一个 表中的数据拆分到多个 表中。

    2. 结果:

    • 每个 表的 结构都一样;

    • 每个 表的 数据都不一样,没有交集;

    • 所有 表的 并集是全量数据;

    场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。

    分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。

    3、垂直分库

    05716aec4ee724a095a7ea8e377502de.png

    1. 概念:以 表为依据,按照业务归属不同,将不同的 表拆分到不同的 库中 。

    2. 结果:

    • 每个 库的 结构都不一样;

    • 每个 库的 数据也不一样,没有交集;

    • 所有 库的 并集是全量数据;

    场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。

    分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。

    4、垂直分表

    c27d79529c75eaec3d7b0611ddd3d8aa.png

    1. 概念:以 字段为依据,按照字段的活跃性,将 表中字段拆到不同的 表(主表和扩展表)中。

    2. 结果:

    • 每个 表的 结构都不一样;

    • 每个 表的 数据也不一样,一般来说,每个表的 字段至少有一列交集,一般是主键,用于关联数据;

    • 所有 表的 并集是全量数据;

    场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。

    分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。但记住,千万别用join,因为join不仅会增加CPU负担并且会将两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

    三、分库分表工具

    1. sharding-sphere:jar,前身是sharding-jdbc;

    2. TDDL:jar,Taobao Distribute Data Layer;

    3. Mycat:中间件。

    注:工具的利弊,请自行调研,官网和社区优先。

    四、分库分表步骤

    根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。

    五、分库分表问题

    1、非partition key的查询问题(水平分库分表,拆分策略为常用的hash法)

    1. 端上除了partition key只有一个非partition key作为条件查询

    • 映射法

      f66dc3651720800a67b3efb793f6b186.png

    • 基因法

      08c6922e981dad78efdb6a94ac7c21be.png

      注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,2 3=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用 snowflake算法。

    端上除了partition key不止一个非partition key作为条件查询

    • 映射法

    60b1f916f63d3940fe39b2406e72c6b0.png

    • 冗余法

      668f216aa9f61e6921ef6502d0d91f4d.png

      注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢?

    后台除了partition key还有各种非partition key组合条件查询

    • NoSQL法

      505959cd6e10b5f37df2ba44f94a3732.png

    • 冗余法

      df4f277a7950a7218c51a0d7c6a19717.png

    2、非partition key跨库跨表分页查询问题(水平分库分表,拆分策略为常用的hash法)

    注:用 NoSQL法解决(ES等)。

    3、扩容问题(水平分库分表,拆分策略为常用的hash法)

    1. 水平扩容库(升级从库法

      a0183137a470918f89487e11b2a2e28d.png

      注:扩容是成倍的。

    2. 水平扩容表(双写迁移法)
      10b58347c09723475bf30596e592fa4a.png
      第一步:(同步双写)应用配置双写,部署;
      第二步:(同步双写)将老库中的老数据复制到新库中;
      第三步:(同步双写)以老库为准校对新库中的老数据;
      第四步:(同步双写)应用去掉双写,部署;

    注: 双写是通用方案。

    总结

    垂直分表:可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表,这样既能使业务清晰,还能提升部分性能。拆分后,尽量从业务角度避免联查,否则性能方面将得不偿失。

    垂直分库:可以把多个表按业务耦合松紧归类,分别存放在不同的库,这些库可以分布在不同服务器,从而使访问压力被多服务器负载,大大提升性能,同时能提高整体架构的业务清晰度,不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。

    水平分库:可以把一个表的数据(按数据行)分到多个不同的库,每个库只有这个表的部分数据,这些库可以分布在不同服务器,从而使访问压力被多服务器负载,大大提升性能。它不仅需要解决跨库带来的所有复杂问题,还要解决数据路由的问题(数据路由问题后边介绍)。

    水平分表:可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中,每个表只有这个表的部分数据,这样做能小幅提升性能,它仅仅作为水平分库的一个补充优化。

    一般来说,在系统设计阶段就应该根据业务耦合松紧来确定垂直分库,垂直分表方案,在数据量及访问压力不是特别大的情况,首先考虑缓存、读写分离、索引技术等方案。若数据量极大,且持续增长,再考虑水平分库水平分表方案。

    - END -

    往期回顾

    java Bean映射框架:Orika

    代码重复:搞定代码重复的三个绝招

    领域驱动设计(DDD)的几种典型架构介绍(图文详解)

    程序员也可以懂一点期望值管理

    分布式缓存,就该这样设计!

    如何设计API返回码(错误码)?

    一文了解微服务的前世今生

    Linux运维超实用工具,赶紧收藏!

    LSM树(Log-Structured Merge Tree)存储引擎介绍

    设计模式和代码规范落地之路

    0706f1e2aec2f875bc60b168446fc5c7.png

    技术交流,请加微信: jiagou6688 ,备注:Java,拉你进架构群


    展开全文
  • 三、分库分表工具 sharding-sphere:jar,前身是sharding-jdbc; TDDL:jar,Taobao Distribute Data Layer; Mycat:中间件。 注:工具的利弊,请自行调研,官网和社区优先。 四、分库分表步骤 根据容量(当前容量...

    Python乱炖推荐搜索后浪

    动森玩家

    送书

    数据分析

    一、数据库瓶颈

    不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。

    1、IO瓶颈

    第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表。

    第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库。

    2、CPU瓶颈

    第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。

    第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水平分表。

    二、分库分表

    1、水平分库

    972e57f1fbff8ab6171895d4a705cda2.png

    概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。

    结果:

    每个库的结构都一样;

    每个库的数据都不一样,没有交集;

    所有库的并集是全量数据;

    场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。

    分析:库多了,io和cpu的压力自然可以成倍缓解。

    2、水平分表

    24be0dd1681c322aee42d0b81410724b.png

    概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。

    结果:

    每个表的结构都一样;

    每个表的数据都不一样,没有交集;

    所有表的并集是全量数据;

    场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。

    分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。

    3、垂直分库

    563774d6332fa4f85027ad72635340e6.png

    概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。

    结果:

    每个库的结构都不一样;

    每个库的数据也不一样,没有交集;

    所有库的并集是全量数据;

    场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。

    分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。

    4、垂直分表

    28a62d12c5d32bd53cf59f126b0736b3.png

    概念:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。

    结果:

    每个表的结构都不一样;

    每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据;

    所有表的并集是全量数据;

    场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。

    分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

    三、分库分表工具

    sharding-sphere:jar,前身是sharding-jdbc;

    TDDL:jar,Taobao Distribute Data Layer;

    Mycat:中间件。

    注:工具的利弊,请自行调研,官网和社区优先。

    四、分库分表步骤

    根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。

    五、分库分表问题

    1、非partition key的查询问题

    基于水平分库分表,拆分策略为常用的hash法。

    端上除了partition key只有一个非partition key作为条件查询

    映射法

    cbb0fee2ea5d6b1bac390694827d12dc.png

    基因法

    5d1d9388ba78c1aa6ccfc6e74976b8cd.png

    注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,23=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。

    端上除了partition key不止一个非partition key作为条件查询

    映射法

    ea04b48415208f0c49910be369aef05a.png

    冗余法

    18d30624cbd0808af67495e43edfaeea.png

    注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢?

    后台除了partition key还有各种非partition key组合条件查询

    NoSQL法

    ab8bb73af6185673593b043a2c5842a9.png

    冗余法

    6997e211ea687fb4e9cd24d2439fb3ee.png

    2、非partition key跨库跨表分页查询问题

    基于水平分库分表,拆分策略为常用的hash法。

    注:用NoSQL法解决(ES等)。

    3、扩容问题

    基于水平分库分表,拆分策略为常用的hash法。

    水平扩容库(升级从库法)

    110eeaf83c9394d25889c0c3278ae938.png

    注:扩容是成倍的。

    水平扩容表(双写迁移法)

    998c7b1bb38929e02cb57ee18277ac65.png

    第一步:(同步双写)修改应用配置和代码,加上双写,部署;

    第二步:(同步双写)将老库中的老数据复制到新库中;

    第三步:(同步双写)以老库为准校对新库中的老数据;

    第四步:(同步双写)修改应用配置和代码,去掉双写,部署;

    注:双写是通用方案。

    六、分库分表总结

    分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分(分库还是分表?水平还是垂直?分几个?)。且不可为了分库分表而拆分。

    选key很重要,既要考虑到拆分均匀,也要考虑到非partition key的查询。

    只要能满足需求,拆分规则越简单越好。

    七、分库分表示例

    来自:cnblogs.com/littlecharacter/p/9342129.html

    以上,便是今天的内容,希望大家喜欢,欢迎「转发」或者点击「在看」支持,谢谢各位。

    “扫一扫,关注我吧”

    展开全文
  • 垂直分表◆ 分库分表工具◆ 分库分表带来的问题■ 事务一致性问题■ 跨节点关联查询 Join 问题■ 跨节点分页、排序、函数问题■ 全局主键避重问题■ 数据迁移、扩容问题 当数据库的数据量过大,大到一定的程度,...

    当数据库的数据量过大,大到一定的程度,我们就可以进行分库分表。那么基于什么原则,什么方法进行拆分,这就是本篇所要讲的。

    ◆ 数据库瓶颈

    不管是 IO 瓶颈还是 CPU 瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载的活跃连接数的阈值。

    在业务 Service 来看, 就是可用数据库连接少甚至无连接可用,接下来就可以想象了(并发量、吞吐量、崩溃)。

    • IO 瓶颈:

    第一种:磁盘读 IO 瓶颈,热点数据太多,数据库缓存放不下,每次查询会产生大量的 IO,降低查询速度→分库和垂直分表。

    第二种:网络 IO 瓶颈,请求的数据太多,网络带宽不够→分库。

    - CPU 瓶颈:

    第一种:SQL 问题:如 SQL 中包含 join,group by,order by,非索引字段条件查询等,增加 CPU 运算的操作→SQL 优化,建立合适的索引,在业务 Service 层进行业务计算。

    第二种:单表数据量太大,查询时扫描的行太多,SQL 效率低,增加 CPU 运算的操作→水平分表。

    ◆分库分表

    1. 水平分库

    在这里插入图片描述
    概念: 以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。

    结果:

    每个库的结构都一样

    每个库中的数据不一样,没有交集

    所有库的数据并集是全量数据

    场景: 系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库的情况下。

    分析: 库多了,IO 和 CPU 的压力自然可以成倍缓解。

    2. 水平分表

    在这里插入图片描述
    概念: 以字段为依据,按照一定策略(hash、range 等),讲一个表中的数据拆分到多个表中。

    结果:
    每个表的结构都一样。

    每个表的数据不一样,没有交集,所有表的并集是全量数据。

    场景: 系统绝对并发量没有上来,只是单表的数据量太多,影响了 SQL 效率,加重了 CPU 负担,以至于成为瓶颈,可以考虑水平分表。

    分析: 单表的数据量少了,单次执行 SQL 执行效率高了,自然减轻了 CPU 的负担。

    3. 垂直分库

    在这里插入图片描述
    概念: 以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。

    结果:
    每个库的结构都不一样。

    每个库的数据也不一样,没有交集。

    所有库的并集是全量数据。

    场景: 系统绝对并发量上来了,并且可以抽象出单独的业务模块的情况下。

    分析: 到这一步,基本上就可以服务化了。例如:随着业务的发展,一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。

    再者,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。

    4. 垂直分表

    概念: 以字段为依据,按照字段的活跃性,将表中字段拆到不同的表中(主表和扩展表)。

    结果:
    每个表的结构不一样。

    每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据。

    所有表的并集是全量数据。

    场景: 系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大,以至于数据库缓存的数据行减少,查询时回去读磁盘数据产生大量随机读 IO,产生 IO 瓶颈。

    分析: 可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能经常会查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表,这样更多的热点数据就能被缓存下来,进而减少了随机读 IO。

    拆了之后,要想获取全部数据就需要关联两个表来取数据。但记住千万别用 Join,因为 Join 不仅会增加 CPU 负担并且会将两个表耦合在一起(必须在一个数据库实例上)。

    关联数据应该在 Service 层进行,分别获取主表和扩展表的数据,然后用关联字段关联得到全部数据。

    ◆ 分库分表工具

    常用的分库分表工具如下:

    • Sharding-JDBC(当当)
    • TSharding(蘑菇街)
    • Atlas(奇虎 360)
    • Cobar(阿里巴巴)
    • MyCAT(基于 Cobar)
    • Oceanus(58 同城)
    • Vitess(谷歌)

    各种工具的利弊自查

    ◆ 分库分表带来的问题

    分库分表能有效缓解单机和单表带来的性能瓶颈和压力,突破网络 IO、硬件资源、连接数的瓶颈,同时也带来一些问题,下面将描述这些问题和解决思路。

    ■ 事务一致性问题

    分布式事务

    当更新内容同时存在于不同库找那个,不可避免会带来跨库事务问题。跨分片事务也是分布式事务,没有简单的方案,一般可使用“XA 协议”和“两阶段提交”处理。

    分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点,推后了提交事务的时间点,延长了事务的执行时间,导致事务在访问共享资源时发生冲突或死锁的概率增高。

    随着数据库节点的增多,这种趋势会越来越严重,从而成为系统在数据库层面上水平扩展的枷锁。

    最终一致性

    对于那些性能要求很高,但对一致性要求不高的系统,往往不苛求系统的实时一致性,只要在允许的时间段内达到最终一致性即可,可采用事务补偿的方式。

    与事务在执行中发生错误立刻回滚的方式不同,事务补偿是一种事后检查补救的措施,一些常见的实现方法有:对数据进行对账检查,基于日志进行对比,定期同标准数据来源进行同步等。

    ■ 跨节点关联查询 Join 问题

    切分之前,系统中很多列表和详情表的数据可以通过 Join 来完成,但是切分之后,数据可能分布在不同的节点上,此时 Join 带来的问题就比较麻烦了,考虑到性能,尽量避免使用 Join 查询。

    解决的一些方法:

    全局表
    全局表,也可看做“数据字典表”,就是系统中所有模块都可能依赖的一些表,为了避免库 Join 查询,可以将这类表在每个数据库中都保存一份。这些数据通常很少修改,所以不必担心一致性的问题。

    字段冗余
    一种典型的反范式设计,利用空间换时间,为了性能而避免 Join 查询。

    例如,订单表在保存 userId 的时候,也将 userName 也冗余的保存一份,这样查询订单详情顺表就可以查到用户名 userName,就不用查询买家 user 表了。

    但这种方法适用场景也有限,比较适用依赖字段比较少的情况,而冗余字段的一致性也较难保证。

    数据组装
    在系统 Service 业务层面,分两次查询,第一次查询的结果集找出关联的数据 id,然后根据 id 发起器二次请求得到关联数据,最后将获得的结果进行字段组装。这是比较常用的方法。

    ER 分片
    关系型数据库中,如果已经确定了表之间的关联关系(如订单表和订单详情表),并且将那些存在关联关系的表记录存放在同一个分片上,那么就能较好地避免跨分片 Join 的问题。

    可以在一个分片内进行 Join,在 1:1 或 1:n 的情况下,通常按照主表的 ID 进行主键切分。

    ■ 跨节点分页、排序、函数问题

    跨节点多库进行查询时,会出现 limit 分页、order by 排序等问题。

    分页需要按照指定字段进行排序,当排序字段就是分页字段时,通过分片规则就比较容易定位到指定的分片;当排序字段非分片字段时,就变得比较复杂。

    需要先在不同的分片节点中将数据进行排序并返回,然后将不同分片返回的结果集进行汇总和再次排序。

    最终返回给用户如下图:
    在这里插入图片描述
    上图只是取第一页的数据,对性能影响还不是很大。但是如果取得页数很大,情况就变得复杂的多。

    因为各分片节点中的数据可能是随机的,为了排序的准确性,需要将所有节点的前N页数据都排序好做合并,最后再进行整体排序,这样的操作很耗费 CPU 和内存资源,所以页数越大,系统性能就会越差。

    在使用 Max、Min、Sum、Count 之类的函数进行计算的时候,也需要先在每个分片上执行相应的函数,然后将各个分片的结果集进行汇总再次计算。

    ■ 全局主键避重问题

    在分库分表环境中,由于表中数据同时存在不同数据库中,主键值平时使用的自增长将无用武之地,某个分区数据库自生成 ID 无法保证全局唯一。

    因此需要单独设计全局主键,避免跨库主键重复问题。这里有一些策略:

    UUID
    UUID 标准形式是 32 个 16 进制数字,分为 5 段,形式是 8-4-4-4-12 的 36 个字符。

    UUID 是最简单的方案,本地生成,性能高,没有网络耗时,但是缺点明显,占用存储空间多。

    另外作为主键建立索引和基于索引进行查询都存在性能问题,尤其是 InnoDb 引擎下,UUID 的无序性会导致索引位置频繁变动,导致分页。

    结合数据库维护主键 ID 表
    在数据库中建立 sequence 表:

    CREATE TABLE `sequence` (  
      `id` bigint(20) unsigned NOT NULL auto_increment,  
      `stub` char(1) NOT NULL default '',  
      PRIMARY KEY  (`id`),  
      UNIQUE KEY `stub` (`stub`)  
    ) ENGINE=MyISAM;
    

    stub 字段设置为唯一索引,同一 stub 值在 sequence 表中只有一条记录,可以同时为多张表生辰全局 ID。

    使用 MyISAM 引擎而不是 InnoDb,已获得更高的性能。MyISAM 使用的是表锁,对表的读写是串行的,所以不用担心并发时两次读取同一个 ID。

    当需要全局唯一的 ID 时,执行:

    REPLACE INTO sequence (stub) VALUES ('a');  
    SELECT LAST_INSERT_ID();  
    

    此方案较为简单,但缺点较为明显:存在单点问题,强依赖 DB,当 DB 异常时,整个系统不可用。配置主从可以增加可用性。另外性能瓶颈限制在单台 MySQL 的读写性能。

    另有一种主键生成策略,类似 sequence 表方案,更好的解决了单点和性能瓶颈问题。

    这一方案的整体思想是:建立 2 个以上的全局 ID 生成的服务器,每个服务器上只部署一个数据库,每个库有一张 sequence 表用于记录当前全局 ID。

    表中增长的步长是库的数量,起始值依次错开,这样就能将 ID 的生成散列到各个数据库上。在这里插入图片描述
    这种方案将生成 ID 的压力均匀分布在两台机器上,同时提供了系统容错,第一台出现了错误,可以自动切换到第二台获取 ID。

    但有几个缺点:系统添加机器,水平扩展较复杂;每次获取 ID 都要读取一次 DB,DB 的压力还是很大,只能通过堆机器来提升性能。

    Snowflake 分布式自增 ID 算法
    在这里插入图片描述Twitter 的 Snowfalke 算法解决了分布式系统生成全局 ID 的需求,生成 64 位 Long 型数字。

    组成部分如下:

    • 第一位未使用。
    • 接下来的 41 位是毫秒级时间,41 位的长度可以表示 69 年的时间。
    • 5 位 datacenterId,5 位 workerId。10 位长度最多支持部署 1024 个节点。
    • 最后 12 位是毫秒内计数,12 位的计数顺序号支持每个节点每毫秒产生 4096 个 ID 序列。

    ■ 数据迁移、扩容问题

    当业务高速发展、面临性能和存储瓶颈时,才会考虑分片设计,此时就不可避免的需要考虑历史数据的迁移问题。

    一般做法是先读出历史数据,然后按照指定的分片规则再将数据写入到各分片节点中。

    此外还需要根据当前的数据量个 QPS,以及业务发展速度,进行容量规划,推算出大概需要多少分片(一般建议单个分片的单表数据量不超过 1000W)。

    ◆ 什么时候考虑分库分表

    能不分就不分
    并不是所有表都需要切分,主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”,避免“过度设计”和“过早优化”。

    分库分表之前,先尽力做力所能及的优化:升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后,在考虑分库分表。

    数据量过大,正常运维影响业务访问
    这里的运维是指:
    对数据库备份,如果单表太大,备份时需要大量的磁盘 IO 和网络 IO。

    对一个很大的表做 DDL,MySQL会锁住整个表,这个时间会很长,这段时间业务不能访问此表,影响很大。

    大表经常访问和更新,就更有可能出现锁等待。

    随着业务发展,需要对某些字段垂直拆分
    这里就不举例了,在实际业务中都可能会碰到,有些不经常访问或者更新频率低的字段应该从大表中分离出去。

    数据量快速增长
    随着业务的快速发展,单表中的数据量会持续增长,当性能接近瓶颈时,就需要考虑水平切分,做分库分表了。

    本文章源自公众号: mjx_java,欢迎关注。

    展开全文
  • 分库分表方案对比

    千次阅读 2020-10-17 15:22:18
    在谈论数据库架构演变和优化时,我们经常会听到分片、分库分表(Sharding)这样的关键词,在很长一段时间内,在各个公司、各中技术论坛里都很热衷谈论各种分片方案,尤其是互联网非常普及的 MySQL 数据库。...
  • 全网最全的分库分表方案

    万次阅读 多人点赞 2020-05-08 20:22:30
    一、数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,... 分库和垂直分表。 第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库。 2、CPU瓶颈 第一种:SQL问题,如SQL中
  • Python+MySQL分表分库实战,适合对MySQL 分库分表感兴趣的读者。
  • 在高并发系统当中,分库分表是必不可少的技术手段之一,同时也是BAT等大厂面试时,经常考的热门考题。 你知道我们为什么要做分库分表吗? 这个问题要从两条线说起:垂直方向和水平方向。 1 垂直方向 垂直方向...
  • 分库分表工具

    千次阅读 2017-09-19 11:12:01
    分库分表工具 最近杂事太忙,更新急剧慢了下来,没办法,只能适应中。昨天忽然想起来件事儿,原来在一家公司面试时,有人问过,分表分库的时候儿用什么工具,说实话,还真没用过。回来看了看相关工具,这时候儿才...
  • 三、分库分表工具 sharding-sphere:jar,前身是sharding-jdbc; TDDL:jar,Taobao Distribute Data Layer; Mycat:中间件。 注:工具的利弊,请自行调研,官网和社区优先。 四、分库分表步骤 根据容量(当前容量...
  • 前端用户可以把它看作是一个数据库代理,用 MySQL 客户端工具和命令行访问,而其后端可以用 MySQL 原生协议与多个 MySQL 服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分库分表。...
  • NULL 博文链接:https://javatea.iteye.com/blog/2383983
  • SpringBoot+Sharding-JDBC分库分表实战
  • 网上有很多介绍分库分表的文章,方法很多:```分区表切分垂直切分水平切分区间切分取模切分```这里不细说分库分表简单,但后期会带来一系列的难题:```事务Join分页```**数据库:**```master和slave是一个主从架构...
  • 一、背景MySQL作为最流行的关系型数据库产品之一,当数据规模增大遭遇性能瓶颈时,最容易想到的解决方案就是分库分表。无论是进行水平拆分还是垂直拆分,第一步必然需要数据迁移与同步。由此可以衍生出一系列数据...
  • 数据存储演进思路一:单单表 单单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db中的user表中查到。 数据存储演进思路二:单多表 随着用户数量的增加,user表的...
  • 如何实现分库分表?怎么配置?

    千次阅读 2020-09-24 22:29:51
    分库分表的实现方案,一般分为两种 1、增加一个中间层,中间层实现 MySQL 客户端协议,可以做到应用程序无感知地与中间层交互。由于是基于协议层的代理,可以做到支持多语言,但需要多启动一个进程、SQL 的解析也...
  • 文章目录一、前言1.1 垂直切分1.2 垂直切分的优缺点:1.3 水平切分1.3.1 水平分表1.3.2 水平分库1.4 水平...当用户量级和业务进一步提升后,写请求越来越多,这时我们开始使用了分库分表 如何解决? 数据切分 简单来
  • **场景:**系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。**分析:**库多了,io和cpu的压力自然可以成倍缓解。 2、水平分表 **概念:**以字段为依据,按照一定策略(hash、...
  • 分库分表工具mycat 等: Mycat是什么 原文链接:https://www.jianshu.com/p/b0f85164831e Mycat是一款基于阿里开源产品Cobar而研发的开源数据库分库分表中间件(基于Java语言开发)。官网所言:Mycat国内最活跃的、...
  • Shark 分布式mysql分库分表中间件,sharding领域的一站式解决方案。具备丰富、灵活的路由算法支持,能够方便DBA实现库的水平扩容和降低数据迁移成本。shark采用应用集成架构,放弃通用性,只为换取更好的执行性能与...
  • 按照规矩,这里应该介绍一下golang和分库表,懒得写,跳过。本文主要介绍两种分表方式,hash和range,对应不同对业务特性,假设有这样一个user表,字段id,name,home,balance:user表数量大概1000w条:一个查询...
  • 数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无... 分库和垂直分表。 第二种:网...
  • 1) 数据分片:分库分表、读写分离、分片策略、分布式主键 2) 分布式事务:标准化事务接口、XA强一致性事务、柔性事务 3) 数据库治理:配置动态、服务治理、数据脱敏、链路追踪 核心概念 逻辑表:水平拆分的数据库...
  • 分库分表优缺点及存在的问题

    千次阅读 2021-04-11 17:23:45
    分库分表的中间件常见的问题: 1、 扩容不方便(在增加数据库实例的时候,需要重分布数据) 2、 分布键变更很麻烦(刚开始需要买家id,后面又要根据卖家id查询时) 3、 分布键选择(架构设计)需要谨慎,甚至很...
  • 如何分库分表

    2021-12-29 16:42:05
    当数据库的数据量过大,大到一定的程度,我们就可以进行分库分表。那么基于什么原则,什么方法进行拆分,这就是本篇所要讲的。 数据库瓶颈 不管是 IO 瓶颈还是 CPU 瓶颈,最终都会导致数据库的活跃连接数增加,...
  • 简单介绍了分库分表的概念以及相关问题。
  • 分库分表的情况和作用

    千次阅读 2018-09-05 16:47:10
    一,先说一下为什么要分表 当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了。分表的目的就在于此,减小数据库的负担,缩短查询时间。 根据个人经验,mysql...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,185
精华内容 12,074
关键字:

分库分表工具