.Net 下高性能分表分库组件-连ShardingCore接模式原理

ShardingCore 一款ef-core下高性能、轻量级针对分表分库读写分离的解决方案，具有零依赖、零学习成本、零业务代码入侵。

Github Source Code 助力dotnet 生态 Gitee Source Code

介绍

在分表分库领域java有着很多的解决方案,尤其是客户端解决方案(ShardingSphere)，因为客户端解决方案有着极高的性能,但是缺点也很明显数据库链接的消耗相对较高，使用语言的限制让我们.Net望而却步，但是哪怕是有着这些缺点其实也不足以掩盖客户端分表分库带来的便捷与高效。
目前本人所开发的ShardingCore 是.Net下基于efcore2+的所有版本的分表分库很多都是借鉴了ShardingSphere,并且对其很多缺点进行了弥补。这边可能有人就要说了，你为什么做个efcore的不做个ado.net的呢，说实话我这边确实有一个ado.net版本的分表分库，你可以理解为ShardingSphere的.Net复刻版本sharding-conector 最最最初版本的分表聚合已经实现底层原理和ShardingSphere一致使用的Antlr4的分词。为什么不对这个版本进行推进转而对efcore的sharding-core版本进行升级维护呢，这边主要有两点，第一点如果我是在ado.net上进行的推进那么势必可以支持更多的orm框架，但是orm框架下的很多特性将可能无法使用，并且需要维护各个数据库版本之间的差异。比如efcore下的批量操作等一些列优化语法是很难被支持的。第二点针对某个orm的扩展性能和使用体验上远远可以大于通用性组件。这就是我为什么针对ShardingCore进行有段优化和升级的原因。

性能

其实性能一直是大家关注的一个点，我用了ShardingCore那么针对特定的查询他的损耗是多少是一个比较令人关注的话题。接下来我放出之前做的两次性能比较，当然这两次比较并不是特意准备的，是我边开发边跑的一个是sqlserver 一个是mysql

性能测试

以下所有数据均在开启了表达式编译缓存的情况下测试，并且电脑处于长时间未关机并且开着很多vs和idea的情况下仅供参考,所有测试都是基于ShardingCore x.3.1.63+ version

以下所有数据均在源码中有案例

efcore版本均为6.0 表结构为string型id的订单取模分成5张表

N代表执行次数

sql server 2012,data rows 7734363 =773w

// * Summary *

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1500 (1909/November2019Update/19H2)
AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
.NET SDK=6.0.100
[Host] : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT
DefaultJob : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT

MethodNMeanErrorStdDevMedian
NoShardingIndexFirstOrDefaultAsync102.154 ms0.1532 ms0.4443 ms1.978 ms
ShardingIndexFirstOrDefaultAsync104.293 ms0.1521 ms0.4485 ms4.077 ms
NoShardingNoIndexFirstOrDefaultAsync10823.382 ms16.0849 ms18.5233 ms821.221 ms
ShardingNoIndexFirstOrDefaultAsync10892.276 ms17.8131 ms16.6623 ms894.880 ms
NoShardingNoIndexCountAsync10830.754 ms16.5309 ms38.6405 ms821.736 ms
ShardingNoIndexCountAsync10915.630 ms8.8511 ms7.3911 ms914.107 ms
NoShardingNoIndexLikeToListAsync107,008.918 ms139.4664 ms166.0248 ms6,955.674 ms
ShardingNoIndexLikeToListAsync107,044.168 ms135.3814 ms132.9626 ms7,008.057 ms
NoShardingNoIndexToListAsync10787.129 ms10.5812 ms8.8357 ms785.798 ms
ShardingNoIndexToListAsync10935.880 ms16.3354 ms15.2801 ms940.369 ms

mysql 5.7,data rows 7553790=755w innerdb_buffer_size=3G

// * Summary *

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1500 (1909/November2019Update/19H2)
AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
.NET SDK=6.0.100
[Host] : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT
DefaultJob : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT

MethodNMeanErrorStdDevMedian
NoShardingIndexFirstOrDefaultAsync105.020 ms0.1245 ms0.3672 ms4.855 ms
ShardingIndexFirstOrDefaultAsync107.960 ms0.1585 ms0.2514 ms7.974 ms
NoShardingNoIndexFirstOrDefaultAsync1011,336.083 ms623.8044 ms1,829.5103 ms11,185.590 ms
ShardingNoIndexFirstOrDefaultAsync105,422.259 ms77.5386 ms72.5296 ms5,390.019 ms
NoShardingNoIndexCountAsync1014,229.819 ms82.8929 ms77.5381 ms14,219.773 ms
ShardingNoIndexCountAsync103,085.268 ms55.5942 ms49.2828 ms3,087.704 ms
NoShardingNoIndexLikeToListAsync1027,046.390 ms71.2034 ms59.4580 ms27,052.316 ms
ShardingNoIndexLikeToListAsync105,707.009 ms106.8713 ms99.9675 ms5,672.453 ms
NoShardingNoIndexToListAsync1026,001.850 ms89.2787 ms69.7030 ms25,998.407 ms
ShardingNoIndexToListAsync105,490.659 ms71.8199 ms67.1804 ms5,477.891 ms

具体可以通过first前两次结果来计算得出结论单次查询的的损耗为0.2-0.3毫秒之间,通过数据聚合和数据路由的损耗单次在0.3ms-0.4ms,其中创建dbcontext为0.1毫秒目前没有好的优化方案,0.013毫秒左右是路由表达式解析和编译,复杂表达式可能更加耗时,剩下的0.2毫秒为数据源和表后缀的解析等操作包括实例的反射创建和数据的聚合，
sqlserver的各项数据在分表和未分表的情况下都几乎差不多可以得出在770w数据集情况下数据库还并未是数据瓶颈的关键，但是mysql可以看到在分表和未分表的情况下如果涉及到没有索引的全表扫描那么性能的差距将是分表后的表数目之多，测试中为5-6倍，也就是分表数目

如果你可以接受单次查询的损耗在0.2ms-0.3ms的那相信这款框架将会是efcore下非常完美的一款分表分库组件

链接模式

说了这么多这边需要针对ShardingCore在查询下面涉及到N表查询后带来的链接消耗是一个不容小觑的客观因素。所以这边参考ShardingSphere进行了类似原理的实现。就是如果查询涉及不同库那么直接并发，如果是同库的将根据用户配置的单次最大链接进行串行查询，并且动态选择使用流式聚合和内存聚合。

首先我们看下ShardingSphere的链接模式在限制链接数的情况下是如何进行处理的
03e4cb86c1845deb978ae87298417c53.png
针对不同的数据库采用并行执行，针对同一个数据库根据用户配置的最大连接数进行分库串行执行，并且因为需要控制链接数所以会将结果集保存在内存中，最后通过合并返回给客户端数据。
之后我们会讲这个模式的缺点并且ShardingCore是如何进行优化的

你可能已经蒙了这么多名称完全没有一个概念。接下来我将一一进行讲解,首先我们来看下链接模式下有哪些参数

MaxQueryConnectionsLimit

最大并发链接数，就是表示单次查询sharding-core允许使用的dbconnection，默认会加上1就是说如果你配置了MaxQueryConnectionsLimit=10那么实际sharding-core会在同一次查询中开启11条链接最多,为什么是11不是10因为sharding-core会默认开启一个链接用来进行空dbconnection的使用。如果不设置本参数那么默认是cpu线程数Environment.ProcessorCount

ConnectionMode

链接模式,可以由用户自行指定，使用内存限制,和连接数限制或者系统自行选择最优

链接模式，有三个可选项，分别是：

MEMORY_STRICTLY

内存限制模式最小化内存聚合 流式聚合 同时会有多个链接

MEMORY_STRICTLY的意思是最小化内存使用率，就是非一次性获取所有数据然后采用流式聚合

CONNECTION_STRICTLY

连接数限制模式最小化并发连接数 内存聚合 连接数会有限制

CONNECTION_STRICTLY的意思是最小化连接并发数，就是单次查询并发连接数为设置的连接数MaxQueryConnectionsLimit。因为有限制，所以无法一直挂起多个连接，数据的合并为内存聚合采用最小化内存方式进行优化，而不是无脑使用内存聚合

SYSTEM_AUTO

系统自动选择内存还是流式聚合

系统自行选择会根据用户的配置采取最小化连接数，但是如果遇到分页则会根据分页策略采取内存限制，因为skip过大会导致内存爆炸

解释

MEMORY_STRICTLY

MEMORY_STRICTLY内存严格模式，用户使用本属性后将会严格控制查询的聚合方式，将会采用流式聚合的迭代器模式，而不是一次性全部去除相关数据在内存中排序获取，通过用户配置的MaxQueryConnectionsLimit连接数来进行限制，比如MaxQueryConnectionsLimit=2，并且本次查询涉及到一个库3张表，因为程序只允许单次查询能并发2个链接，所以本次查询会被分成2组每组两个，其中第二组只有一个，在这种情况下第一次并发查询2条语句因为采用内存严格所以不会将数据获取到内存，第二次在进行一次查询并将迭代器返回一共组合成3个迭代器后续通过流式聚合+优先级队列进行返回所要的数据，在这种情况下程序的内存是最少的但是消耗的链接也是最大的。当用户手动选择MEMORY_STRICTLY后MaxQueryConnectionsLimit将变成并行数目. 该模式下ShardingCore和ShardingSphere的处理方式类似基本一致
40c2958c893eceee8b7e8ad4b0e218fe.png

CONNECTION_STRICTLY

CONNECTION_STRICTLY连接数严格模式，用户使用本属性后将会严格控制查询后的同一个数据库下的同时查询的链接数，不会因为使用流式内存而导致迭代器一致开着，因为一个迭代器查询开着就意味着需要一个链接，如果查询需要聚合3张表那么就需要同时开着三个链接来迭代保证流式聚合。通过用户配置的MaxQueryConnectionsLimit连接数来进行限制，比如MaxQueryConnectionsLimit=2，并且本次查询涉及到一个库3张表，因为程序只允许单次查询能并发2个链接，所以本次查询会被分成2组每组两个，其中第二组只有一个，在这种情况下第一次并发查询2条语句因为采用连接数严格所以不会一直持有链接，会将链接结果进行每组进行合并然后将连接放回，合并时还是采用的流式聚合，会首先将第一组的两个链接进行查询之后将需要的结果通过流式聚合取到内存，然后第二组会自行独立查询并且从第二次开始后会将上一次迭代的内存聚合数据进行和本次查询的流式聚合分别一起聚合，保证在分页情况下内存数据量最少。因为如果每组都是用独立的内存聚合那么你有n组就会有n*(skip+take)的数目，而ShardingSphere采用的是更加简单的做法，就是将每组下面的各自节点都自行进行内存聚合，那么如果在skip(10).take(10)的情况下sql会被改写成各组的各个节点分别进行skip(0).take(20)的操作那么2组执行器的第一组将会有40条数据第二组将会有20条数据一共会有60条数据远远操作了我们所需要的20条。所以在这个情况下ShardingCore第一组内存流式聚合会返回20条数据，第二组会将第一组的20条数据和第二组的进行流式聚合内存中还是只有20条数据，虽然是连接数严格但是也做到了最小化内存单元。当用户手动选择CONNECTION_STRICTLY后MaxQueryConnectionsLimit将是正则的最小化链接数限制

e4f40e6fe483de267f8664fe30b91ce5.png

SYSTEM_AUTO

SYSTEM_AUTO系统自行选择，这是一个非常帮的选择，因为在这个选择下系统会自动根据用户配置的MaxQueryConnectionsLimit来自行控制是采用流式聚合还是内存聚合，并且因为我们采用的是同数据库下面最小化内存相比其他的解决方案可以更加有效和高性能的来应对各种查询。仅仅只需要配置一个最大连接数限制既可以适配好连接模式。

这边极力推荐大家在不清楚应该用什么模式的时候使用SYSTEM_AUTO并且手动配置MaxQueryConnectionsLimit来确定各个环境下的配置一直而不是采用默认的cpu线程数。

首先我们通过每个数据库被路由到了多少张表进行计算期望用户在配置了xx后应该的并行数来进行分组,sqlCount :表示这个数据库被路由到的表数目，exceptCount :表示计算出来的应该的单次查询并行数

//代码本质就是向上取整int exceptCount =Math.Max(0 == sqlCount % maxQueryConnectionsLimit? sqlCount / maxQueryConnectionsLimit: sqlCount / maxQueryConnectionsLimit + 1, 1);

第二次我们通过判断sqlCount和maxQueryConnectionsLimit的大小来确定链接模式的选择

private ConnectionModeEnum CalcConnectionMode(int sqlCount){switch (_shardingConfigOption.ConnectionMode){case ConnectionModeEnum.MEMORY_STRICTLY:case ConnectionModeEnum.CONNECTION_STRICTLY: return _shardingConfigOption.ConnectionMode;default:{return _shardingConfigOption.MaxQueryConnectionsLimit < sqlCount? ConnectionModeEnum.CONNECTION_STRICTLY: ConnectionModeEnum.MEMORY_STRICTLY; ;}}}

比较

针对ShardingSphere的流程图我们可以看到在获取普通数据的时候是没有什么问题的,但是如果遇到分页也就是

select * from order limit 10,10

这种情况下会被改写成

select * from order limit 0,20

我们可以看到如果是ShardingSphere的流程模式那么在各个节点处虽然已经将连接数控制好了但是对于每个节点而言都有着20条数据，这种情况下其实是一种非常危险的，因为一旦节点过多并且limit的跳过页数过多每个节点储存的数据将会非常恐怖。
98b739b5ce8225b02359b3cc9c1e8664.png

所以针对这种情况ShardingCore将同库下的各个节点组的查询使用StreamMerge而不是MemoryMerge，并且会对各个节点间建立联系进行聚合保证在同一个数据库下只会有20条数据被加载到内存中，大大降低了内存的使用，提高了内存使用率。
e127f244fc683b853697919d7ae0f568.png

当然具体情况应该还需要再次进行优化并不是简单的一次优化就搞定的比如当跳过的页数过多之后其实在内存中的一部分数据也会再次进行迭代和新的迭代器比较，这个中间的性能差距可能需要不断地尝试才可以获取一个比较可靠的值

总结

目前已经有很多小伙伴已经在使用SharidingCore了并且在使用的时候也是相对比较简单的配置既可以“完美”目前她在使用的各种框架譬如:AbpVNext....基本上在继承和使用方面可以说是目前efcore生态下最最最完美的了真正做到了三零的框架：零依赖,零学习成本,零业务代码入侵

最后放一张图

是我这边给ShardingSphere提的建议,也证实了我对该聚合模型的优化是可以有效解决在分页下面聚合各数据库节点下的内存使用情况
b5f2deffc1b6bb4b5a3d4acd3e555893.png

分表分库组件求赞求star

您的支持是开源作者能坚持下去的最大动力

  • Github ShardingCore

  • Gitee ShardingCore

ShardingCore 一款ef-core下高性能、轻量级针对分表分库读写分离的解决方案，具有零依赖、零学习成本、零业务代码入侵。

Github Source Code 助力dotnet 生态 Gitee Source Code

介绍

在分表分库领域java有着很多的解决方案,尤其是客户端解决方案(ShardingSphere)，因为客户端解决方案有着极高的性能,但是缺点也很明显数据库链接的消耗相对较高，使用语言的限制让我们.Net望而却步，但是哪怕是有着这些缺点其实也不足以掩盖客户端分表分库带来的便捷与高效。
目前本人所开发的ShardingCore 是.Net下基于efcore2+的所有版本的分表分库很多都是借鉴了ShardingSphere,并且对其很多缺点进行了弥补。这边可能有人就要说了，你为什么做个efcore的不做个ado.net的呢，说实话我这边确实有一个ado.net版本的分表分库，你可以理解为ShardingSphere的.Net复刻版本sharding-conector 最最最初版本的分表聚合已经实现底层原理和ShardingSphere一致使用的Antlr4的分词。为什么不对这个版本进行推进转而对efcore的sharding-core版本进行升级维护呢，这边主要有两点，第一点如果我是在ado.net上进行的推进那么势必可以支持更多的orm框架，但是orm框架下的很多特性将可能无法使用，并且需要维护各个数据库版本之间的差异。比如efcore下的批量操作等一些列优化语法是很难被支持的。第二点针对某个orm的扩展性能和使用体验上远远可以大于通用性组件。这就是我为什么针对ShardingCore进行有段优化和升级的原因。

性能

其实性能一直是大家关注的一个点，我用了ShardingCore那么针对特定的查询他的损耗是多少是一个比较令人关注的话题。接下来我放出之前做的两次性能比较，当然这两次比较并不是特意准备的，是我边开发边跑的一个是sqlserver 一个是mysql

性能测试

以下所有数据均在开启了表达式编译缓存的情况下测试，并且电脑处于长时间未关机并且开着很多vs和idea的情况下仅供参考,所有测试都是基于ShardingCore x.3.1.63+ version

以下所有数据均在源码中有案例

efcore版本均为6.0 表结构为string型id的订单取模分成5张表

N代表执行次数

sql server 2012,data rows 7734363 =773w

// * Summary *

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1500 (1909/November2019Update/19H2)
AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
.NET SDK=6.0.100
[Host] : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT
DefaultJob : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT

MethodNMeanErrorStdDevMedian
NoShardingIndexFirstOrDefaultAsync102.154 ms0.1532 ms0.4443 ms1.978 ms
ShardingIndexFirstOrDefaultAsync104.293 ms0.1521 ms0.4485 ms4.077 ms
NoShardingNoIndexFirstOrDefaultAsync10823.382 ms16.0849 ms18.5233 ms821.221 ms
ShardingNoIndexFirstOrDefaultAsync10892.276 ms17.8131 ms16.6623 ms894.880 ms
NoShardingNoIndexCountAsync10830.754 ms16.5309 ms38.6405 ms821.736 ms
ShardingNoIndexCountAsync10915.630 ms8.8511 ms7.3911 ms914.107 ms
NoShardingNoIndexLikeToListAsync107,008.918 ms139.4664 ms166.0248 ms6,955.674 ms
ShardingNoIndexLikeToListAsync107,044.168 ms135.3814 ms132.9626 ms7,008.057 ms
NoShardingNoIndexToListAsync10787.129 ms10.5812 ms8.8357 ms785.798 ms
ShardingNoIndexToListAsync10935.880 ms16.3354 ms15.2801 ms940.369 ms

mysql 5.7,data rows 7553790=755w innerdb_buffer_size=3G

// * Summary *

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1500 (1909/November2019Update/19H2)
AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
.NET SDK=6.0.100
[Host] : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT
DefaultJob : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT

MethodNMeanErrorStdDevMedian
NoShardingIndexFirstOrDefaultAsync105.020 ms0.1245 ms0.3672 ms4.855 ms
ShardingIndexFirstOrDefaultAsync107.960 ms0.1585 ms0.2514 ms7.974 ms
NoShardingNoIndexFirstOrDefaultAsync1011,336.083 ms623.8044 ms1,829.5103 ms11,185.590 ms
ShardingNoIndexFirstOrDefaultAsync105,422.259 ms77.5386 ms72.5296 ms5,390.019 ms
NoShardingNoIndexCountAsync1014,229.819 ms82.8929 ms77.5381 ms14,219.773 ms
ShardingNoIndexCountAsync103,085.268 ms55.5942 ms49.2828 ms3,087.704 ms
NoShardingNoIndexLikeToListAsync1027,046.390 ms71.2034 ms59.4580 ms27,052.316 ms
ShardingNoIndexLikeToListAsync105,707.009 ms106.8713 ms99.9675 ms5,672.453 ms
NoShardingNoIndexToListAsync1026,001.850 ms89.2787 ms69.7030 ms25,998.407 ms
ShardingNoIndexToListAsync105,490.659 ms71.8199 ms67.1804 ms5,477.891 ms

具体可以通过first前两次结果来计算得出结论单次查询的的损耗为0.2-0.3毫秒之间,通过数据聚合和数据路由的损耗单次在0.3ms-0.4ms,其中创建dbcontext为0.1毫秒目前没有好的优化方案,0.013毫秒左右是路由表达式解析和编译,复杂表达式可能更加耗时,剩下的0.2毫秒为数据源和表后缀的解析等操作包括实例的反射创建和数据的聚合，
sqlserver的各项数据在分表和未分表的情况下都几乎差不多可以得出在770w数据集情况下数据库还并未是数据瓶颈的关键，但是mysql可以看到在分表和未分表的情况下如果涉及到没有索引的全表扫描那么性能的差距将是分表后的表数目之多，测试中为5-6倍，也就是分表数目

如果你可以接受单次查询的损耗在0.2ms-0.3ms的那相信这款框架将会是efcore下非常完美的一款分表分库组件

链接模式

说了这么多这边需要针对ShardingCore在查询下面涉及到N表查询后带来的链接消耗是一个不容小觑的客观因素。所以这边参考ShardingSphere进行了类似原理的实现。就是如果查询涉及不同库那么直接并发，如果是同库的将根据用户配置的单次最大链接进行串行查询，并且动态选择使用流式聚合和内存聚合。

首先我们看下ShardingSphere的链接模式在限制链接数的情况下是如何进行处理的
9c7c412de001b38564d2073cccd40203.png
针对不同的数据库采用并行执行，针对同一个数据库根据用户配置的最大连接数进行分库串行执行，并且因为需要控制链接数所以会将结果集保存在内存中，最后通过合并返回给客户端数据。
之后我们会讲这个模式的缺点并且ShardingCore是如何进行优化的

你可能已经蒙了这么多名称完全没有一个概念。接下来我将一一进行讲解,首先我们来看下链接模式下有哪些参数

MaxQueryConnectionsLimit

最大并发链接数，就是表示单次查询sharding-core允许使用的dbconnection，默认会加上1就是说如果你配置了MaxQueryConnectionsLimit=10那么实际sharding-core会在同一次查询中开启11条链接最多,为什么是11不是10因为sharding-core会默认开启一个链接用来进行空dbconnection的使用。如果不设置本参数那么默认是cpu线程数Environment.ProcessorCount

ConnectionMode

链接模式,可以由用户自行指定，使用内存限制,和连接数限制或者系统自行选择最优

链接模式，有三个可选项，分别是：

MEMORY_STRICTLY

内存限制模式最小化内存聚合 流式聚合 同时会有多个链接

MEMORY_STRICTLY的意思是最小化内存使用率，就是非一次性获取所有数据然后采用流式聚合

CONNECTION_STRICTLY

连接数限制模式最小化并发连接数 内存聚合 连接数会有限制

CONNECTION_STRICTLY的意思是最小化连接并发数，就是单次查询并发连接数为设置的连接数MaxQueryConnectionsLimit。因为有限制，所以无法一直挂起多个连接，数据的合并为内存聚合采用最小化内存方式进行优化，而不是无脑使用内存聚合

SYSTEM_AUTO

系统自动选择内存还是流式聚合

系统自行选择会根据用户的配置采取最小化连接数，但是如果遇到分页则会根据分页策略采取内存限制，因为skip过大会导致内存爆炸

解释

MEMORY_STRICTLY

MEMORY_STRICTLY内存严格模式，用户使用本属性后将会严格控制查询的聚合方式，将会采用流式聚合的迭代器模式，而不是一次性全部去除相关数据在内存中排序获取，通过用户配置的MaxQueryConnectionsLimit连接数来进行限制，比如MaxQueryConnectionsLimit=2，并且本次查询涉及到一个库3张表，因为程序只允许单次查询能并发2个链接，所以本次查询会被分成2组每组两个，其中第二组只有一个，在这种情况下第一次并发查询2条语句因为采用内存严格所以不会将数据获取到内存，第二次在进行一次查询并将迭代器返回一共组合成3个迭代器后续通过流式聚合+优先级队列进行返回所要的数据，在这种情况下程序的内存是最少的但是消耗的链接也是最大的。当用户手动选择MEMORY_STRICTLY后MaxQueryConnectionsLimit将变成并行数目. 该模式下ShardingCore和ShardingSphere的处理方式类似基本一致
dba7853c4e8564cce8c23125c5bb933c.png

CONNECTION_STRICTLY

CONNECTION_STRICTLY连接数严格模式，用户使用本属性后将会严格控制查询后的同一个数据库下的同时查询的链接数，不会因为使用流式内存而导致迭代器一致开着，因为一个迭代器查询开着就意味着需要一个链接，如果查询需要聚合3张表那么就需要同时开着三个链接来迭代保证流式聚合。通过用户配置的MaxQueryConnectionsLimit连接数来进行限制，比如MaxQueryConnectionsLimit=2，并且本次查询涉及到一个库3张表，因为程序只允许单次查询能并发2个链接，所以本次查询会被分成2组每组两个，其中第二组只有一个，在这种情况下第一次并发查询2条语句因为采用连接数严格所以不会一直持有链接，会将链接结果进行每组进行合并然后将连接放回，合并时还是采用的流式聚合，会首先将第一组的两个链接进行查询之后将需要的结果通过流式聚合取到内存，然后第二组会自行独立查询并且从第二次开始后会将上一次迭代的内存聚合数据进行和本次查询的流式聚合分别一起聚合，保证在分页情况下内存数据量最少。因为如果每组都是用独立的内存聚合那么你有n组就会有n*(skip+take)的数目，而ShardingSphere采用的是更加简单的做法，就是将每组下面的各自节点都自行进行内存聚合，那么如果在skip(10).take(10)的情况下sql会被改写成各组的各个节点分别进行skip(0).take(20)的操作那么2组执行器的第一组将会有40条数据第二组将会有20条数据一共会有60条数据远远操作了我们所需要的20条。所以在这个情况下ShardingCore第一组内存流式聚合会返回20条数据，第二组会将第一组的20条数据和第二组的进行流式聚合内存中还是只有20条数据，虽然是连接数严格但是也做到了最小化内存单元。当用户手动选择CONNECTION_STRICTLY后MaxQueryConnectionsLimit将是正则的最小化链接数限制

5fb9bd4d1bbf885440d683d17b9d4c0f.png

SYSTEM_AUTO

SYSTEM_AUTO系统自行选择，这是一个非常帮的选择，因为在这个选择下系统会自动根据用户配置的MaxQueryConnectionsLimit来自行控制是采用流式聚合还是内存聚合，并且因为我们采用的是同数据库下面最小化内存相比其他的解决方案可以更加有效和高性能的来应对各种查询。仅仅只需要配置一个最大连接数限制既可以适配好连接模式。

这边极力推荐大家在不清楚应该用什么模式的时候使用SYSTEM_AUTO并且手动配置MaxQueryConnectionsLimit来确定各个环境下的配置一直而不是采用默认的cpu线程数。

首先我们通过每个数据库被路由到了多少张表进行计算期望用户在配置了xx后应该的并行数来进行分组,sqlCount :表示这个数据库被路由到的表数目，exceptCount :表示计算出来的应该的单次查询并行数

//代码本质就是向上取整int exceptCount =Math.Max(0 == sqlCount % maxQueryConnectionsLimit? sqlCount / maxQueryConnectionsLimit: sqlCount / maxQueryConnectionsLimit + 1, 1);

第二次我们通过判断sqlCount和maxQueryConnectionsLimit的大小来确定链接模式的选择

private ConnectionModeEnum CalcConnectionMode(int sqlCount){switch (_shardingConfigOption.ConnectionMode){case ConnectionModeEnum.MEMORY_STRICTLY:case ConnectionModeEnum.CONNECTION_STRICTLY: return _shardingConfigOption.ConnectionMode;default:{return _shardingConfigOption.MaxQueryConnectionsLimit < sqlCount? ConnectionModeEnum.CONNECTION_STRICTLY: ConnectionModeEnum.MEMORY_STRICTLY; ;}}}

比较

针对ShardingSphere的流程图我们可以看到在获取普通数据的时候是没有什么问题的,但是如果遇到分页也就是

select * from order limit 10,10

这种情况下会被改写成

select * from order limit 0,20

我们可以看到如果是ShardingSphere的流程模式那么在各个节点处虽然已经将连接数控制好了但是对于每个节点而言都有着20条数据，这种情况下其实是一种非常危险的，因为一旦节点过多并且limit的跳过页数过多每个节点储存的数据将会非常恐怖。
3f82061ac599e2f26d2219855bcf81e2.png

所以针对这种情况ShardingCore将同库下的各个节点组的查询使用StreamMerge而不是MemoryMerge，并且会对各个节点间建立联系进行聚合保证在同一个数据库下只会有20条数据被加载到内存中，大大降低了内存的使用，提高了内存使用率。
68a2d2d38e9f0ff86ea557c089f5ad99.png

当然具体情况应该还需要再次进行优化并不是简单的一次优化就搞定的比如当跳过的页数过多之后其实在内存中的一部分数据也会再次进行迭代和新的迭代器比较，这个中间的性能差距可能需要不断地尝试才可以获取一个比较可靠的值

总结

目前已经有很多小伙伴已经在使用SharidingCore了并且在使用的时候也是相对比较简单的配置既可以“完美”目前她在使用的各种框架譬如:AbpVNext....基本上在继承和使用方面可以说是目前efcore生态下最最最完美的了真正做到了三零的框架：零依赖,零学习成本,零业务代码入侵

最后放一张图

是我这边给ShardingSphere提的建议,也证实了我对该聚合模型的优化是可以有效解决在分页下面聚合各数据库节点下的内存使用情况
c6f9e725f88ab3c752d98d5ba7617147.png

分表分库组件求赞求star

您的支持是开源作者能坚持下去的最大动力

  • Github ShardingCore

  • Gitee ShardingCoreShardingCore 一款ef-core下高性能、轻量级针对分表分库读写分离的解决方案，具有零依赖、零学习成本、零业务代码入侵。

    Github Source Code 助力dotnet 生态 Gitee Source Code

    介绍

    在分表分库领域java有着很多的解决方案,尤其是客户端解决方案(ShardingSphere)，因为客户端解决方案有着极高的性能,但是缺点也很明显数据库链接的消耗相对较高，使用语言的限制让我们.Net望而却步，但是哪怕是有着这些缺点其实也不足以掩盖客户端分表分库带来的便捷与高效。
    目前本人所开发的ShardingCore 是.Net下基于efcore2+的所有版本的分表分库很多都是借鉴了ShardingSphere,并且对其很多缺点进行了弥补。这边可能有人就要说了，你为什么做个efcore的不做个ado.net的呢，说实话我这边确实有一个ado.net版本的分表分库，你可以理解为ShardingSphere的.Net复刻版本sharding-conector 最最最初版本的分表聚合已经实现底层原理和ShardingSphere一致使用的Antlr4的分词。为什么不对这个版本进行推进转而对efcore的sharding-core版本进行升级维护呢，这边主要有两点，第一点如果我是在ado.net上进行的推进那么势必可以支持更多的orm框架，但是orm框架下的很多特性将可能无法使用，并且需要维护各个数据库版本之间的差异。比如efcore下的批量操作等一些列优化语法是很难被支持的。第二点针对某个orm的扩展性能和使用体验上远远可以大于通用性组件。这就是我为什么针对ShardingCore进行有段优化和升级的原因。

    性能

    其实性能一直是大家关注的一个点，我用了ShardingCore那么针对特定的查询他的损耗是多少是一个比较令人关注的话题。接下来我放出之前做的两次性能比较，当然这两次比较并不是特意准备的，是我边开发边跑的一个是sqlserver 一个是mysql

    性能测试

    以下所有数据均在开启了表达式编译缓存的情况下测试，并且电脑处于长时间未关机并且开着很多vs和idea的情况下仅供参考,所有测试都是基于ShardingCore x.3.1.63+ version

    以下所有数据均在源码中有案例

    efcore版本均为6.0 表结构为string型id的订单取模分成5张表

    N代表执行次数

    sql server 2012,data rows 7734363 =773w

    // * Summary *

    BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1500 (1909/November2019Update/19H2)
    AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
    .NET SDK=6.0.100
    [Host] : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT
    DefaultJob : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT

    MethodNMeanErrorStdDevMedian
    NoShardingIndexFirstOrDefaultAsync102.154 ms0.1532 ms0.4443 ms1.978 ms
    ShardingIndexFirstOrDefaultAsync104.293 ms0.1521 ms0.4485 ms4.077 ms
    NoShardingNoIndexFirstOrDefaultAsync10823.382 ms16.0849 ms18.5233 ms821.221 ms
    ShardingNoIndexFirstOrDefaultAsync10892.276 ms17.8131 ms16.6623 ms894.880 ms
    NoShardingNoIndexCountAsync10830.754 ms16.5309 ms38.6405 ms821.736 ms
    ShardingNoIndexCountAsync10915.630 ms8.8511 ms7.3911 ms914.107 ms
    NoShardingNoIndexLikeToListAsync107,008.918 ms139.4664 ms166.0248 ms6,955.674 ms
    ShardingNoIndexLikeToListAsync107,044.168 ms135.3814 ms132.9626 ms7,008.057 ms
    NoShardingNoIndexToListAsync10787.129 ms10.5812 ms8.8357 ms785.798 ms
    ShardingNoIndexToListAsync10935.880 ms16.3354 ms15.2801 ms940.369 ms

    mysql 5.7,data rows 7553790=755w innerdb_buffer_size=3G

    // * Summary *

    BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1500 (1909/November2019Update/19H2)
    AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
    .NET SDK=6.0.100
    [Host] : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT
    DefaultJob : .NET 6.0.0 (6.0.21.52210), X64 RyuJIT

    MethodNMeanErrorStdDevMedian
    NoShardingIndexFirstOrDefaultAsync105.020 ms0.1245 ms0.3672 ms4.855 ms
    ShardingIndexFirstOrDefaultAsync107.960 ms0.1585 ms0.2514 ms7.974 ms
    NoShardingNoIndexFirstOrDefaultAsync1011,336.083 ms623.8044 ms1,829.5103 ms11,185.590 ms
    ShardingNoIndexFirstOrDefaultAsync105,422.259 ms77.5386 ms72.5296 ms5,390.019 ms
    NoShardingNoIndexCountAsync1014,229.819 ms82.8929 ms77.5381 ms14,219.773 ms
    ShardingNoIndexCountAsync103,085.268 ms55.5942 ms49.2828 ms3,087.704 ms
    NoShardingNoIndexLikeToListAsync1027,046.390 ms71.2034 ms59.4580 ms27,052.316 ms
    ShardingNoIndexLikeToListAsync105,707.009 ms106.8713 ms99.9675 ms5,672.453 ms
    NoShardingNoIndexToListAsync1026,001.850 ms89.2787 ms69.7030 ms25,998.407 ms
    ShardingNoIndexToListAsync105,490.659 ms71.8199 ms67.1804 ms5,477.891 ms

    具体可以通过first前两次结果来计算得出结论单次查询的的损耗为0.2-0.3毫秒之间,通过数据聚合和数据路由的损耗单次在0.3ms-0.4ms,其中创建dbcontext为0.1毫秒目前没有好的优化方案,0.013毫秒左右是路由表达式解析和编译,复杂表达式可能更加耗时,剩下的0.2毫秒为数据源和表后缀的解析等操作包括实例的反射创建和数据的聚合，
    sqlserver的各项数据在分表和未分表的情况下都几乎差不多可以得出在770w数据集情况下数据库还并未是数据瓶颈的关键，但是mysql可以看到在分表和未分表的情况下如果涉及到没有索引的全表扫描那么性能的差距将是分表后的表数目之多，测试中为5-6倍，也就是分表数目

    如果你可以接受单次查询的损耗在0.2ms-0.3ms的那相信这款框架将会是efcore下非常完美的一款分表分库组件

    链接模式

    说了这么多这边需要针对ShardingCore在查询下面涉及到N表查询后带来的链接消耗是一个不容小觑的客观因素。所以这边参考ShardingSphere进行了类似原理的实现。就是如果查询涉及不同库那么直接并发，如果是同库的将根据用户配置的单次最大链接进行串行查询，并且动态选择使用流式聚合和内存聚合。

    首先我们看下ShardingSphere的链接模式在限制链接数的情况下是如何进行处理的
    e23652f527eea4922206eaedfa4da020.png
    针对不同的数据库采用并行执行，针对同一个数据库根据用户配置的最大连接数进行分库串行执行，并且因为需要控制链接数所以会将结果集保存在内存中，最后通过合并返回给客户端数据。
    之后我们会讲这个模式的缺点并且ShardingCore是如何进行优化的

    你可能已经蒙了这么多名称完全没有一个概念。接下来我将一一进行讲解,首先我们来看下链接模式下有哪些参数

    MaxQueryConnectionsLimit

    最大并发链接数，就是表示单次查询sharding-core允许使用的dbconnection，默认会加上1就是说如果你配置了MaxQueryConnectionsLimit=10那么实际sharding-core会在同一次查询中开启11条链接最多,为什么是11不是10因为sharding-core会默认开启一个链接用来进行空dbconnection的使用。如果不设置本参数那么默认是cpu线程数Environment.ProcessorCount

    ConnectionMode

    链接模式,可以由用户自行指定，使用内存限制,和连接数限制或者系统自行选择最优

    链接模式，有三个可选项，分别是：

    MEMORY_STRICTLY

    内存限制模式最小化内存聚合 流式聚合 同时会有多个链接

    MEMORY_STRICTLY的意思是最小化内存使用率，就是非一次性获取所有数据然后采用流式聚合

    CONNECTION_STRICTLY

    连接数限制模式最小化并发连接数 内存聚合 连接数会有限制

    CONNECTION_STRICTLY的意思是最小化连接并发数，就是单次查询并发连接数为设置的连接数MaxQueryConnectionsLimit。因为有限制，所以无法一直挂起多个连接，数据的合并为内存聚合采用最小化内存方式进行优化，而不是无脑使用内存聚合

    SYSTEM_AUTO

    系统自动选择内存还是流式聚合

    系统自行选择会根据用户的配置采取最小化连接数，但是如果遇到分页则会根据分页策略采取内存限制，因为skip过大会导致内存爆炸

    解释

    MEMORY_STRICTLY

    MEMORY_STRICTLY内存严格模式，用户使用本属性后将会严格控制查询的聚合方式，将会采用流式聚合的迭代器模式，而不是一次性全部去除相关数据在内存中排序获取，通过用户配置的MaxQueryConnectionsLimit连接数来进行限制，比如MaxQueryConnectionsLimit=2，并且本次查询涉及到一个库3张表，因为程序只允许单次查询能并发2个链接，所以本次查询会被分成2组每组两个，其中第二组只有一个，在这种情况下第一次并发查询2条语句因为采用内存严格所以不会将数据获取到内存，第二次在进行一次查询并将迭代器返回一共组合成3个迭代器后续通过流式聚合+优先级队列进行返回所要的数据，在这种情况下程序的内存是最少的但是消耗的链接也是最大的。当用户手动选择MEMORY_STRICTLY后MaxQueryConnectionsLimit将变成并行数目. 该模式下ShardingCore和ShardingSphere的处理方式类似基本一致
    af8f694d6ea68042fa7d8d9f696eafa5.png

    CONNECTION_STRICTLY

    CONNECTION_STRICTLY连接数严格模式，用户使用本属性后将会严格控制查询后的同一个数据库下的同时查询的链接数，不会因为使用流式内存而导致迭代器一致开着，因为一个迭代器查询开着就意味着需要一个链接，如果查询需要聚合3张表那么就需要同时开着三个链接来迭代保证流式聚合。通过用户配置的MaxQueryConnectionsLimit连接数来进行限制，比如MaxQueryConnectionsLimit=2，并且本次查询涉及到一个库3张表，因为程序只允许单次查询能并发2个链接，所以本次查询会被分成2组每组两个，其中第二组只有一个，在这种情况下第一次并发查询2条语句因为采用连接数严格所以不会一直持有链接，会将链接结果进行每组进行合并然后将连接放回，合并时还是采用的流式聚合，会首先将第一组的两个链接进行查询之后将需要的结果通过流式聚合取到内存，然后第二组会自行独立查询并且从第二次开始后会将上一次迭代的内存聚合数据进行和本次查询的流式聚合分别一起聚合，保证在分页情况下内存数据量最少。因为如果每组都是用独立的内存聚合那么你有n组就会有n*(skip+take)的数目，而ShardingSphere采用的是更加简单的做法，就是将每组下面的各自节点都自行进行内存聚合，那么如果在skip(10).take(10)的情况下sql会被改写成各组的各个节点分别进行skip(0).take(20)的操作那么2组执行器的第一组将会有40条数据第二组将会有20条数据一共会有60条数据远远操作了我们所需要的20条。所以在这个情况下ShardingCore第一组内存流式聚合会返回20条数据，第二组会将第一组的20条数据和第二组的进行流式聚合内存中还是只有20条数据，虽然是连接数严格但是也做到了最小化内存单元。当用户手动选择CONNECTION_STRICTLY后MaxQueryConnectionsLimit将是正则的最小化链接数限制

    6d8c9836d41a12f303c782a15152054d.png

    SYSTEM_AUTO

    SYSTEM_AUTO系统自行选择，这是一个非常帮的选择，因为在这个选择下系统会自动根据用户配置的MaxQueryConnectionsLimit来自行控制是采用流式聚合还是内存聚合，并且因为我们采用的是同数据库下面最小化内存相比其他的解决方案可以更加有效和高性能的来应对各种查询。仅仅只需要配置一个最大连接数限制既可以适配好连接模式。

    这边极力推荐大家在不清楚应该用什么模式的时候使用SYSTEM_AUTO并且手动配置MaxQueryConnectionsLimit来确定各个环境下的配置一直而不是采用默认的cpu线程数。

    首先我们通过每个数据库被路由到了多少张表进行计算期望用户在配置了xx后应该的并行数来进行分组,sqlCount :表示这个数据库被路由到的表数目，exceptCount :表示计算出来的应该的单次查询并行数

    //代码本质就是向上取整int exceptCount =Math.Max(0 == sqlCount % maxQueryConnectionsLimit? sqlCount / maxQueryConnectionsLimit: sqlCount / maxQueryConnectionsLimit + 1, 1);

    第二次我们通过判断sqlCount和maxQueryConnectionsLimit的大小来确定链接模式的选择

    private ConnectionModeEnum CalcConnectionMode(int sqlCount){switch (_shardingConfigOption.ConnectionMode){case ConnectionModeEnum.MEMORY_STRICTLY:case ConnectionModeEnum.CONNECTION_STRICTLY: return _shardingConfigOption.ConnectionMode;default:{return _shardingConfigOption.MaxQueryConnectionsLimit < sqlCount? ConnectionModeEnum.CONNECTION_STRICTLY: ConnectionModeEnum.MEMORY_STRICTLY; ;}}}

    比较

    针对ShardingSphere的流程图我们可以看到在获取普通数据的时候是没有什么问题的,但是如果遇到分页也就是

    select * from order limit 10,10

    这种情况下会被改写成

    select * from order limit 0,20

    我们可以看到如果是ShardingSphere的流程模式那么在各个节点处虽然已经将连接数控制好了但是对于每个节点而言都有着20条数据，这种情况下其实是一种非常危险的，因为一旦节点过多并且limit的跳过页数过多每个节点储存的数据将会非常恐怖。
    300401689427e131e8b3c28a3390bdc5.png

    所以针对这种情况ShardingCore将同库下的各个节点组的查询使用StreamMerge而不是MemoryMerge，并且会对各个节点间建立联系进行聚合保证在同一个数据库下只会有20条数据被加载到内存中，大大降低了内存的使用，提高了内存使用率。
    30ad3b50e88397ac1e80257ac354913e.png

    当然具体情况应该还需要再次进行优化并不是简单的一次优化就搞定的比如当跳过的页数过多之后其实在内存中的一部分数据也会再次进行迭代和新的迭代器比较，这个中间的性能差距可能需要不断地尝试才可以获取一个比较可靠的值

    总结

    目前已经有很多小伙伴已经在使用SharidingCore了并且在使用的时候也是相对比较简单的配置既可以“完美”目前她在使用的各种框架譬如:AbpVNext....基本上在继承和使用方面可以说是目前efcore生态下最最最完美的了真正做到了三零的框架：零依赖,零学习成本,零业务代码入侵

    最后放一张图

    是我这边给ShardingSphere提的建议,也证实了我对该聚合模型的优化是可以有效解决在分页下面聚合各数据库节点下的内存使用情况
    81abea9eb35a54d5bddab875ace07506.png

    分表分库组件求赞求star

    您的支持是开源作者能坚持下去的最大动力

    • Github ShardingCore: https://github.com/xuejmnet/sharding-core

    • Gitee ShardingCore: https://gitee.com/dotnetchina/sharding-core 

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/294493.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

php 利用http上传协议(表单提交上传图片 )

php 利用http上传协议(表单提交上传图片 )

主要就是利用php 的 fsocketopen 消息传输。 这里先通过upload.html 文件提交&#xff0c;利用chrome抓包&#xff0c;可以看到几个关键的信息。 首先指定了表单类型为multipart/form-data;。 boundary是分隔符 因为上传文件不在使用原有的http协议了。请求内容不再可能以 x…
阅读更多...
重新认识Docker Compose之Sidecar模式

重新认识Docker Compose之Sidecar模式

什么是Docker Compose在微服务盛行的今天&#xff0c;我们通常是这么定义Compose的&#xff1a;对容器的统一启动和关闭的编排工具。但是我以前还是有个疑惑&#xff0c;谁会用Compose在一台服务器上部署多个服务呢&#xff1f;干脆直接用单体服务就行了&#xff01;直到我遇到…
阅读更多...
数学家看到就把持不住，高斯被它迷得神魂颠倒，2600年的数学史里的一个奇迹……...

数学家看到就把持不住，高斯被它迷得神魂颠倒，2600年的数学史里的一个奇迹……...

全世界只有3.14 % 的人关注了爆炸吧知识数学的美两个字就能说清数学女神很可能是个洁癖她的苛刻就体现在公式里那每一个符号每一个数字都不允许有哪怕一点杂质如此才是她最认可的孩子因为知道了勾股定理古人们才创造了辉煌因为有了经典力学公式人类才能探索星辰大海因为掌握了质…
阅读更多...
编程语言也环保？C语言领跑，Python、Perl垫底

编程语言也环保？C语言领跑，Python、Perl垫底

文 | Travis出品 | OSC开源社区&#xff08;ID&#xff1a;oschina2013&#xff09;毋庸置疑&#xff0c;Python 是世界上最流行的编程语言之一&#xff0c;其被广泛运用于人工智能、数据分析、网络爬虫和 Web 开发等领域。在上个月的 TIOBE 榜单中&#xff0c;Python 一举超过…
阅读更多...
我靠“读书笔记”闷声赚3万：那些你看不上的行业，往往最赚钱

我靠“读书笔记”闷声赚3万：那些你看不上的行业，往往最赚钱

全世界只有3.14 % 的人关注了爆炸吧知识你有没有计算过&#xff1a;你的时间&#xff0c;值多少钱&#xff1f;如果你月薪5000&#xff0c;一个月工作20天&#xff0c;每天8小时&#xff0c;那么你1小时的价值就是32元。然而&#xff0c;现在请一个打扫卫生的钟点工&#xff0c…
阅读更多...
微信企业号开发之如何建立连接

微信企业号开发之如何建立连接

http://www.07net01.com/2014/09/167991.html 连接将使你的企业号更具价值&#xff0c;你可以使用以下三种方式&#xff0c;连接你的企业号及企业应用&#xff1a; 1、企业应用调用企业号提供的接口&#xff0c;管理或查询企业号后台所管理的资源、或给成员发送消息等&#xff…
阅读更多...
完全颠覆你世界观的10个科学实验！从此脑洞大开

完全颠覆你世界观的10个科学实验！从此脑洞大开

全世界只有3.14 % 的人关注了爆炸吧知识这两天超模君逛知乎时&#xff0c;发现有人提问&#xff1a;“如何让孩子学会主动”&#xff1f;孩子学会主动是很重要的&#xff0c;特别是在学习方面&#xff0c;懂得主动学习无论是在小时候还是未来都很有优势。可能很多家长都有类似的…
阅读更多...
char varchar java_在数据库中varchar与char的区别

char varchar java_在数据库中varchar与char的区别

char是固定长度类型varchar是可变的长度类型char和varchar类型相似&#xff0c;但是它们的存储和检索方式不同。在MySQL5.0.3&#xff0c;它们在最大长度和是否保留尾部空格也不相同。char和varchar定义了字符串的最大长度。例如&#xff0c;char(30)可以放30个字符。char列的长…
阅读更多...
震撼世界的基建狂魔，中国制造的超级工程到底有多牛？

震撼世界的基建狂魔，中国制造的超级工程到底有多牛？

全世界只有3.14 % 的人关注了数据与算法之美1949年的中华大地上一无所有&#xff0c;而现在一栋栋高楼伫立在这片土地上的时候不禁感叹&#xff0c;到底是什么支撑着让我们从一片荒漠变成如今高楼耸立&#xff1f;今天小编带来的这部纪录片《超级工程》&#xff0c;带你认识被称…
阅读更多...
C# WPF图表控件之ChartControl用法指南①

C# WPF图表控件之ChartControl用法指南①

“ 引言部分&#xff0c;总领全篇文章的中心内容。”WPF的DevExpress ChartControl是一种功能强大的可视化工具&#xff0c;可帮助您将数据显示为二维或伪三维条形图、区域、线和许多其他形式。01—将数据绑定到Chart SeriesStep 1. 创建新项目并添加图表创建一个新的WPF应用程…
阅读更多...
Android之SwipeRefreshLayout

Android之SwipeRefreshLayout

wipeRefreshLayout字面意思就是下拉刷新的布局，继承自ViewGroup，在support v4兼容包下，但必须把你的support library的版本升级到19.1。 提到下拉刷新大家一定对ActionBarPullToRefresh比较熟悉，而如今google推出了更官方的下拉刷新组件，这无疑是对开发者来说比较好的消…
阅读更多...
你以后会不会有小三？

你以后会不会有小三？

1 千万别碰到小孩就去逗他&#xff08;素材来源网络&#xff0c;侵删&#xff09;▼2 像极了早上刚睡醒炸毛的你▼3 乞丐和社畜的区别▼4 当你学校装了能上网的平板后&#xff08;素材来源网络&#xff0c;侵删&#xff09;▼5 看图写字&#xff08;素材来源网络&#xff0…
阅读更多...
CSharp 如何OCR离线识别文本

CSharp 如何OCR离线识别文本

WPF开发者QQ群&#xff1a; 340500857 | 微信群 -> 进入公众号主页 加入组织由于微信群人数太多入群请添加小编微信号&#xff08;yanjinhuawechat&#xff09;或&#xff08;W_Feng_aiQ&#xff09;邀请入群&#xff08;需备注WPF开发者&#xff09;本项目是基于开源项目P…
阅读更多...
第一个h5页面

第一个h5页面

不废话&#xff0c;先爆照&#xff0c;不好勿喷 我用的软件是WebStorm开发&#xff0c;然后也知道了h5我们可以用谷歌浏览器点击右键&#xff0c;然后点击审查&#xff0c;就可以按照手机屏幕来看到页面 下面是项目的图片 这个是我的index.html文件 <!doctype html> <…
阅读更多...
Ubuntu系统备份和恢复

Ubuntu系统备份和恢复

为什么80%的码农都做不了架构师&#xff1f;>>> 安装好Ubuntu之后&#xff0c;别忘了安装 for linux 防火墙和杀毒软件。在备份系统前&#xff0c;请保证系统是无错和干净的&#xff1a;本人操作系统是ubuntu14.04&#xff0c;不知道是系统出了问题还是装的软件有问…
阅读更多...
热血致敬！曾影响几代科学巨匠的传奇经典，至今仍无人能超越！

热血致敬！曾影响几代科学巨匠的传奇经典，至今仍无人能超越！

▲ 点击查看有人说&#xff0c;世界上有两本神书&#xff0c;一本是霍金的《时间简史》&#xff0c;是可以不看&#xff0c;但书架必须得有。还有一本&#xff0c;就是必须有也必须看的书&#xff0c;这就是《从一到无穷大》。2018年&#xff0c;清华大学校长&#xff0c;将这本…
阅读更多...
.NET 6 中 gRPC 的新功能

.NET 6 中 gRPC 的新功能

gRPC是一个现代的、跨平台的、高性能的 RPC 框架。gRPC for .NET 构建在 ASP.NET Core 之上&#xff0c;是我们推荐的在 .NET 中构建 RPC 服务的方法。.NET 6 进一步提高了 gRPC 已经非常出色的性能&#xff0c;并添加了一系列新功能&#xff0c;使 gRPC 在现代云原生应用程序中…
阅读更多...
这，像极了爱情！

这，像极了爱情！

全世界只有3.14 % 的人关注了爆炸吧知识特别的爱给特别的你古希腊数学家普罗克洛斯说过&#xff1a;“数学就是这样一种东西&#xff1a;她提醒你有无形的灵魂&#xff0c;她赋予她所发现的真理以生命&#xff1b;她唤起心神&#xff0c;澄净智慧&#xff1b;她给我们的内心思想…
阅读更多...
mysql 调用未定义函数_php – Wierd和Annoying错误：调用未定义的函数mysql_query()[复制]...

mysql 调用未定义函数_php – Wierd和Annoying错误：调用未定义的函数mysql_query()[复制]...

参见英文答案 > Why shouldn’t I use mysql_* functions in PHP? 15个我已经在这一个超过一个小时了,我可以连接到我的数据库和所有(不会给出任何错误)但是当我尝试使用时我收到以下错误“的mysql_query($查询);”Call to undefined f…
阅读更多...
ZABBIX2.4.8监控 Windows Mysql数据库

ZABBIX2.4.8监控 Windows Mysql数据库

2019独角兽企业重金招聘Python工程师标准>>> 系统环境&#xff1a; 操作系统&#xff1a;Windows Server 2012 ZABBIX Server&#xff1a;2.4.8 IP地址&#xff1a;192.168.0.77 模板脚本地址&#xff1a;http://pan.baidu.com/s/1eSDaiS6 ZABBIX客户端操作 1、在za…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023