作者回复: 这个地方详细说一下,比如只取用户ID后四位,为了保证后四位的哈希结果和完整用户ID的哈希结果是一样的,分片的数量需要能被10000整除。300个分片是不行的,200、250这种分片数量就是可以满足要求的。
作者回复: 👍👍👍
作者回复: 查表法一般可以配合哈希或者范围分片一起使用。
比如说,我们按用户ID哈希分成10个分片,其中第8个分片数据特别多不均匀。
那我们可以按用户ID哈希成100个逻辑分片。
再做一个100逻辑分片和10个物理分片的映射表,这个表里面只有100条记录。
那怎么来映射我们就可以人工分配,让10个物理分片中的数据尽量均匀。
作者回复: 如果需要分库分表还要跨表查询,这种情况下没有什么好的分页解决方案,业务还是要规避分库分表之后跨表查询的情况。
如果实在规避不了,就要考虑sharding key是不是合理,或者可能要更换数据库。
作者回复: 直接用用户ID哈希,计算出这个用户的订单在哪个分片上,然后去查询就可以了。
作者回复: 是的,一般是同步到其它的数据库中去解决。我会在19中来讲,如何做实时同步。
作者回复: 你说的没错!
作者回复: 1. 因为有可能用户的男女比例不同,造成分片不均衡,出现热点。
2. 如果要修改分片映射,一般的流程是:先完成扩容和数据复制,然后直接修改分片映射表。不需要修改代码。
作者回复: 比较方便的方法是扩容后的分片数量是24的整数倍,这样每个分片相当于1分n。或者在设计之初就采用一致性哈希算法来分片。
作者回复: 如果一亿的数据分12个月,那实际上每个月的表中大概是一千万左右的数据,这个量级的数据,在做好索引的前提下,查询不会很慢。
建议你先看一下查询的执行计划,找出为什么慢的原因。
另外,你没有提到表中的数据是否会频繁删除。如果频繁插入和删除数据的这张表,它的索引会越来越大,定期重建索引是有必要的。
作者回复: 是的
作者回复: 是这样的。
作者回复: 订单号是怎么构成的,应该算是商业秘密了。因为如果你知道它的规律,是有可能从中获得一些信息的。所以各家都不会公布自己的订单号是如何构成的。
作者回复: 因为取模的时候更快一些,如果是业务类的系统,这点儿差别可以忽略不计了。
如果你是做存储系统或者中间件类产品,还是需要考虑这个因素的。
作者回复: 某些场景下是可以的,具体还要根据业务情况来权衡。mycat的优点是对业务透明,不用修改代码,缺点是加长了调用链路,增加了故障点、降低了性能。
作者回复: 这种情况使用MySQL没有太好的解决方案,你可以看一下后面的19、22二节课,尝试使用其它的数据库来解决而你的问题。