Mongo分库方案选型

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

1. mongo sharding方式：

1.1. 深翻页的问题。

举例：当mongo的分片是5片时，分页查询（如果按照创建时间倒叙查询）第一页，每页50条数据，则mongo sharding在每个分片上取50条数据，一共50 * 5 = 250条数据，然后进行汇总，计算出前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库，实现负载均衡需要自己代码实现。