分库分表之历史表如何选择最佳分片路由规则
分库分表之历史表如何选择最佳分片路由规则
前言
先别急着关闭,我相信这篇文章应该是所有讲分表分库下的人都没有和你们讲过的一种分片模式,外面的文章基本上都是教你如何从零开始分片,现在我将讲解的是如何从1+开始分片
背景
首先我相信很多人使用分表分库一定有这么一个情况,就是目前我们的系统有一张表可能会非常的庞大,然后希望通过分片技术将其进行水平拆分,但是如何拆分或者说如何拆分可以保证让目前的数据性能达到最优解,是一个很值得探讨的问题。
这边简单举一个例子,譬如我们的订单表,目前我们的订单表可能已经达到一定的数量级了比如百万或者千万级别了,可能光是简单的查询性能是很高的,但是新增订单可能就没这么乐观了,随着索引的增多新增的数目也会不断地变慢,不仅仅是查询一个维度迫使你选择分表。
基于这个简单的案例我们来延伸一下如何水平拆分成为目前最关键的一个问题。
按月份表
这边我们如果将订单表按月进行水平分表那么我们可以了解到哪怕是随着时间的推移,数据库的瓶颈也会慢慢的变成容量的瓶颈了而不仅仅是单表的上限了。
假设我们这边的订单是从2016年开始的,一直到2022年3月我们发现订单表可以分成近70张表,而且针对分片我们有个天然的优势就是按时间分片可以拥有顺序查询这一特性,所以说这么来分片将是一个比较完美的实现
但是随着系统的运行我们发现这种分片方式虽然看着比较完美,但是存在一个很严重的问题就是数据的分布不均匀,因为可能系统刚上线那段时间我们的系统使用量并不是那么多,导致了系统内部的订单数量不会那么的多,所以虽然我们把订单表按月来分了,但是之前的历史数据因为使用量的原因导致按月分表的每张表里面可能拥有的数据很少很少。
导致了分片在各个表中的数据分布极其不均匀。会造成很多不必要的跨表聚合问题,那么我们希望的方案是什么呢?
多维度分片
什么是多维度分片
- 2018年及以前的数据我们将其归集到Order_History表中
- 2019到2021年份的我们按年分表
- 2022年开始的数据我们按月分表
时间分片遇到的问题 随着系统的不断升级迭代,我们的系统也慢慢地拆分成了多个微服务,在各个微服务之间针对订单的调用我们将会传递一个订单id作为各个微服务之间交互的手段。
但是也是因为这种方式,让我们认识到分片如果按时间来分配那么微服务之间交互的id那么如果不是雪花id那么最好是带时间的或者说可以反解析出创建时间的。
但是因为订单历史原因导致2022年之前的订单全部采用的是guid那种无序的id,分表后我们将无法通过无序的guid来进行分片路由的指定,没办法用多字段分片辅助路由这个特性了。
针对这个问题我们该如何解决呢?
引入redis来辅助分片 虽然我们没办法通过历史订单id,guid来进行路由的辅助,但是我们可以借助第三方高速缓存来实现乱序id在分片环境下的辅助路由。
具体我们的实现原理是什么呢
- 采用订单id进行辅助路由
- 将历史数据全部导入到redis,redis只需要存储id和时间即可
- 程序利用辅助路由来实现乱序guid进行实际分片辅助
# ShardingCore核心框架 版本6.4.2.4+
PM> Install-Package ShardingCore
# 数据库驱动这边选择的是mysql的社区驱动 efcore6最新版本即可
PM> Install-Package Pomelo.EntityFrameworkCore.MySql
# redis驱动
PM> Install-Package CSRedisCore
第二步添加订单表和数据库上下文
添加订单表
public class Order
{
public string Id { get;
set;
}
public string Title { get;
set;
}
public string Description { get;
set;
}
public OrderStatusEnum OrderStatus { get;
set;
}
public DateTime? PayTime { get;
set;
}
public DateTime CreateTime { get;
set;
}
}public enum OrderStatusEnum
{
NoPay=1,
Paid=1<<1
}
【分库分表之历史表如何选择最佳分片路由规则】添加数据库上下文和
Order
对象的数据库映射public class MyDbContext:AbstractShardingDbContext,IShardingTableDbContext
{
public MyDbContext(DbContextOptions options) : base(options)
{}public IRouteTail RouteTail { get;
set;
}protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity(builder =>
{
builder.HasKey(o => o.Id);
builder.Property(o => o.Id).HasMaxLength(50).IsRequired().IsUnicode(false);
builder.Property(o => o.Title).HasMaxLength(50).IsRequired();
builder.Property(o => o.Description).HasMaxLength(255).IsRequired();
builder.Property(o => o.OrderStatus).HasConversion();
builder.ToTable(nameof(Order));
});
}
}
第三步添加按创建时间按月路由
public class OrderRoute:AbstractSimpleShardingMonthKeyDateTimeVirtualTableRoute
{
public override void Configure(EntityMetadataTableBuilder builder)
{
builder.ShardingProperty(o => o.CreateTime);
}public override bool AutoCreateTableByTime()
{
return true;
}public override DateTime GetBeginTime()
{
return new DateTime(2016, 1, 1);
}
}
第四步初始化配置和数据
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
ILoggerFactory efLogger = LoggerFactory.Create(builder =>
{
builder.AddFilter((category, level) => category == DbLoggerCategory.Database.Command.Name && level == LogLevel.Information).AddConsole();
});
builder.Services.AddControllers();
builder.Services.AddShardingDbContext()
.AddEntityConfig(o =>
{
o.CreateShardingTableOnStart = true;
o.EnsureCreatedWithOutShardingTable = true;
o.AddShardingTableRoute();
})
.AddConfig(o =>
{
o.ConfigId = "c1";
o.UseShardingQuery((conStr, b) =>
{
b.UseMySql(conStr, new MySqlServerVersion(new Version())).UseLoggerFactory(efLogger);
});
o.UseShardingTransaction((conn, b) =>
{
b.UseMySql(conn, new MySqlServerVersion(new Version())).UseLoggerFactory(efLogger);
});
o.AddDefaultDataSource("ds0", "server=127.0.0.1;
port=3306;
database=ShardingHistoryDB;
userid=root;
password=root;
");
o.ReplaceTableEnsureManager(sp => new MySqlTableEnsureManager());
}).EnsureConfig();
var app = builder.Build();
app.Services.GetRequiredService().Start();
using (var scope = app.Services.CreateScope())
{
var myDbContext = scope.ServiceProvider.GetRequiredService();
if (!myDbContext.Set().Any())
{
List orders = new List();
var order2016s = createOrders(2016,50);
var order2017s = createOrders(2017,100);
var order2018s = createOrders(2018,200);
var order2019s = createOrders(2019,300);
var order2020s = createOrders(2020,300);
var order2021s = createOrders(2021,300);
var order2022s = createOrders(2022,90);
orders.AddRange(order2016s);
orders.AddRange(order2017s);
orders.AddRange(order2018s);
orders.AddRange(order2019s);
orders.AddRange(order2020s);
orders.AddRange(order2021s);
orders.AddRange(order2022s);
myDbContext.AddRange(orders);
myDbContext.SaveChanges();
}
}
app.MapControllers();
app.Run();
List createOrders(int year,int count)
{
var beginTime = new DateTime(year, 1, 1, 1, 1,1);
var orders = Enumerable.Range(1,count)
.Select((o, i) =>
{
var createTime = beginTime.AddDays(i);
return new Order()
{
Id = year<2022?Guid.NewGuid().ToString("n"):$"{createTime:yyyyMMddHHmmss}",
CreateTime = createTime,
Title = year+"年订单:" + i,
Description = year+"年订单详细描述:" + i,
OrderStatus = i % 7 == 0 ? OrderStatusEnum.NoPay : OrderStatusEnum.Paid,
PayTime = i % 7 == 0 ? null : createTime.AddSeconds(new Random().Next(1, 300)),
};
}).ToList();
return orders;
}
第五步开启程序
SELECT table_name,table_rows FROM information_schema.tables
WHERE TABLE_SCHEMA = 'ShardingHistoryDB' ORDER BY TABLE_SCHEMA DESC;
通过上述sql语句我们可以查询出对应表内有多少数据量
文章图片
通过截图我们可以看到数据分布相对恨不均匀导致很多表的数据过少(这边是做了一个测试)
所以当我们进行查询的时候,有很大的可能性会做落到无关表上,并且因为历史原因导致我们在2022年之前的数据订单id都是采用的是guid,这让我们无法通过guid来实现分表的辅助查询。
优化数据表分布 因为上述原因我们这边需要进行表数据的分布优化,具体我们采用的是现实将2018年包括2018年的数据全部存入一张叫做history的表,然后针对2019、2020、2021表进行按年分表,剩下的订单按月分表
目前市面上很少有框架支持这么复杂的订单路由所以我们接下来就需要进行实现
第一步改写路由
- 改写2018年之前的
- 改写近期按年分表
- 剩下的按月分表
public class OrderRoute:AbstractSimpleShardingMonthKeyDateTimeVirtualTableRoute
{
public override void Configure(EntityMetadataTableBuilder builder)
{
builder.ShardingProperty(o => o.CreateTime);
}public override bool AutoCreateTableByTime()
{
return true;
}public override DateTime GetBeginTime()
{
return new DateTime(2016, 1, 1);
}
//系统启动需要知道数据库应该有哪些表
public override List GetAllTails()
{
var tails=new List();
tails.Add("History");
tails.Add("2019");
tails.Add("2020");
tails.Add("2021");
var beginTime = ShardingCoreHelper.GetCurrentMonthFirstDay(new DateTime(2022,1,1));
//提前创建表
var nowTimeStamp =ShardingCoreHelper.GetCurrentMonthFirstDay(DateTime.Now);
if (beginTime > nowTimeStamp)
throw new ArgumentException("begin time error");
var currentTimeStamp = beginTime;
while (currentTimeStamp <= nowTimeStamp)
{
var tail = ShardingKeyToTail(currentTimeStamp);
tails.Add(tail);
currentTimeStamp = ShardingCoreHelper.GetNextMonthFirstDay(currentTimeStamp);
}
return tails;
}private static readonly DateTime historyTime = new DateTime(2019, 1, 1);
private static readonly DateTime yearTime = new DateTime(2022, 1, 1);
public override string ShardingKeyToTail(object shardingKey)
{
var dateTime = (DateTime)shardingKey;
if (dateTime < historyTime)
{
return "History";
}if (dateTime < yearTime)
{
return $"{dateTime:yyyy}";
}
return base.ShardingKeyToTail(shardingKey);
}private static readonly HistoryMinComparer _historyMinComparer = new HistoryMinComparer();
public override Expression GetRouteToFilter(DateTime shardingKey, ShardingOperatorEnum shardingOperator)
{
var t = TimeFormatToTail(shardingKey);
switch (shardingOperator)
{
case ShardingOperatorEnum.GreaterThan:
case ShardingOperatorEnum.GreaterThanOrEqual:
return tail => _historyMinComparer.Compare(tail, t) >= 0;
case ShardingOperatorEnum.LessThan:
{
// var currentMonth = ShardingCoreHelper.GetCurrentMonthFirstDay(shardingKey);
// //处于临界值 o=>o.time < [2021-01-01 00:00:00] 尾巴20210101不应该被返回
// if (currentMonth == shardingKey)
//return tail => _historyMinComparer.Compare(tail, t) < 0;
return tail => _historyMinComparer.Compare(tail, t) <= 0;
}
case ShardingOperatorEnum.LessThanOrEqual:
return tail => _historyMinComparer.Compare(tail, t) <= 0;
case ShardingOperatorEnum.Equal: return tail => tail == t;
default:
{
#if DEBUG
Console.WriteLine($"shardingOperator is not equal scan all table tail");
#endif
return tail => true;
}
}
}
}
public class HistoryMinComparer:IComparer
{
private const string History = "History";
public int Compare(string? x, string? y)
{
if (!Object.Equals(x, y))
{
if (History.Equals(x))
return -1;
if (History.Equals(y))
return 1;
}
return Comparer.Default.Compare(x, y);
}
}
这边我们改写路由将原先的按月分表改成2019年之前存入历史,2022年之前按年之后按月来实现,并且针对表后缀实现了一个历史记录History最小的比较器
第二步从新跑一边数据
删除原先的数据库从新启动程序
SELECT table_name,table_rows FROM information_schema.tables
WHERE TABLE_SCHEMA = 'ShardingHistoryDB' ORDER BY TABLE_SCHEMA DESC;
文章图片
针对这次优化我们发现我们大大的减少了数据库表的分片数量,可以有效的提高数据分布在分片环境下的存储。
第三步编写查询
编写查询控制器
文章图片
首先两个按时间查询复核预期
文章图片
因为id是guid历史原因并且框架没有对id配置辅助路由所以会进行全分片扫描
文章图片
出现这种情况会导致程序系统稳定性不足,在分布式环境下查询会变得很复杂
历史GUID辅助分片 首先因为系统历史原因导致系统的订单id使用的是乱序guid,乱序guid在程序中很难对时间分片进行优化,所以这边采用引入三方框架redis,来实现,最新数据将采用雪花id(本次演示采用格式化时间)
第一步将历史数据存入到redis,分别对应到具体表后缀
//....
RedisHelper.Initialization(new CSRedis.CSRedisClient("127.0.0.1:6379,defaultDatabase=0,poolsize=10,ssl=false,writeBuffer=10240"));
app.Services.GetRequiredService().Start();
using (var scope = app.Services.CreateScope())
{
var myDbContext = scope.ServiceProvider.GetRequiredService();
if (!myDbContext.Set().Any())
{
List orders = new List();
//.....myDbContext.AddRange(orders);
myDbContext.SaveChanges();
var virtualTableManager = app.Services.GetRequiredService>();
var virtualTable = virtualTableManager.GetVirtualTable(typeof(Order));
foreach (var order in orders.Where(o=>o.CreateTime
第二步编写路由多字段分表
public class OrderRoute:AbstractSimpleShardingMonthKeyDateTimeVirtualTableRoute
{
public override void Configure(EntityMetadataTableBuilder builder)
{
builder.ShardingProperty(o => o.CreateTime);
builder.ShardingExtraProperty(o => o.Id);
}//.....public override Expression GetExtraRouteFilter(object shardingKey, ShardingOperatorEnum shardingOperator, string shardingPropertyName)
{
if (shardingPropertyName == nameof(Order.Id))
{
return GetOrderNoRouteFilter(shardingKey, shardingOperator);
}
return base.GetExtraRouteFilter(shardingKey, shardingOperator, shardingPropertyName);
}
///
/// 订单编号的路由
///
///
///
///
private Expression GetOrderNoRouteFilter(object shardingKey,
ShardingOperatorEnum shardingOperator)
{
//将分表字段转成订单编号
var orderNo = shardingKey?.ToString() ?? string.Empty;
//判断订单编号是否是我们符合的格式
if (!CheckOrderNo(orderNo, out var orderTime))
{
//如果格式不一样就查询redis
var t = RedisHelper.Get(shardingKey.ToString());
if (string.IsNullOrWhiteSpace(t))
{
return tail => false;
}
return tail => tail==t;
}//当前时间的tail
var currentTail = TimeFormatToTail(orderTime);
//因为是按月分表所以获取下个月的时间判断id是否是在临界点创建的
//var nextMonthFirstDay = ShardingCoreHelper.GetNextMonthFirstDay(DateTime.Now);
//这个是错误的
var nextMonthFirstDay = ShardingCoreHelper.GetNextMonthFirstDay(orderTime);
if (orderTime.AddSeconds(10) > nextMonthFirstDay)
{
var nextTail = TimeFormatToTail(nextMonthFirstDay);
return DoOrderNoFilter(shardingOperator, orderTime, currentTail, nextTail);
}
//因为是按月分表所以获取这个月月初的时间判断id是否是在临界点创建的
//if (orderTime.AddSeconds(-10) < ShardingCoreHelper.GetCurrentMonthFirstDay(DateTime.Now))//这个是错误的
if (orderTime.AddSeconds(-10) < ShardingCoreHelper.GetCurrentMonthFirstDay(orderTime))
{
//上个月tail
var previewTail = TimeFormatToTail(orderTime.AddSeconds(-10));
return DoOrderNoFilter(shardingOperator, orderTime, previewTail, currentTail);
}return DoOrderNoFilter(shardingOperator, orderTime, currentTail, currentTail);
}private Expression DoOrderNoFilter(ShardingOperatorEnum shardingOperator, DateTime shardingKey, string minTail, string maxTail)
{
switch (shardingOperator)
{
case ShardingOperatorEnum.Equal:
{
var isSame = minTail == maxTail;
if (isSame)
{
return tail => tail == minTail;
}
else
{
return tail => tail == minTail || tail == maxTail;
}
}
default:
{
return tail => true;
}
}
}private bool CheckOrderNo(string orderNo, out DateTime orderTime)
{
//yyyyMMddHHmmss
if (orderNo.Length == 14)
{
if (DateTime.TryParseExact(orderNo, "yyyyMMddHHmmss", CultureInfo.InvariantCulture,
DateTimeStyles.None, out var parseDateTime))
{
orderTime = parseDateTime;
return true;
}
}orderTime = DateTime.MinValue;
return false;
}
}
//....
省略了相同部分代码,我们再次来尝试看看
第三步运行
文章图片
id所以不需要经过redis就可以直接解析出订单信息对应的所属分片
demo
DEMO
总结 目前
ShardingCore
在分片领域基本上给出了非常多的解决方案可以使用,针对.net在分表分库领域的缺失我相信会随着开源项目和更多使用的人群,来帮助.Net在未来走的更远。最后的最后 身位一个dotnet程序员我相信在之前我们的分片选择方案除了
mycat
和shardingsphere-proxy
外没有一个很好的分片选择,但是我相信通过ShardingCore
的原理解析,你不但可以了解到大数据下分片的知识点,更加可以参与到其中或者自行实现一个,我相信只有了解了分片的原理dotnet才会有更好的人才和未来,我们不但需要优雅的封装,更需要原理的是对原理了解。我相信未来dotnet的生态会慢慢起来配上这近乎完美的语法
您的支持是开源作者能坚持下去的最大动力
- Github ShardingCore
- Gitee ShardingCore
QQ群:771630778
个人QQ:326308290(欢迎技术支持提供您宝贵的意见)
个人邮箱:326308290@qq.com
推荐阅读
- 搜索引擎Elasticsearch简介实践
- java高并发之ConcurrentSkipListMap的那些事
- redis学习之集群
- 面试常问的设计模式之代理模式的详细解析!分析说明静态代理模式和动态代理模式
- 设计模式之【装饰器模式】
- Go|Go 笔记 - 小练习之获取命令行参数的三种方法
- 发现了股票涨停之前的规律,让你提前至少10分钟知道
- Go|Go 笔记 - Beego 之 orm 表结构操作
- Golang 基础之数据类型梳理
- Java实战之兼职平台系统的实现