MongoDB文档指出,当一台服务器/副本不足以存储所有数据时,应该使用分片。
假设一个数据集可以扩展到100 1GB和1 1GB,并且在这两个数据集上执行相同的查询,我们可以说-
在5个分片中分片100 1GB,每个分片20 1GB,相当于在5个分片中分片1 1GB,每个分片200MB。比例因子会影响Mongo进行分片的方式吗?如果是,将在哪里观察到这些变化?
发布于 2015-04-24 11:13:45
假设一个数据集可以同时扩展到100 1GB和1 1GB,并且在这两个数据集上执行相同的查询,我们可以说-
在5个分片中分片100 1GB,每个分片20 1GB,相当于在5个分片中分片1 1GB,每个分片200MB
从高层次上看,您的两个示例中的sharded cluster architecture可能是相似的:5个分片、3个配置服务器和一些mongos进程。我不愿以同样的方式将其称为“等效”,因为轻便摩托车并不等同于摩托车,尽管在这个类比中两者都是两轮车辆,因此解释取决于您的观点。
但是,当然也可以从配置了资源(RAM/CPU/存储)的5分片集群开始,以满足特定的预期工作负载,然后使用资源升级(或降级)相同的集群,以满足您的用例不断变化的需求。
比例因子会影响Mongo进行分片的方式吗?如果是,将在哪里观察到这些变化?
基于分片数据量的主要行为差异将是sharded cluster balancing活动。平衡基于块,块是分片键值的逻辑连续范围,默认情况下表示大约64MB的数据。
分片之间的分块均衡是通过migration threshold触发的,根据分片集合中分块最少和最多的分片之间的差异以及分片集合中的总分块数:
| Number of Chunks | Migration Threshold |
|====================|=====================|
| Fewer than 20 | 2 |
| 20-79 | 4 |
| 80 and greater | 8 |对于每个分片只有100MB的数据,这大约是2个块(或大约10个)。
对于每个分片20 at的数据,每个分片至少有312个块(可能更多,因为块是抢先拆分的,而不是总是满的)。
如果您选择了一个好的分片键,可以有效的跨分片分发数据,那么应该不需要频繁的重新均衡。另一方面,糟糕的分片键将需要更频繁的平衡,并且由于额外的I/O开销,在规模上问题将更加明显。
https://stackoverflow.com/questions/29811951
复制相似问题