Mongo分库方案选型

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhglance/article/details/78288371

 

Mongo分库方案两种形式分析:

 

1. mongo sharding方式:

1.1. 深翻页的问题

举例:当mongo的分片是5片时,分页查询(如果按照创建时间倒叙查询)第一页,每页50条数据,则mongo sharding在每个分片上取50条数据,一共50*5条数据,然后进行汇总,计算出前50条正确数据作为返回结果。如果是翻页到1000页,那么mongo sharding需要从5个分片上分别查询50*1000=5万条条数据,然后汇总成50*1000*5 = 25万条数据,然后计算第1000页的数据,这样系统会占用很大的系统资源,很容易造成系统异常。这个问题暂时没有什么可以解决的办法。

1.2. mongo sharding再平衡时,有可能查询数据出现重复的问题

当mongo sharding根据 sharding key,将数据存入mongo的5个片(1,2,3,4,5)时,一般会产生5个分片数据不均匀的问题,假如1,2的分片数据较多,3,4,5的分片数据量较少,那么mongo sharding再平衡策略会将1,2分片上的数据平衡到3,4,5分片上,如果此时数据正在进行平衡,那么查询1,2分片上的数据平衡到3,4,5的那部分的数据时,而且没有命中索引的情况时,有可能出现重复数据的现象。现有的解决方式是,在晚上调用量少的时候进行数据平衡,白天数据访问量大的时候关闭再数据平衡。

1.3. mongo分片扩展

分片不能够无限扩大,实际使用中一般分成个位数分片,很难做到无限扩展。

1.4. sharding的key不能变更

sharding key 一旦指定,不可更改。更改之后,访问数据的分片逻辑会变,导致服务不可用。
 

2. 采用物理分库方式:

2.1 分库要自己代码实现

需要自己代码中实现根据不同的context访问不同的数据库,即实现根据分库的key,路由到不同的物理库上。

2.2 不同的分库交叉访问问题

不能够像mongo sharding那样直接交叉访问库,如果要进行交叉访问库,只能在程序中自己实现。

2.3 负载均衡

mongo sharding内部实现了负载均衡,如果采用物理分成多个mongo库,实现负载均衡需要自己代码实现。

 

阅读更多

没有更多推荐了,返回首页