.netcore分库分表的问题

Posted 2023-04-18

参考技术A .NET Core作为一款领先的跨平台开发框架，对于分库分表的应用也有很好的支持。在.NET Core中，可以使用ORM框架或自定义数据访问层实现分库分表的功能。

具体来说，分库分表可以在数据库层面实现，也可以在应用层面实现。在数据库层面实现，需要先进行水平分片和垂直拆分，然后在应用层面使用ORM框架或自定义数据访问层进行数据读写和事务控制。

在.NET Core中，常用的ORM框架包括Entity Framework Core、Dapper和NHibernate等，它们可以使用分库分表插件或自定义数据访问层来实现分库分表的功能。

同时，也可以在应用层面实现分库分表功能。例如，可以使用分布式缓存或分布式数据访问层来分散数据访问负载，从而达到分库分表的效果。

总之，.NET Core提供了很好的支持和扩展性，可以根据具体业务需求选择适合的分库分表方式。 参考技术B 1. 数据一致性：在分库分表的情况下，不同的数据可能被存在不同的服务器或数据库中，而且同一个数据可能会被分成多个表存储，因此需要考虑数据的一致性问题。需要使用跨库事务、分布式事务等技术，来保证数据在不同的服务器或数据库中的一致性。

2. 数据迁移：在分库分表的情况下，如果需要新增服务器或数据库，需要进行数据迁移。这可能需要一些工作，包括备份、恢复、迁移数据等。

3. 查询优化：在分库分表的情况下，查询可能需要查询多个数据库表，这可能会影响性能。需要进行优化查询，包括使用索引、减少联表查询等方法。

4. 性能监控：在分库分表的情况下，需要对不同的数据库进行性能监控。需要监控每个数据库的性能指标，包括系统负载、查询响应速度、数据存储空间等。

5. 跨数据中心访问：在分库分表的情况下，可能需要跨不同的数据中心访问数据。这需要特殊的网络设置和技术来处理数据的访问。 参考技术C .NET Core是一个开源的跨平台框架，对于分库分表问题，通常有以下两种解决方案。

1. 手动实现分库分表

手动实现分库分表是一种常见的解决方案，可以自己设计数据分片规则和数据迁移策略等。根据业务需求和数据量，可以将数据库表按照一定规则拆分成多个逻辑数据库或物理数据库，并且使用分布式事务来保证数据一致性。需要注意的是，手动实现分库分表需要编写大量的代码来完成数据的路由、数据的迁移以及异常处理等，同时还需要考虑大量的细节问题，比如数据位置管理、数据备份和恢复等。

2. 使用ORM框架的支持

目前，许多ORM框架已经支持分库分表功能。ORM框架可以将数据库分库分表的细节封装起来，使得开发人员不必自己编写复杂的代码。例如，Entity Framework Core（EF Core）提供了一种称为“Sharding”的分库分表解决方案，可以通过在代码中使用ShardedDbContext来实现分库分表。此外，NHibernate和Dapper也都提供了分库分表的支持。使用ORM框架的优势是可以提高开发效率，并且减少分布式事务的开发难度，但需要注意的是，ORM框架的功能和性能也存在一些局限性，需要仔细评估和测试。

总之，分库分表是一个非常复杂和重要的问题，需要结合具体业务需求和数据量来选择合适的解决方案。无论选择哪种方案，都需要充分测试和评估，以确保系统的性能和可用性。

互联网公司常用分库分表方案汇总

本文目录

一、数据库瓶颈

• IO瓶颈

• CPU瓶颈

二、分库分表

• 水平分库

• 水平分表

• 垂直分库

• 垂直分表

三、分库分表工具

四、分库分表步骤

五、分库分表问题

• 非partition key的查询问题

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

• 扩容问题

六、分库分表总结

七、分库分表示例

一、数据库瓶颈

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

1、IO瓶颈

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

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

2、CPU瓶颈

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

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

二、分库分表

1、水平分库

概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。

结果：

• 每个库的结构都一样；

• 每个库的数据都不一样，没有交集；

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

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

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

2、水平分表

概念：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。

结果：

• 每个表的结构都一样；

• 每个表的数据都不一样，没有交集；

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

场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。推荐：一次SQL查询优化原理分析

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

3、垂直分库

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

结果：

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

• 每个库的数据也不一样，没有交集；

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

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

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

4、垂直分表

概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

结果：

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

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

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

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

分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。

但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

三、分库分表工具

• sharding-sphere：jar，前身是sharding-jdbc；

• TDDL：jar，Taobao Distribute Data Layer；

• Mycat：中间件。

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

四、分库分表步骤

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

扩展：MySQL：分库分表与分区的区别和思考

五、分库分表问题

1、非partition key的查询问题

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

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

映射法

基因法

注：写入时，基因法生成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作为条件查询

映射法

冗余法

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

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

NoSQL法

冗余法

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

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

注：用NoSQL法解决（ES等）。

3、扩容问题

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

水平扩容库（升级从库法）

注：扩容是成倍的。

水平扩容表（双写迁移法）

• 第一步：（同步双写）修改应用配置和代码，加上双写，部署；

• 第二步：（同步双写）将老库中的老数据复制到新库中；

• 第三步：（同步双写）以老库为准校对新库中的老数据；

• 第四步：（同步双写）修改应用配置和代码，去掉双写，部署；

注：双写是通用方案。

六、分库分表总结

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

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

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

七、分库分表示例

示例GitHub地址：https://github.com/littlecharacter4s/study-sharding

来源: 程序员DD, 程序员小灰, macrozheng