MongoDB中的参数限制与阀值详析
前言
今天搜索spark mongo的资料,意外发现了MongoDB的一些知识,这些都是之前没有接触过的,所以专门记录下。 (๑• . •๑)
下面话不多说了,来一起看看详细的介绍吧
一、BSON文档
- BSON文档尺寸:一个document文档最大尺寸为16M;大于16M的文档需要存储在GridFS中。
- 文档内嵌深度:BSON文档的结构(tree)深度最大为100。
二、Namespaces
- collection命名空间:.,最大长度为120字节。这也限定了database和collection的名字不能太长。
- 命名空间的个数:对MMAPV1引擎,个数最大为大约为24000个,每一个collection和index都是一个namespace;对wiredTiger引擎则没有这个限制。
- namespace文件的大小:对MMAPV1引擎而言,默许大小为16M,可以通过在配置文件中修改。wiredTiger不受此限制。
三、indexes
- index key:每条索引的key不得超过1024个字节,如果index key的长度超过此值,将会致使write操作失败。
- 每一个collection中索引的个数不得超过64个。
- 索引名称:我们可以为index设定名称,终究全名为..$,最长不得超过128个字节。默许情况下为filed名称与index类型的组合,我们可以在创建索引时显式的指定index名字,参见createIndex()方法。
- 组合索引最多能包括31个field。
四、Data
- Capped Collection:如果你在创建“Capped”类型的collection时指定了文档的最大个数,那末此个数不能超过2的32次方,如果没有指定最大个数,则没有限制。
- Database Size:MMAPV1引擎而言,每一个database不得持有超过16000个数据文件,即单个database的总数据量最大为32TB,可以通过设置“smallFiles”来限定到8TB。
- Data Size:对MMAVPV1引擎而言,单个mongod不能管理超过最大虚拟内存地址空间的数据集,比如linux(64位)下每一个mongod实例最多可以保护64T数据。wiredTiger引擎没有此限制。
- 每一个Database中collection个数:对MMAPV1引擎而然,每一个database所能持有的collections个数取决于namespace文件大小(用来保存namespace)和每一个collection中indexes的个数,终究总尺寸不超过namespace文件的大小(16M)。wiredTiger引擎不遭到此限制。
五、Replica Sets
- 每一个replica set中最多支持50个members。
- replica set中最多可以有7个voting members。(投票者)
- 如果没有显式的指定oplog的尺寸,其最大不会超过50G。
六、Sharded Clusters
- group聚合函数,在sharding模式下不可用。请使用mapreduce或aggregate方法。
- Coverd Queries:即查询条件中的Fields一定要是index的一部份,且返回结果只包括index中的fields;对sharding集群,如果query中不包括shard key,索引则没法进行覆盖。虽然_id不是“shard key”,但是如果查询条件中只包括_id,且返回的结果中也只需要_id字段值,则可使用覆盖查询,不过这个查询仿佛并没有甚么意义(除非是检测此_id的document会不会存在)。
- 对已存有数据的collections开启sharding(原来非sharding),则其最大数据不得超过256G。当collection被sharding以后,那末它可以存储任意多的数据。
- 对sharded collection,update、remove对单条数据操作(操作选项为multi:false或justOne),一定要指定shard key或_id字段;否则将会抛出error。
- 唯一索引:shards之间不支持唯一索引,除非这个“shard key”是唯一索引的最左前缀。比如collection的shard key为{“zipcode”:1,”name”: 1},如果你想对collection创建唯一索引,那末唯一索引一定要将zipcode和name作为索引的最左前缀,比如:collection.createIndex({“zipcode”:1,”name”:1,”company”:1},{unique:true})。
- 在chunk迁移时允许的最大文档个数:如果一个chunk中documents的个数超过250000(默许chunk大小为64M)时,或document个数大于 1.3 *(chunk最大尺寸(有配置参数决定)/ document平均尺寸),此chunk将没法被“move”(不管是balancer或者人工干预),一定要等待split以后才能被move。
七、shard key
- shard key的长度不得超过512个字节。
- “shard key索引”可以为基于shard key的正序索引,或以shard key开头的组合索引。shard key索引不能是multikey索引(基于数组的索引)、text索引或geo索引。
- Shard key是不可变的,不管什么时候都不能修改document中的shard key值。如果需要变更shard key,则需要手动清洗数据,即全量dump原始数据,然后修改并保存在新的collection中。
- 单调递增(递减)的shard key会限制insert的吞吐量;如果_id是shard key,需要知道_id是ObjectId()生成,它也是自增值。对单调递增的shard key,collection上的所有insert操作都会在一个shard节点上进行,那末此shard将会承载cluster的全部insert操作,由于单个shard节点的资源有限,因此全部cluster的insert量会因此受限。如果cluster主要是read、update操作,将不会有这方面的限制。为了不这个问题,可以斟酌使用“hashed shard key”或选择一个非单调递增key作为shard key。(rang shard key 和hashed shard key各有优势和劣势,需要根据query的情况而定)。
八、Operations
- 如果mongodb不能使用索引排序来获得documents,那末参与排序的documents尺寸需要小于32M。
- Aggregation Pileline操作。Pipeline stages限制在100M内存,如果stage超过此限制将会产生毛病,为了能处理较大的数据集,请开启“allowDiskUse”选项,即允许pipeline stages将额外的数据写入临时文件。
九、命名规则
- database的命名辨别大小写。
- database名称中不要包括:/ .‘’$*<>:|?
- database名称长度不能超过64个字符。
- collection名称可以以“_”或字母字符开头,但是不能包括”$”符号,不能为空字符或null,不能以“system.”开头,由于这是系统保存字。
- document字段名不能包括“.”或null,且不能以“$”开头,由于$是一个“援用符号”。
最后记录下json嵌套中含有列表的查询方法,样例数据:
{ "_id" : ObjectId("5c6cc376a589c200018f7312"), "id" : "9472", "data" : { "name" : "测试", "publish_date" : "2009-05⑴5", "authors" : [ { "author_id" : 3053, "author_name" : "测试数据" } ], } }
我要查询authors中的author_id,query可以这样写:
db.getCollection().find({'data.authors.0.author_id': 3053})
用0来代表第一个索引,点代表嵌套结构。但是spark mongo中是不能这样导入的,需要使用别的方法。
总结
本篇文章到此结束,如果您有相关技术方面疑问可以联系我们技术人员远程解决,感谢大家支持本站!
文章来源:丸子建站
文章标题:MongoDB中的参数限制与阀值详析
https://www.wanzijz.com/view/61809.html