分库分表【Sharding-JDBC】入门与项目实战

最新推荐文章于 2024-09-22 21:58:06 发布
最新推荐文章于 2024-09-22 21:58:06 发布
阅读量216 收藏
点赞数 1
文章标签： 数据库 分布式 java spring mysql
原文链接：https://github.com/MarkerHub/JavaIndex/blob/master/README.md
版权
小Hub领读：

Sharding-JDBC，这么主流的分库分表框架，你还不懂？来了解一下，然后入门吧！

作者：六点半起床

https://juejin.im/post/5edc9f3ff265da76bc760726

最近项目中不少表的数据量越来越大，并且导致了一些数据库的性能问题。因此想借助一些分库分表的中间件，实现自动化分库分表实现。调研下来，发现Sharding-JDBC目前成熟度最高并且应用最广的Java分库分表的客户端组件。本文主要介绍一些 Sharding-JDBC 核心概念以及生产环境下的实战指南，旨在帮助组内成员快速了解 Sharding-JDBC 并且能够快速将其使用起来。Sharding-JDBC 官方文档：https://shardingsphere.apache.org/document/current/cn/overview/

核心概念

在使用Sharding-JDBC之前，一定是先理解清楚下面几个核心概念。

逻辑表

水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为 10 张表，分别是t_order_0到t_order_9，他们的逻辑表名为t_order。

真实表

在分片的数据库中真实存在的物理表。即上个示例中的t_order_0到t_order_9。

数据节点

数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。

绑定表

指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明, 如果 SQL 为：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

假设t_order和t_order_item对应的真实表各有 2 个，那么真实表就有t_order_0、t_order_1、t_order_item_0、t_order_item_1。在不配置绑定表关系时，假设分片键order_id将数值 10 路由至第 0 片，将数值 11 路由至第 1 片，那么路由后的 SQL 应该为 4 条，它们呈现为笛卡尔积：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在配置绑定表关系后，路由的 SQL 应该为 2 条：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

广播表

指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。

数据分片

分片键

用于分片的数据库字段，是将数据库 (表) 水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。SQL 中如果无分片字段，将执行全路由，性能较差。除了对单分片字段的支持，Sharding-JDBC 也支持根据多个字段进行分片。

分片算法

通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

目前提供 4 种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

搜索公纵号：MarkerHub，关注回复[ vue ]获取前后端入门教程！

精确分片算法

对应 PreciseShardingAlgorithm，用于处理使用单一键作为分片键的 = 与 IN 进行分片的场景。需要配合 StandardShardingStrategy 使用。

范围分片算法

对应 RangeShardingAlgorithm，用于处理使用单一键作为分片键的 BETWEEN AND、>、<、>=、<= 进行分片的场景。需要配合 StandardShardingStrategy 使用。

复合分片算法

对应 ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合 ComplexShardingStrategy 使用。

Hint 分片算法

对应 HintShardingAlgorithm，用于处理通过 Hint 指定分片值而非从 SQL 中提取分片值的场景。需要配合 HintShardingStrategy 使用。

分片策略

包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供 5 种分片策略。

标准分片策略

对应 StandardShardingStrategy。提供对 SQ L 语句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。 StandardShardingStrategy 只支持单分片键，提供 PreciseShardingAlgorithm 和 RangeShardingAlgorithm 两个分片算法。 PreciseShardingAlgorithm 是必选的，用于处理 = 和 IN 的分片。 RangeShardingAlgorithm 是可选的，用于处理 BETWEEN AND, >, <, >=, <=分片，如果不配置 RangeShardingAlgorithm，SQL 中的 BETWEEN AND 将按照全库路由处理。

复合分片策略

对应 ComplexShardingStrategy。复合分片策略。提供对 SQL 语句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。 ComplexShardingStrategy 支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。

行表达式分片策略

对应 InlineShardingStrategy。使用 Groovy 的表达式，提供对 SQL 语句中的 = 和 IN的分片操作支持，只支持单分片键。对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的 Java 代码开发，如: t_user_$->{u_id % 8} 表示 t_user 表根据 u_id 模 8，而分成 8 张表，表名称为 t_user_0 到 t_user_7。 可以认为是精确分片算法的简易实现

Hint 分片策略

对应 HintShardingStrategy。通过 Hint 指定分片值而非从 SQL 中提取分片值的方式进行分片的策略。

分布式主键

用于在分布式环境下，生成全局唯一的 id。Sharding-JDBC 提供了内置的分布式主键生成器，例如 UUID、SNOWFLAKE。还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。为了保证数据库性能，主键 id 还必须趋势递增，避免造成频繁的数据页面分裂。

读写分离

提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用。

  • 同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库读取，用于保证数据一致性

  • 基于 Hint 的强制主库路由。

  • 主从模型中，事务中读写均用主库。

执行流程

Sharding-JDBC 的原理总结起来很简单: 核心由 SQL解析 => 执行器优化 => SQL路由 => SQL改写 => SQL执行 => 结果归并的流程组成。

项目实战

spring-boot 项目实战

引入依赖

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>4.0.1</version>
</dependency>

数据源配置

如果使用sharding-jdbc-spring-boot-starter, 并且数据源以及数据分片都使用 shardingsphere 进行配置，对应的数据源会自动创建并注入到 spring 容器中。

spring.shardingsphere.datasource.names=ds0,ds1

spring.shardingsphere.datasource.ds0.type=org.apache.commons.dbcp.BasicDataSource
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds0.url=jdbc:mysql://localhost:3306/ds0
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=

spring.shardingsphere.datasource.ds1.type=org.apache.commons.dbcp.BasicDataSource
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds1.url=jdbc:mysql://localhost:3306/ds1
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=

# 其它分片配置

但是在我们已有的项目中，数据源配置是单独的。因此要禁用sharding-jdbc-spring-boot-starter里面的自动装配，而是参考源码自己重写数据源配置。需要在启动类上加上@SpringBootApplication(exclude = {org.apache.shardingsphere.shardingjdbc.spring.boot.SpringBootConfiguration.class})来排除。然后自定义配置类来装配DataSource。

@Configuration
@Slf4j
@EnableConfigurationProperties({
        SpringBootShardingRuleConfigurationProperties.class,
        SpringBootMasterSlaveRuleConfigurationProperties.class, SpringBootEncryptRuleConfigurationProperties.class, SpringBootPropertiesConfigurationProperties.class})
@AutoConfigureBefore(DataSourceConfiguration.class)
public class DataSourceConfig implements ApplicationContextAware {

    @Autowired
    private SpringBootShardingRuleConfigurationProperties shardingRule;

    @Autowired
    private SpringBootPropertiesConfigurationProperties props;

    private ApplicationContext applicationContext;

    @Bean("shardingDataSource")
    @Conditional(ShardingRuleCondition.class)
    public DataSource shardingDataSource() throws SQLException {
        // 获取其它方式配置的数据源
        Map<String, DruidDataSourceWrapper> beans = applicationContext.getBeansOfType(DruidDataSourceWrapper.class);
        Map<String, DataSource> dataSourceMap = new HashMap<>(4);
        beans.forEach(dataSourceMap::put);
        // 创建shardingDataSource
        return ShardingDataSourceFactory.createDataSource(dataSourceMap, new ShardingRuleConfigurationYamlSwapper().swap(shardingRule), props.getProps());
    }

    @Bean
    public SqlSessionFactory sqlSessionFactory() throws SQLException {
        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
        // 将shardingDataSource设置到SqlSessionFactory中
        sqlSessionFactoryBean.setDataSource(shardingDataSource());
        // 其它设置
        return sqlSessionFactoryBean.getObject();
    }
}

分布式 id 生成器配置

Sharding-JDBC 提供了UUID、SNOWFLAKE生成器，还支持用户实现自定义 id 生成器。比如可以实现了 type 为SEQ的分布式 id 生成器，调用统一的分布式id服务获取 id。

@Data
public class SeqShardingKeyGenerator implements ShardingKeyGenerator {

    private Properties properties = new Properties();

    @Override
    public String getType() {
        return "SEQ";
    }

    @Override
    public synchronized Comparable<?> generateKey() {
       // 获取分布式id逻辑
    }
}

由于扩展ShardingKeyGenerator是通过 JDK 的serviceloader的 SPI 机制实现的，因此还需要在resources/META-INF/services目录下配置org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator文件。 文件内容就是SeqShardingKeyGenerator类的全路径名。这样使用的时候，指定分布式主键生成器的 type 为SEQ就好了。

至此，Sharding-JDBC 就整合进 spring-boot 项目中了，后面就可以进行数据分片相关的配置了。

数据分片实战

如果项目初期就能预估出表的数据量级，当然可以一开始就按照这个预估值进行分库分表处理。但是大多数情况下，我们一开始并不能准备预估出数量级。这时候通常的做法是：

  1. 线上数据某张表查询性能开始下降，排查下来是因为数据量过大导致的。

  2. 根据历史数据量预估出未来的数据量级，并结合具体业务场景确定分库分表策略。

  3. 自动分库分表代码实现。

下面就以一个具体事例，阐述具体数据分片实战。比如有张表数据结构如下：

CREATE TABLE `hc_question_reply_record` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '自增ID',
  `reply_text` varchar(500) NOT NULL DEFAULT '' COMMENT '回复内容',
  `reply_wheel_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '回复时间',

  `ctime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `mtime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  INDEX `idx_reply_wheel_time` (`reply_wheel_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
  COMMENT='回复明细记录';
分片方案确定

先查询目前目标表月新增趋势：

SELECT count(*), date_format(ctime, '%Y-%m') AS `日期`
FROM hc_question_reply_record
GROUP BY date_format(ctime, '%Y-%m');

目前月新增在 180w 左右，预估未来达到 300w(基本以 2 倍计算) 以上。期望单表数据量不超过 1000w，可使用

reply_wheel_time

作为分片键按季度归档。

分片配置
spring:
  # sharing-jdbc配置
  shardingsphere:
    # 数据源名称
    datasource:
      names: defaultDataSource,slaveDataSource
    sharding:
      # 主从节点配置
      master-slave-rules:
        defaultDataSource:
          # maser数据源
          master-data-source-name: defaultDataSource
          # slave数据源
          slave-data-source-names: slaveDataSource
      tables:
        # hc_question_reply_record 分库分表配置
        hc_question_reply_record:
          # 真实数据节点  hc_question_reply_record_2020_q1
          actual-data-nodes: defaultDataSource.hc_question_reply_record_$->{2020..2025}_q$->{1..4}
          # 表分片策略
          table-strategy:
            standard:
              # 分片键
              sharding-column: reply_wheel_time
              # 精确分片算法 全路径名
              preciseAlgorithmClassName: com.xx.QuestionRecordPreciseShardingAlgorithm
              # 范围分片算法，用于BETWEEN，可选。。该类需实现RangeShardingAlgorithm接口并提供无参数的构造器
              rangeAlgorithmClassName: com.xx.QuestionRecordRangeShardingAlgorithm

      # 默认分布式id生成器
      default-key-generator:
        type: SEQ
        column: id
分片算法实现

  • 精确分片算法：QuestionRecordPreciseShardingAlgorithm

public class QuestionRecordPreciseShardingAlgorithm implements PreciseShardingAlgorithm<Date> {
  /**
   * Sharding.
   *
   * @param availableTargetNames available data sources or tables's names
   * @param shardingValue        sharding value
   * @return sharding result for data source or table's name
   */
  @Override
  public String doSharding(Collection<String> availableTargetNames, PreciseShardingValue<Date> shardingValue) {
	  return ShardingUtils.quarterPreciseSharding(availableTargetNames, shardingValue);
  }
}

  • 范围分片算法：QuestionRecordRangeShardingAlgorithm

public class QuestionRecordRangeShardingAlgorithm implements RangeShardingAlgorithm<Date> {


  /**
   * Sharding.
   *
   * @param availableTargetNames available data sources or tables's names
   * @param shardingValue        sharding value
   * @return sharding results for data sources or tables's names
   */
  @Override
  public Collection<String> doSharding(Collection<String> availableTargetNames, RangeShardingValue<Date> shardingValue) {
	  return ShardingUtils.quarterRangeSharding(availableTargetNames, shardingValue);
  }
}

  • 具体分片实现逻辑：ShardingUtils

@UtilityClass
public class ShardingUtils {
	public static final String QUARTER_SHARDING_PATTERN = "%s_%d_q%d";

	/**
	* logicTableName_{year}_q{quarter}
	* 按季度范围分片
	* @param availableTargetNames 可用的真实表集合
	* @param shardingValue 分片值
	* @return
	*/
	public Collection<String> quarterRangeSharding(Collection<String> availableTargetNames, RangeShardingValue<Date> shardingValue) {
		Range<Date> valueRange = shardingValue.getValueRange();
		Date lower = valueRange.lowerEndpoint();
		Date upper = valueRange.upperEndpoint();
		LocalDate lowerLocalDate =
				lower.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
		LocalDate upperLocalDate =
				upper.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
		int lowerYear = lowerLocalDate.getYear();
		int lowerMonth = lowerLocalDate.getMonthValue();
		int lowerQuarter = getQuarter(lowerMonth);

		int upperYear = upperLocalDate.getYear();
		int upperMonth = upperLocalDate.getMonthValue();
		int upperQuarter = getQuarter(upperMonth);

		String logicTableName = shardingValue.getLogicTableName();
		List<String> actualTableNames = new ArrayList<>();

		if (lowerYear == upperYear) {
			// 不跨年
			for (int quarter = lowerQuarter; quarter <= upperQuarter; quarter++) {
				String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, lowerYear, quarter);
				actualTableNames.add(actualTableName);
			}
		} else {
			// 跨年
			for (int quarter = lowerQuarter; quarter <= Constant.INT_4; quarter++) {
				String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, lowerYear, quarter);
				actualTableNames.add(actualTableName);
			}

			for (int year = lowerYear + 1; year < upperYear; year++) {
				for (int quarter = 1; quarter <= Constant.INT_4; quarter++) {
					String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, year, quarter);
					actualTableNames.add(actualTableName);
				}
			}

			for (int quarter = 1; quarter <= upperQuarter; quarter++) {
				String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, upperYear, quarter);
				actualTableNames.add(actualTableName);
			}

		}

		if (!availableTargetNames.containsAll(actualTableNames)) {
			throw new IllegalArgumentException("分片异常！shardingValue=" + shardingValue + "; availableTargetNames=" + availableTargetNames);
		}
		return actualTableNames;
	}

	/**
	* logicTableName_{year}_q{quarter}
	* 按季度精确分片
	* @param availableTargetNames 可用的真实表集合
	* @param shardingValue 分片值
	* @return
	*/
	public static String quarterPreciseSharding(Collection<String> availableTargetNames, PreciseShardingValue<Date> shardingValue) {
		String logicTableName = shardingValue.getLogicTableName();
		Date value = shardingValue.getValue();
		LocalDate localDate =
				value.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
		int year = localDate.getYear();
		int month = localDate.getMonthValue();
		int quarter = getQuarter(month);
		String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, year, quarter);
		if (availableTargetNames.contains(actualTableName)) {
			return actualTableName;
		}
		throw new IllegalArgumentException("分片异常！shardingValue=" + shardingValue + "; availableTargetNames=" + availableTargetNames);
	}

	private static int getQuarter(int month) {
		if (month >= Constant.INT_1 && month <= Constant.INT_3) {
			return Constant.INT_1;
		} else if (month >= Constant.INT_4 && month <= Constant.INT_6) {
			return Constant.INT_2;
		} else if (month >= Constant.INT_7 && month <= Constant.INT_9) {
			return Constant.INT_3;
		} else if (month >= Constant.INT_10 && month <= Constant.INT_12) {
			return Constant.INT_4;
		} else {
			throw new IllegalArgumentException("month非法！month=" + month);
		}
	}
}

到这里，针对hc_question_reply_record表，使用reply_wheel_time作为分片键，按照季度分片的处理就完成了。还有一点要注意的就是，分库分表之后，查询的时候最好都带上分片键作为查询条件，否则就会使用全库路由，性能很低。还有就是 Sharing-JDBC 对 mysql 的全文索引支持的不是很好，项目有使用到的地方也要注意一下。总结来说整个过程还是比较简单的，后续碰到其它业务场景，相信大家按照这个思路肯定都能解决的。

（完）

MarkerHub文章索引：（点击阅读原文直达）

https://github.com/MarkerHub/JavaIndex
【推荐阅读】
有啥不同？来看看Spring Boot 基于 JUnit 5 实现单元测试
记一次Spring boot 和Vue前后端分离的入门培训
实践：SpringBoot实现定时任务的动态增删启停

微服务统一登陆认证怎么做？JWT ？
Spring容器IOC初始化过程--今天终于进行总结了
好用到爆的 Java 技巧

好文章！点个在看！

MarkerHub
关注
Sharding-JDBC【Sharding-JDBC介绍、数据分片剖析实战】(一)-全面详解（学习总结---从入门到深化）
07-09 500
Sharding-JDBC【Sharding-JDBC介绍、数据分片剖析实战】(一)-全面详解（学习总结---从入门到深化）
一文入门数据库中间件（ShardingSphere，Sharding-JDBC），从理论到实战，完成数据库主从复制，读写分离，分库分表！！！
weixin_45929082的博客
09-26 1254
注： 大家好我是妈妈的好大儿， 笔者联系方式 QQ：3302254385 微信：yxc3302254385 交个朋友！ 创作不易，三连十分感谢！！！ 文章篇幅过长，有很多理论如果没有耐心！！！可以直接通过目录找到需要的配置文件！！！ 1.基本介绍 详细内容见： https://shardingsphere.apache.org/document/current/cn/overview/ ShardingSphere是什么？ Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生
shareding-jdbc分库分表
04-01
Sharding-JDBC 是当当网开源的适用于微服务的分布式数据访问基础类库，完整的实现了分库分表，读写分离和分布式主键功能，并初步实现了柔性事务。从 2016 年开源至今，在经历了整体架构的数次精炼以及稳定性打磨后，如今它已积累了足够的底蕴。
项目集成sharding-jdbc
最新发布
luosuss的博客
09-22 1138
目录项目集成sharding-jdbc1.业务分析 2.数据库构建3.分库分表策略 项目配置默认数据源一：导入sharding-jdbc依赖 二：在application文件中编写配置三：注释掉主配置文件中配置的数据源注意：这里添加了spring.main.allow-bean-definition-overriding: true四：测试项目配置广播表（公共表）一:application配置二：测试项目使用standard标准模式配置分库算法一.分库算法类 二.application中配置逻辑表对应的数据
Sharding-JDBC （一）—— 核心概念
zhouhuahao的博客
03-10 270
一.SQL 逻辑表会在SQL解析和路由时被替换成真实的表名 1) 逻辑表 水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为 10 张表，分别是t_order0到t_order9，他们的逻辑表名为t_order。 2)真实表 在分片的数据库中真实存在的物理表。即上个示例中的t_order0到t_order9。 3)数据节点 数...
分库分表—ShardingJDBC
Eris_QwQ的博客
06-22 1216
定位为轻量级 Java框架，在 Java 的 JDBC层提供的额外服务，它使用客户端直连数据库，以 jar包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC驱动，完全兼容 JDBC 和各种 ORM框架。适用于任何基于 JDBC 的 ORM框架，如：JPA、Hibernate、Mybatis、Spring JDBC Template 或是直接使用 JDBC；支持任何第三方的数据库连接池，如：DBCP、C3P0、BoneCP、HikariCP 等；
分布式数据库-分库分表01-ShardingJDBC
LC的博客
12-30 1175
1.MYSQL分库分表的原理 为什么要分库分表 一般的机器（4核16G），单库的MySQL并发（QPS+TPS）超过了2k，系统基本就完蛋了。最好是并发量控制在1k左右。这里就引出一个问题，为什么要分库分表？ 1、高并发情况下，会造成IO读写频繁，自然就会造成读写缓慢，甚至是宕机。一般单库不要超过2k并发，NB的机器除外。 2、数据量大的问题。主要由于底层索引实现导致，MySQL的索引实现为B+TREE，数据量其他，会导致索引树十分庞大，造成查询缓慢。第二，innodb的最大存储限制64TB 分库分表目
关于分库分表组件Sharding-JDBC入门与项目实战
gg7894125的博客
08-01 905
最近项目中不少表的数据量越来越大，并且导致了一些数据库的性能问题。因此想借助一些分库分表的中间件，实现自动化分库分表实现。调研下来，发现Sharding-JDBC目前成熟度最高并且应用最广的Java分库分表的客户端组件。本文主要介绍一些Sharding-JDBC核心概念以及生产环境下的实战指南，旨在帮助组内成员快速了解Sharding-JDBC并且能够快速将其使用起来。Sharding-JDBC官方文档 核心概念 在使用Sharding-JDBC之前，一定是先理解清楚下面几个核心概念。 逻辑表 水平拆分的数
使用Sharding-JDBC实现分库分表
2401_84048179的博客
04-19 1037
Sharding-JDBC是当当网研发的开源分布式数据库中间件，从 3.0 开始Sharding-JDBC被包含在 Sharding-Sphere中，之后该项目进入进入Apache孵化器，4.0版本之后的版本为Apache版本。ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding- Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。
mysql使用sharding-JDBC进行分表
sean的博客
07-08 1107
使用sharding-jdbc进行分表
ShardingJdbc分表
weixin_44545290的博客
11-13 1041
Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
ShardingSphere系列01：Shardingjdbc实现分表（含项目实践）
Think_and_work的博客
03-30 3675
Springboot系列：整合Shardingjdbc实现分表、含项目实践！
Sharding-JDBC 分库分表
tanksyg的专栏
03-18 173
分库分表就是按照一定的规则，对原有的数据库和表进行拆分，把原本存储于一个库的数据分玦存储到多 个库上，把原本存储于一个表的数据分块存储到多个表上。目的就是为了缓解数据库的压力，最大限度提高数据操作的效率。分表就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。分库一旦分表，一个库中的表会越来越多。
Sharding-jdbc分库分表
Lyzxii
07-30 6028
引入 不断增长的业务数据会对MySQL数据库的存储和访问造成极大的性能影响，由于单台服务器的资源（CPU、磁盘、内存等）总是有限的，所以单台数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。不论是获取连接还是插入或查询都会有极大的性能问题。 MySQL大数据量造成的性能瓶颈解决方案： 从SQL入手 加入索引 -> 缓存 -> 主从复制/读写分离 使用缓存，减少对数据库的同步访问 减少MySQL使用，可以使用HBase、polarDB、TiDB等分布式存储，ES查询 分库分表 拓展
Sharding-JDBC分库分表
shaopengjie的博客
05-19 2172
垂直分表： 按字段访问频次、是否大字段等原则，将原先的大表拆分为多个小表，从而提升数据库性能。垂直分表会导致表结构改变，所以拆分时尽量从业务角度出发，避免联查，否则得不偿失。垂直分库：可以按照数据表业务，将相同业务的表拆分到多个数据库，这些数据库可以分布在不同的服务器上。这个过程中，表结构不发生改变。拆分之后，压力被多个服务器分别承担，从而提升访问数据，同时可以提高业务清晰度。但它需要解决跨库所带来的所有复杂问题。水平分库。
Java：95-分库分表技术之ShardingJDBC
qq_59609098的博客
10-14 6434
- "utf8"可以不加引号，反正不区分，相当于一个数（添加数据时需要加，那里是区分的）););#定义名称#定义起始路径#通常用来解决中文乱码，在88章博客有具体说明#解决bean重复问题，在89章博客有具体说明#开启驼峰命名匹配映射#定义名称#定义起始路径#通常用来解决中文乱码，在88章博客有具体说明#解决bean重复问题，在89章博客有具体说明#开启驼峰命名匹配映射# 定义数据源名称#如果出现相同的属性，那么在后面的覆盖前面的，虽然同时存在会报错。
sharding-jdbc分库分表（一）
喜欢DNF的小黑猫的博客
12-05 1542
sharding-jdbc 分库分表
Shareding JDBC分库分表
weixin_45476233的博客
09-26 3330
springboot整合sharding-jdbc实现按年分库按月分表（实现、简析篇） 1.前言： ​ 此方案为适用对时间依赖度较高的数据进行水平切分，如果你正好符合，那么你可以看看此篇，不符合也可以看看，毕竟sharding-jdbc对分库分表的方案实现度很高，可根据自身实际情况进行数据切分，如果你对以下概念已经有共了解，可直接跳到代码环节 2.分库分表概念 ​ 在做实现之前，我们需要了解到何为分库分表，为何要这样做，这样做有何利弊？ ​ 由于关系型数据库的先天特性，在单表数据量达到一定体量的时候，就会出
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值