Hướng dẫn does mongodb support full
Docs Home → MongoDB Manual On this page
This document provides a collection of hard and soft limitations of the MongoDB system. The maximum BSON document size is 16 megabytes. The maximum document size helps ensure that a single document cannot use excessive amount of RAM or, during transmission, excessive amount
of bandwidth. To store documents larger than the maximum size, MongoDB provides the GridFS API. See MongoDB supports no more than 100 levels of nesting for BSON documents. Each object or array adds a level. Do not rely on case to distinguish between databases. For example, you cannot use two databases with names like, After you create a database in MongoDB, you must use consistent capitalization when you refer to
it. For example, if you create the For MongoDB deployments running on Windows, database names cannot contain any of the following characters: Also database names cannot contain the null character. Restrictions on Database Names for Unix and Linux SystemsFor MongoDB deployments running on Unix and Linux systems, database names cannot contain any of the following characters: Also database names cannot contain the null character. Length of Database NamesDatabase names cannot be empty and must have fewer than 64 characters. Restriction on Collection NamesCollection names should begin with an underscore or a letter character, and cannot:
If your collection name includes special characters, such as the underscore character, or begins with numbers, then to access the collection use the Namespace Length:
The field name WarningUse caution, the issues discussed in this section could lead to data loss or corruption. The MongoDB Query Language is undefined over documents with duplicate field names. BSON builders may support creating a BSON document with duplicate field names. While the BSON builder may not throw an error, inserting these documents into MongoDB is not supported even if the insert succeeds. For example, inserting a BSON document with duplicate field names through a MongoDB driver may result in the driver silently dropping the duplicate values prior to insertion. Starting in MongoDB 5.0, document field names can be dollar ( MongoDB Extended JSON v2 cannot differentiate between type wrappers and fields that happen
to have the same name as type wrappers. Do not use Extended JSON formats in contexts where the corresponding BSON representations might include dollar ( There are also restrictions on using
There is a small chance of data loss when using dollar ( When running
insert, update, and findAndModify commands, drivers that are 5.0 compatible remove restrictions on using documents with field names that are dollar ( The restrictions are removed regardless of the server version the driver is connected to. If a 5.0 driver sends a document to an older server, the document will be rejected without sending an error.
TipSee also:NoteChanged in version 4.2For
MongoDB 2.6 through MongoDB versions with fCV set to When the Index Key Limit applies:
A single collection can have no more than 64 indexes. Index Name LengthNoteChanged in version 4.2In previous versions of MongoDB or MongoDB versions with fCV set to By default, There can be no more than 32 fields in a compound index. Queries cannot use both text and Geospatial IndexesYou cannot combine the Fields with 2dsphere indexes must hold geometry data in the form of coordinate pairs or GeoJSON data. If you attempt to insert a document with non-geometry data in a Tip
See also:Limited Number of 2dsphere index keysTo generate keys for a 2dsphere index,
When
If the value of a field returned from a query that is covered by an
index is Multikey indexes cannot cover queries over array field(s). Geospatial IndexGeospatial indexes cannot cover a query. Memory Usage in Index Builds
You can override the memory limit by setting the
Changed in version 4.2.
Index builds may be initiated either by a user command such as Create Index or by an administrative process such as an initial sync. Both are subject to the limit set by
An initial sync operation populates only one collection at a time and has no risk of exceeding the memory limit. However, it is possible for a user to start index builds on multiple collections in multiple databases simultaneously and potentially
consume an amount of memory greater than the limit set in TipTo minimize the impact of building an index on replica sets and sharded clusters with replica set shards, use a rolling index build procedure as described on Rolling Index Builds on Replica Sets. Collation and Index TypesThe following index types only support simple binary comparison and do not support collation:
TipTo create a
You can sort on a maximum of 32 keys. If you specify the maximum number of documents in a capped collection with If you do not specify a maximum number of documents when creating a capped collection, there is no limit on the number of documents. Replica sets can have up to 50 members. Number of Voting Members of a Replica SetReplica sets can have up to 7 voting members. For replica sets with more than 7 total members, see Non-Voting Members. Maximum Size of Auto-Created OplogIf you do not explicitly specify an oplog size (i.e. with
Sharded clusters have the restrictions and thresholds described here.
The
In MongoDB 5.0 and earlier, you cannot specify sharded collections in the Starting in MongoDB 3.0, an index
cannot cover a query on a sharded collection when run against a In previous versions, an index cannot
cover a query on a sharded collection when run against a An existing collection can only be sharded if its size does not exceed specific limits. These limits can be estimated based on the average size of all shard key values, and the configured chunk size. ImportantThese limits only apply for the initial sharding operation. Sharded collections can grow to any size after successfully enabling sharding. Use the following formulas to calculate the theoretical maximum collection size.
NoteThe maximum BSON document size is 16MB or All conversions should use base-2 scale, e.g. 1024 kilobytes = 1 megabyte. If After successful initial sharding, you can reduce the chunk size as needed. If you later reduce the chunk size, it may take time for all chunks to split to the new size. See Modify Chunk Size in a Sharded Cluster for instructions on modifying chunk size. This table illustrates the approximate maximum collection sizes using the formulas described above:
All
MongoDB does not support unique indexes across shards, except when the unique index contains the full shard key as a prefix of the index. In these situations MongoDB will enforce uniqueness across the full key, not a single field. TipSee:Maximum Number of Documents Per Chunk to MigrateBy default, MongoDB cannot move a chunk if the number of documents in the chunk is greater than 1.3 times the result of dividing the configured
chunk size by the average document size. For chunks that are too large to migrate, starting in MongoDB 4.4:
Starting in version 4.4, MongoDB removes the limit on the shard key size. For MongoDB 4.2 and earlier, a shard key cannot exceed 512 bytes. Shard Key Index TypeA shard key index can be an ascending index on the shard key, a compound index that start with the shard key and specify ascending order for the shard key, or a hashed index. A shard key index cannot be an index that specifies a multikey index, a text index or a geospatial index on the shard key fields. Shard Key Selection is Immutable in MongoDB 4.2 and EarlierYour options for changing a shard key depend on the version of MongoDB that you are running:
In MongoDB 4.2 and earlier, to change a shard key:
For clusters with high insert volumes, a shard key with monotonically increasing and decreasing keys
can affect insert throughput. If your shard key is the When inserting documents with monotonically increasing shard keys, all inserts belong to the same chunk on a single shard. The system eventually divides the chunk range that receives all write operations and migrates its contents to distribute data more evenly. However, at any moment the cluster directs insert operations only to a single shard, which creates an insert throughput bottleneck. If the operations on the cluster are predominately read operations and updates, this limitation may not affect the cluster. To avoid this constraint, use a hashed shard key or select a field that does not increase or decrease monotonically. Hashed shard keys and hashed indexes store hashes of keys with ascending values. If MongoDB cannot use an index or
indexes to obtain the sort order, MongoDB must perform a blocking sort operation on the data. The name refers to the requirement that the If MongoDB requires using more than 100 megabytes of system memory for the blocking sort operation, MongoDB returns an error unless the query specifies
Changed in version 4.4: For MongoDB 4.2 and prior, blocking sort operations could not exceed 32 megabytes of system memory. For more information on sorts and index use, see Sort and Index Use. Aggregation Pipeline OperationStarting in MongoDB 6.0, the
The Examples of stages that can write temporary files to disk when allowDiskUse is
NotePipeline stages operate on streams of documents with each pipeline stage taking in documents, processing them, and then outputing the resulting documents. Some stages can't output any documents until they have processed all incoming documents. These pipeline stages must keep their stage output in RAM until all incoming documents are processed. As a result, these pipeline stages may require more space than the 100 MB limit. If the results of one of your Starting in MongoDB 4.2, the profiler log messages and diagnostic log messages includes a
TipGeospatial QueriesFor spherical queries, use the The use of
For For multi-document transactions:
Changed in version 4.4. The following operations are not allowed in transactions:
Transactions have a lifetime limit as specified by
Changed in version 3.6: The limit raises from
The A view definition Views have the following operation restrictions:
New in version 4.4: $ -Prefixed
Field Path RestrictionStarting in MongoDB 4.4, the find() and findAndModify() projection cannot project a field that starts with $ with the exception of the
DBRef fields.For example, starting in MongoDB 4.4, the following operation is invalid: In earlier version, MongoDB ignores the $ -prefixed field projections.$ Positional Operator Placement RestrictionStarting in MongoDB 4.4, the
$ projection operator can only appear at the end of the field path; e.g. "field.$" or "fieldA.fieldB.$" .For example, starting in MongoDB 4.4, the following operation is invalid: To resolve, remove the component of the field path that follows the
$ projection operator.In previous versions, MongoDB ignores the part of the path that follows the $ ; i.e. the projection is treated as "instock.$" .Empty Field Name Projection RestrictionStarting in MongoDB 4.4,
find() and findAndModify() projection cannot include a projection of an empty field name.For example, starting in MongoDB 4.4, the following operation is invalid: In previous versions, MongoDB
treats the inclusion/exclusion of the empty field as it would the projection of non-existing fields.Path Collision: Embedded Documents and Its FieldsStarting in MongoDB 4.4, it is illegal to project an embedded document with any of the embedded document's fields.For example, consider a collection inventory with documents that contain a size field: Starting in MongoDB 4.4, the following operation fails with a Path
collision error because it attempts to project both
size document and the size.uom field: In previous versions, lattermost projection between the embedded documents and its fields determines the projection:
$slice of an Array and Embedded FieldsStarting in MongoDB 4.4, find() and
findAndModify() projection cannot contain both a $slice of an array and a field embedded in the array.For example, consider a collection inventory that contains an array field instock : Starting in
MongoDB 4.4, the following operation fails with a Path
collision error: In previous versions, the projection applies both projections and returns the first element ($slice: 1 ) in the instock array but suppresses the warehouse field in the projected element. Starting in MongoDB 4.4, to achieve the same result, use the db.collection.aggregate() method with two
separate $project stages.$ Positional Operator and $slice RestrictionStarting in MongoDB 4.4, find() and
findAndModify() projection cannot include $slice projection expression as part of a
$ projection expression.For example, starting in MongoDB 4.4, the following operation is invalid: In previous versions, MongoDB returns the first element (instock.$ ) in the instock array that matches the query condition; i.e. the positional projection "instock.$" takes precedence and the $slice:1 is a no-op. The "instock.$": {
$slice: 1 } does not exclude
any other document field.To use Client
Sessions and Causal Consistency Guarantees with Sessions that receive no read or write operations for 30 minutes
or that are not refreshed using Consider an application that issues a
For operations that return a cursor, if the cursor may be idle for longer than 30 minutes, issue the operation within an explicit session using
In the example operation, the For MongoDB drivers, defer to the driver documentation for instructions and syntax for creating sessions. |