你是个天才,你浑身是铁,碾的了多少钉子
MySQL单机的存储能力、连接数是有限的,它自身就很容易会成为系统的瓶颈。
当单表数据量在百万以里时,我们还可以通过添加从库、优化索引提升性能。
数据量朝着千万以上趋势增长,再怎么优化数据库,很多操作性能仍下降严重。为了减少数据库的负担,提升数据库响应速度,缩短查询时间,这时候就需要进行 分库分表 。
分库分表就是要将大量数据分散到多个数据库中,使每个数据库中数据量小响应速度快,以此来提升数据库整体性能。核心理念就是对数据进行切分( Sharding ),以及切分后如何对数据的快速定位与整合。
针对数据切分类型,大致可以分为:垂直(纵向)切分和水平(横向)切分两种。
业务间解耦,不同业务的数据进行独立的维护、监控、扩展
在高并发场景下,一定程度上缓解了数据库的压力
提升了开发的复杂度,由于业务的隔离性,很多表无法直接访问,必须通过接口方式聚合数据,
分布式事务管理难度增加
数据库还是存在单表数据量过大的问题,并未根本上解决,需要配合水平切分
库内分表虽然将表拆分,但子表都还是在同一个数据库实例中,只是解决了单一表数据量过
大的问题,并没有将拆分后的表分布到不同机器的库上,还在竞争同一个物理机的CPU、内存、网络IO。
分库分表则是将切分出来的子表,分散到不同的数据库中,从而使得单个表的数据量变小,
达到分布式的效果。
解决高并发时单库数据量过大的问题,提升系统稳定性和负载能力
业务系统改造的工作量不是很大
跨分片的事务一致性难以保证
跨库的join关联查询性能较差
扩容的难度和维护量较大
数据分片相对比较均匀,不易出现某个库并发访问的问题
这样同一个用户的数据都会存在同一个库里,用 userId 作为条件查询就很好定位了
但这种算法存在一些问题,当某一台机器宕机,本应该落在该数据库的请求就无法得到正确的
处理,这时宕掉的实例会被踢出集群,此时算法变成hash(userId) mod N-1,用户信息可能
就不再在同一个库中。
扩展性较差
单表数据量是可控的
水平扩展简单只需增加节点即可,无需对其他分片的数据进行迁移
能快速定位要查询的数据在哪个库
由于连续分片可能存在数据热点,如果按时间字段分片,有些分片存储最近时间段内的数据,
可能会被频繁的读写,而有些分片存储的历史数据,则很少被查询。
如果您觉得文章好看,欢迎点赞收藏加关注,一连三击呀,感谢!!☺☻