备份库
mongodump -h 127.0.0.1 -d loginserver -o /root/data/soft/mongodb/backup/
恢复库
mongorestore -h 127.0.0.1 -d loginserver /root/data/soft/mongodb/backup/loginserver
删除库，在当前库下面执行
db.dropDatabase()
创建索引
db.users.createIndex({name:1})
db.users.createIndex({name:"hashed"})
启用分片
sh.enableSharding("loginserver")
创建片键
sh.shardCollection("loginserver.users", {"name":"hashed"})
mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5efa2a6d6e156de96ae022a6") } shards: { "_id" : "shard1_repl", "host" : "shard1_repl/172.31.140.157:27201,172.31.140.158:27201,172.31.140.159:27201", "state" : 1 } { "_id" : "shard2_repl", "host" : "shard2_repl/172.31.140.157:27202,172.31.140.158:27202,172.31.140.159:27202", "state" : 1 } { "_id" : "shard3_repl", "host" : "shard3_repl/172.31.140.157:27203,172.31.140.158:27203,172.31.140.159:27203", "state" : 1 } active mongoses: "3.4.4" : 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: no Balancer lock taken at Tue Jun 30 2020 01:52:49 GMT+0800 (CST) by ConfigServer:Balancer Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 9 : Success databases: { "_id" : "loginsaveserver", "primary" : "shard2_repl", "partitioned" : true } { "_id" : "gmserver", "primary" : "shard3_repl", "partitioned" : false } { "_id" : "webserver", "primary" : "shard3_repl", "partitioned" : false } { "_id" : "loginserver", "primary" : "shard1_repl", "partitioned" : true } loginserver.users shard key: { "name" : "hashed" } unique: false balancing: true chunks: shard1_repl 4 shard2_repl 1 { "name" : { "$minKey" : 1 } } -->> { "name" : NumberLong("-3886158847527038099") } on : shard1_repl Timestamp(2, 1) { "name" : NumberLong("-3886158847527038099") } -->> { "name" : NumberLong("2094497450232798455") } on : shard1_repl Timestamp(1, 2) { "name" : NumberLong("2094497450232798455") } -->> { "name" : NumberLong("2382442107794890264") } on : shard1_repl Timestamp(1, 3) { "name" : NumberLong("2382442107794890264") } -->> { "name" : NumberLong("5478317658905294769") } on : shard1_repl Timestamp(1, 4) { "name" : NumberLong("5478317658905294769") } -->> { "name" : { "$maxKey" : 1 } } on : shard2_repl Timestamp(2, 0) mongos>
片键：mongo使用一个或者几个字段的组合来分发数据到分片的标准，一旦形成了多个分片，再修改片键是不可能的事情
随着分片的增加（成千上百个）不能做遍历所有分片才能返回的结果的操作（慢！）
分片的目的是通过增加并行性来提高mongo的吞吐量（每秒处理的IO），而不是为了降低延迟；当然也增加了数据的总存储量
数据分发
分片中的数据是以数据块chunk来管理的，块是随机分发到每个分片中；当某一片的chunk太多时，mongo平衡器会自动迁移数据块到其他的分片上，来保持每个分片数据块的基本平衡。mongo路由只需要管理请求到数据块的映射即可。
升序片键
以id大小有序的范围形成一个一个的数据块，且新的写请求都是路由到同一个分片的同一个数据块中（maxCurrentId-$maxKey数据块）；mongo必须不断的才分这个不断膨胀的数据块，且迁移到其他分片中。
随机片键
以一种具有随机性的字段作为片键，电话、email、hash散列值等。这样写IO会比较均匀的路由到每个数据块；
片键策略
hash片键
Hashed shard keys use a hashed index of a field as the shard key to partition data across your sharded cluster
当集群使用片键分发数据时，hash片键使用的是字段的hash索引，所以先创建hash索引：
db.yourCollection.createIndex( { a: "hashed" } )
开启集合的hash分片
sh.shardCollection( "db.yourCollection", { a: "hashed" } )
对一个字段建立了hash索引后，还可以再建立普通的升序、降序的索引；使用范围比较的时候，mongo就会使用普通的索引
you can create both a hashed index and an ascending/descending (i.e. non-hashed) index on the same field: MongoDB will use the scalar index for range queries.
分片
1. 分片(sharding)是指将数据拆分，将其分散存放在不同的机器上的过程。有时也用分区(partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以
存储更多的数据，处理更大的负载。
2. MongoDB支持自动分片(autosharding)，可以使数据库架构对应用程序不可见，也可以简化系统管理。对应用程序而言，好像始终在使用一个单机的MongoDB服务器一样。另一方面，
mongoDB自动处理数据在分片上的分布，也更容易添加和删除分片技术。
3. 复制与分片的区别：复制时让多台服务器都拥有同样的数据副本，每一台服务器都是其他服务器的镜像，而每一个分片都和其他分片拥有不同的数据子集。
4. 路由服务器：为了对应用程序隐藏数据库架构的细节，在分片之前要先执行mongos进行一次路由过程。这个路由服务器维护这一个"内容列表"，指明了每个分片包含什么数据内容。应用
程序只需要连接路由服务器，就可以像使用单机一样进行正常的请求了。
5. 运行sh.status()可以看到集群的状态：分片摘要信心、数据库摘要信息、集合摘要信息。
6. 要对一个集合分片，首先你要对这个集合的数据库启用分片，执行如下命令：sh.enableSharding("test")
7. 片键：片键是集合的一个键，MongoDB根据这个键拆分数据。例如：username 。在启用分片之前，先在希望作为片键的键上创建索引：db.users.ensureIndex({"username":1})
8. 对集合分片：sh.shardCollection("test.users",{"username":1})
9. 集合被拆分为多个数据块，每个数据块都是集合的一个数据子集。这是按照片键的范围排列的({"username":minValue}-->>{"username":maxValue}指出了每个数据块的范围)。
10. 包含片键的查询能够直接被发送到目标分片或者是集群分片的一个子集。这样的查询叫做定向查询(targetd query)。有些查询必须被发送到所有分片，这样的查询叫做分散-聚合查询(
scatter-gather query);mongos将查询分散到所有的分片上，然后经各个分片的查询结果聚集起来。
11. cluster.stop() 关闭整个集群。
BSON类型
配置分片：
1. 何时进行分片：决定何时分片是一个值得权衡的问题。通常不必太早分片，因为分片不仅会增加部署的操作复杂度，还要求做出设计决策，而改决策以后很难再改。另外最好也不要在系统
运行太久之后再分片，因为在一个过载的系统上不停机进行分配是很困难的。
2. 分片的目的：增加可用的RAM，增加可用磁盘空间，减轻单台服务器的负载，处理单个mongod无法承受的吞吐量。
3. 一般情况下至少应该创建3个或者以上的分片。
4. 启动服务器：
1). 配置服务器：配置服务器相当于集群的大脑，保存着集群和分片的元数据，即各分片包含哪些数据的信息。因此，应该首先建立配置服务器，鉴于它所包含的的数据极端重要性，必须启用
其日志功能，并确保其数据保存在非易失性驱动器上。每个配置服务器都应该位于单独的物理机上，最好是分布在不同地址位置的机器上。
a. 启动配置服务器：mongod --configsvr --dbpath /var/lib/mongodb -f /var/lib/config/mognd.conf 。需要启动三台配置服务器，且都是可写的。
为什么是3台配置服务器？因为我们需要考虑不时之需。但是，也不需要过多的配置服务器，因为配置服务器上的确认操作比较耗时。另外，如果有服务器宕机了，集群源数据就会变成只读的。
--configsvr 选项指定mongod为新配置服务器。该选项并非必选项，因为它所做的不过是将mongod的默认监听端口改为27019，并大默认的数据目录改为/data/configdb而已(可以使用
--port 和 --dbpath 选项修改这两项配置)。但建议使用--configsvr选项，因为它比价直白地说明了这些配置服务器的用途。
配置服务器的1KB相当于200MB知识数据，它保存的真实数据的分布表。由于配置服务器并不需要太多的资源，因此可以将其部署在运行着其他程序的服务器上。
2). mongos进程：三个配置服务器均处于运行状态后，启动一个mongos进程供应用程序连接。mongos进程需要配置服务器的地址，所以必须使用--configdb选项启动mongos:
mongos --configdb config-1:27019,config-2:27019,config-3:27019 -f /var/lib/mongos.conf
默认情况下，mongos运行在27017端口。mongos本身不保存数据，它会在启动时从配置服务器加载集群数据。
可以启动任意数量的mongos进程。通常的设置时每个应用程序服务器使用一个mongos进程(与应用服务器运行在同一台机器上)
每个mongos进程必须按照列表排序，使用相同的配置服务器列表。
3). 将副本集转换为分片：有两种可能性：已经有一个副本集，或者从零开始建立集群。下例假设我们已经拥有了一个副本集。如果是从零开始的话，可先初始化一个空的副本集，然后按照本例操作。
a. 告知mongos副本集名称和副本集成员列表：sh.addShard("spock/server-1:27017,server-2:27017,server-4:27017") mongos能够自动检测到没有包含在副本集成员表中的成员。
b. 副本集作为分片添加到集群后，就可以将应用程序设置从连接到副本集改为连接到mongos。
c. 副本集名称spokc被作为分片名称。如果之后希望移除这个分片或者是向这个分片迁移数据，可以使用spock来标志这个分片。
d. 配置完分片后，必须将客户端设置为将所有请求发送到mongos，而不是副本集。同时配置防火墙规则，以确保客户端不能直接将请求发送到分片。
e. 有一个--shardsvr选项，与前面介绍的--configsvr选项类似，它也没什么实用性(只是将默认端口改为27018)，但在操作中建议使用该选项。
f. 不建议创建单mongod服务器分片(而不是副本集分片)，将单一服务器分片转换为副本集需要停机操作。
4). 增加集群容量：通过增加分片来增加集群容量。
5). 数据分片：除非明确指定规则，否则MongoDB不会自动对数据进行拆分。如果有必要，必须明确告知数据库和集合。加入对music数据库中的artists集合按照name进行分片，
db.enableSharding("music") 对数据库分片是对集合分片的先决条件
sh.shardCollection("music.artists",{"name":1}) 对集合分片，集合会按照name键进行分片。如果是对已存在的集合分片，那么name键上必须有索引，否则会返回错误。
shardCollection()命令会经集合拆分为多个数据块，这是MongoDB迁移数据的基本单元。命令执行后，MongoDB会均衡的将数据分散到集群的分片上。
5. MongoDB如何追踪集群数据
1). MongoDB将文档分组为块(chunk)，每个块由给定片键特定范围内的文档组成。一个块只存在于一个分片上，所以MongoDB用一个比较小的表就能够维护跟分片的映射。
2). 当一个块增长到特定大小时，MongoDB会自动将其拆分为两个较小的块。
3). 一个常见的误解释同一个块内的数据保存在磁盘的同一片区域。这是不正确的，块并不影响mongod保存集合数据的方式。
4). 块信息保存在config.chunks集合中。左闭右开。
5). 可以使用复合片键，工作方式与使用复合索引进行排序一样。
6). 拆分块：mongos会记录在每个块中插入了多少数据，一旦达到某个阈值，就会检查是否需要对块进行拆分。mongos就会在配置服务器更新这个块的源信息。块拆分中只需要改变块源数据即可，
而无需进行数据移动。进行拆分时，配置服务器会创建新的块文档，同时修改旧的块范围，拆分完成以后，mongos会重置对原始块的追踪器，同时为新的块创建新的追踪器。
7). 分片有时可能会找不到任何可用的拆分点，因为合法拆分块方法有限。具有相同片键的文档必须保存在相同的块中。
8). 如果mongos试图进行拆分时有一个服务器挂了，那么mongos就无法更新源数据。mongos不断重复发起拆分请求却无法进行拆分的过程，叫做拆分风暴。防止拆分风暴的唯一方法是尽可能保证
配置服务器的可用和健康。也可以重启mongos，重置引入计数器，这样他就不会再处于拆分阈值点了。
9). 如果mongos进程不断重启，它们的计数器可能永远也不会到达阈值点，因此块的增加不存在最大值，也就无法到达阈值点。
10). 防止无法拆分的两种方法：一是减少mongos进程的波动，二是使块的大小比实际预期小一些，这样就更容易达到拆分阈值点。
11). 可以在mongos启动时指定--nosplit选项，从而关闭块的拆分。
6. 均衡器：均衡器负责数据的迁移。它会周期性地检查分片间是否存在不均衡，如果存在，则会开始块的迁移。虽然均衡器通常被看成单一的实体，但每个mongos有时也会扮演均衡器的角色。
每隔几秒，mongos就会尝试变身均衡器。如果没有其他可用的均衡器，mongos就会对整个集群加锁，以防止配置服务器对整个集群进行修改，然后做一次均衡。
mongos成为均衡器后，就会检查每个集合的分块表，从而查看是否有分片达到了均衡阈值。
选择片键
1. 对集合进行分片时，要选择一或两个字段用于拆分数据，这个键就叫做片键。
2. 拆分数据最常用的数据分发方式有三种：升序片键、随机分发的片键和基于位置的片键。
1). 升序片键：升序片键通常有点类似于"date"字段或者是ObjectId，是一种随着时间稳定增长的字段。缺点：例如ObjectId可能会导致接下来的所有的写入操作都在同一块分片上。
2). 随机分发的片键：随机分发的片键可以是用户名，邮件地址，UDID，MD5散列值或者数据集中其他一些没有规律的键。缺点：MongoDB在随机访问超出RAM大小的数据时效率不高。
3). 基于位置的片键：基于位置的片键可以是用户的IP、经纬度、或者地址。这里的"位置"比较抽象，不必与实际的物理位置字段相关。
如果希望特定范围内的块出现在特定的分片中，可以为分片添加tag，然后为块指定相应的tag
3. 片键策略：
1). 散列片键：如果追求的是数据加载速度的极致，那么散列片键是最佳选择。散列片键可使其他任何键随机分发，因此，如果打算在大量查询中使用使用升序键，但同时又希望写入数据随机分发的话，
散列片键会是一个非常好的选择。缺点：无法使用散列片键做指定目标的范围查找。
创建步骤： db.users.ensureIndex({"username":"hashed"}) , sh.shardCollection("app.users",{"username":"hashed"})
2). GridFS的散列片键
3). 流水策略：如果有一些服务器比其他服务器更强大，我们可能希望让这些强大的服务器处理更多的负载。比如说：加入有一个使用SSD的分片能够处理10倍于其他机器的负载。我们可以强制将所有新数据
插入到SSD，然后让均衡器将旧的块移动到其他分片上。
a. 为SSD指定一个标签：sh.addShardTag("shard-name","ssd")
b. 将升序键的当前值一直到正无穷范围的块都指定分布在SSD分片上：sh.addTagRange("dbName.collName",{"_id":ObjectId()},...{"_id":MaxKey},"ssd")
所有插入请求均会路由到这个块上，这个块始终位于标签的ssd的分片上。
c. 除非修改标签范围，否则从升序键的当前值一直到正无穷都被固定在这个分片上。可以创建一个定时任务每天更新一次标签范围：
use config
var tag =db.tags.findOne({"ns":"dbName.collName",..."max":{"shardKey":MaxKey}})
tag.min.shardKey = ObjectId()
db.tags.save(tag)
这样前一天的数据就会被移动到其他分片上了。
此策略的另一个缺点：需要修改才能进行扩展。如果写请求超出了SSD的处理能力，无法进行负载均衡。
4). 多热点：写请求分布在集群中时，分片是最高效的。这种技术会创建多个热点(最好在每个分片上都创建几个热点)，写请求于是会均衡地分布在集群内，而在单个分片上则是以升序分布的。
为了实现这种方式，需使用复合片键。复合片键中的第一个值只是比较粗略的随机值，势也比较低。
4. 片键规则和指导方针：
1). 片键限制：片键不可以是数组。文档一旦插入，其片键就无法修改了。要修改文档的片键值，就必须先删除文档。
2). 片键的势：选择一个值会变化的的键非常重要，即值很多，随着数据量的增大可以分出更多的片键。分片在势比较高的字段上性能更佳。
5. 控制数据分发
1). 对多个数据库和集合使用一个集群：通过tag标记，将重要的数据放到性能更好的服务器上，将不重要的数据放在性能一般的服务器上。
2). 手动分片：如果不希望数据被自动分发，可以关闭均衡器，使用moveChunk命令手动对数据进行迁移。
分片管理
1. 检查集群状态：
1). 使用sh.status查看集群摘要信息: 块的数量比较多时，sh.status()命令会概述块的状态，而非打印出每个块的相关信息。如需查看所有的块，可使用sh.status(true)命令。
sh.status()显示的所有信息都来自config数据库。运行sh.status()命令，使用MapReduce获取这一数据。因此，如果启动数据库时指定--noscripting选项，则无法运行sh.status()命令。
2). 检查配置信息：
a. 集群相关的所有配置信息都保存在配置服务器上config数据库的集合中。可以直接访问该数据库，不过shell提供了一些辅助函数。
b. 永远不要直接连接到配置服务器，以防止配置服务器数据被不小心修改或删除。应该先连接到mongos，然后通过config数据库来查询相关信息：use config
如果通过mongos操作配置数据，mongos会保证将修改同步到所有配置服务器，也会防止危险的操作发生，如意外删除config数据库等。
c. 总的来说，不应直接修改config数据库中的任何数据。如果确实修改了某些数据，通常需要重启所有的mongos服务器，才能看到效果。
d. config中几个关键集合：
shards : 跟踪记录集群中所有分片的信息。
databases: 跟踪记录集群中所有数据库的信息，不管数据库有没有分片。
collections: 跟踪记录所有分片集合的信息(非分片集合信息除外)
chunks: 记录集合中所有块的信息。
changelog: 跟踪记录集群的操作，因为该集合会记录所有拆分和迁移的操作。
tags: 该集合的创建是在为系统配置分片标签时发生的。每个标签都与一个块范围相关联。
settings: 该集合含有当前的均衡器设置和块大小的文档信息。通过修改该集合的文档，可开启和关闭均衡器，也可以修改块的大小。注意，应总是连接到mongos修改该集合的值。
2. 查看网络连接：
1). 查看连接统计：可以使用connPoolStats命令，查看mongos和mongod之间的连接信息：db.adminCommand({"connPoolStats":1})
在一个分片上执行connPoolStats，输出信息中可以看到该分片与其他分片间的连接，包括连接到其他分片做数据迁移的连接。
2). 限制连接数量： 可在mongos的命令行配置中使用maxConns选项，这样可以限制mongos能够创建的连接数量。可以使用下面公式计算分片能够处理的来自单一mongos连接数量：
maxConns = 20000 - (mongos进程的数量 * 3 ) - (每个副本集的成员数量 * 3 ) - (其他/mongos进程的数量)
MongoDB如果没有安全退出，那些已经打开的套接字很可能没有被关闭。
在出现大量重新连接时，除了重启进程，没有其他特殊有效的方法。
3. 服务器管理
1). 添加服务器：使用addShard命令，向集群中添加新的分片
2). 修改分片的服务器：要修改分片的成员，需直接连接到分片的主服务器上，然后对副本集进行重新配置。集群配置会自动检测更改，并将其更新到config.shards上。
3). 通常来说，不应从集群中删除分片。执行removeShard命令排除数据和查看排出进度。
4). 修改配置服务器：修改配置服务器非常困难，而且有风险，通常还需要停机。注意，修改配置服务器前，应做好备份。
首先必须关闭所有mongos进程，然后使用新的--configdb参数重启所有mongos进程。
4. 数据均衡：
1). 均衡器：均衡器只使用块的数量，而非数据大小，作为衡量分片间是否均衡的指标。自动均衡总是根据数据集的当前状态来决定数据迁移，而不考虑数据集历史状态。我们可以手动均衡数据集块的数量。
2). 修改块的大小：块的大小默认为64M，这个大小的块既易于迁移，又不至于导致过多的流失。使用shell连接到mongos，修改config.setting集合，从而完成块大小的修改。
该设置的有效范围是整个集群：它会影响所有集合的数据库。因此，如需对一个集合使用较小的块，而对另一个集合使用较大的块，比较好的解决方式是取一个折中值(或者将这两个值放到不同的集合中)。
如果MongoDB频繁进行数据迁移或文档增大，则可能需要增加块的大小。
3). 迁移块：同一块内的所有数据都位于同一分片上。如该分片的块数量比其他分片多，则MongoDB会将其中的一部分块迁移到其他块数量较少的分片上。移动快的过程叫迁移，MongoDB就是这样在集群中
实现数据均衡的。可在shell中使用moveChunk辅助函数，手动移动块。
如果某个块的大小超出了系统指定的最大值，mongos则会拒绝移动这个块。移动之前必须先手动拆分这个块，可以使用splitAt命令对块进行拆分。特大块，无法被拆分。
4). 特大块：某些片键，值比较少，例如：日期等。可能会形成超出设置的最大块大小的块，这种块成为特大块.
出现特大块的表现之一是，某个分片的大小增长速度要比其他分片块的多。也可使用sh.status()来检查是否出现了特大块；特大块会存在一个jumbo属性。
a. 分发特大块，一个复杂的过程
b. 防止特大块的出现：修改片键，细化片键的粒度
5). mongos有时无法从配置服务器正确更新配置。如果发现配置有误，mongos的配置过旧或无法找到应有的数据，可以使用flushRouterConfig命令手动刷新所有缓存：db.adminCommand({"flushRouterConfig":1})
如flushRouterConfig命令没能解决问题，则应重启所有的mongos或者mongod进程，以便清除所有可能的缓存。
摘自 华为云
MongoDB数据库中数据的分片是以集合为基本单位的，集合中的数据通过片键被分成多部分。
对集合进行分片时，您需要选择一个片键 , 片键是每条记录都必须包含的，且建立了索引的单个字段或复合字段，MongoDB数据库按照片键将数据划分到不同的数据块中，并将数据块均衡地分布到所有分片中。为了按照片键划分数据块，MongoDB数据库使用基于范围的分片方式或者基于哈希的分片方式。
|
分片键类型 |
描述 |
使用场景 |
|---|---|---|
|
基于范围的分片键 |
基于范围的分片键是根据分片键值把数据分成一个个邻接的范围，如果没有指定特定的分片类型，则基于范围的分片键是默认的分片类型。 特点：基于范围的分片键对于范围类型的查询比较高效，给定一个片键的范围，分发路由可以很简单地确定哪个数据块存储了请求需要的数据，并将请求转发到相应的分片中。 |
建议在分片键基数较大，频率较低，并且分片键值不是单调变化的情况下使用基于范围的分片键。 |
|
基于哈希的分片键 |
基于哈希的分片键是指MongoDB数据库计算一个字段的哈希值，并用这个哈希值来创建数据块。 特点：保证了集群中数据的均衡。哈希值的随机性使数据随机分布在每个数据块中，因此也随机分布在不同分片中。 |
如果分片键值的基数较大，拥有大量不一样的值，或者分片键值是单调变化的，则建议使用基于哈希的分片键。 |
集合设置分片并插入文档之后，其中的每个文档的分片的键和值都是不可更改的。如果需要修改文档的分片键，必须要先删除文档，再修改分片键，然后重新插入文档。
说明：
分片键不支持数组索引，文本索引和地理空间索引。
基于范围的分片键设置
- 使用如下命令，开启数据库分片开关。
sh.enableSharding(database)
说明：
参数database表示要开启分片集合的数据库。
- 设置分片键。
sh.shardCollection(namespace, key)
说明：
- 参数namespace表示需要进行分片的目标集合的完整命名空间<database>.<collections>。
- key表示要设置分片键的索引。
- 如果需要进行分片的目标集合是空集合，可以不创建索引直接进行下一步的分片设置，该操作会自动创建索引。
sh.shardCollection()
- 如果需要进行分片的目标集合是非空集合，则需要先创建索引key。然后使用如下命令设置分片键。
sh.shardCollection()
基于哈希的分片键设置
- 使用如下命令，开启数据库分片开关。
sh.enableSharding(database)
说明：
参数database表示要开启分片集合的数据库。
- 设置基于哈希的分片键。
sh.shardCollection("<database>.<collection>", { <shard key> : "hashed" } , false, {numInitialChunks: 预置的chunk个数})
其中numInitialChunks值的估算方法是：db.collection.stats().size / 10*1024*1024*1024 。
如果集合已经包含数据，则需要先使用如下命令对需要创建的基于哈希的分片键先创建哈希索引：
db.collection.createIndex()
然后再使用如下命令创建基于哈希的分片键：
sh.shardCollection()
对使用了哈希片键分片的集合进行请求时,MongoDB会自动计算哈希值,应用方 不需要 解析哈希值.
- If the collection is empty, sh.shardCollection() creates the index on the shard key if such an index does not already exists.
-
片键可以影响数据在分片间的分布,也影响 mongos 对集群直接操作的效率,因此可以影响集群的读写性能, 可以考虑以下的操作受片键的影响.
一些片键会使应用程序能够达到集群能够提供的最大的写性能,有一些则不能,比如使用默认的 _id 做片键的情况.
-
在插入文档时,MongoDB会生成一个全局唯一的 ObjectId 标识符_id,不过,需要注意的一点是, 这个标识符的前几位代表时间戳,这意味着_id是以常规的并且可预测的方式增长,即使_id有 大的基数 ,在使用 _id或者任意其他单调递增的数据 作为片键时,所有的写入操作都会集中到一个分片中
-
片键可以影响数据在分片间的分布,也影响 mongos 对集群直接操作的效率,因此可以影响集群的读写性能, 可以考虑以下的操作受片键的影响.
不过,如果你的写入频率很低或者大多都是 update() 操作,单调递增的片键不会对性能有很大影响,一般来说,选择的片键要 同时 具有较大的基数与将请求分布在整个集群中两个特性.