[MongoDB translation] sharding limit)

Security

Version 2.0 supports the Authentication Mode in the sharding status.

Differences from sharding Configuration

• Before Version 2.0, parts must run in a trusted security mode without clear security policies.
• In the current version, the shard key cannot be changed once selected.
• All (not multiple) Update, update, and insert operations must contain the complete shard key. This will have some impact on the use of ing libraries, because you cannot control the update operation at this time.

$ Where

$ Where can be used under sharding. But do not reference database objects (DB objects) in the $ where function ).

DB. Eval

DB. eval () cannot be used on the shard set. Of course, you can use dB. eval () on the unsharded set. You can use map/reduce in the fragment environment.

Getpreverror

Getpreverror is not supported in the sharded database and may not be supported in future releases. If this will cause you trouble, please let us know.

Unique Indexes

For a shard set, you can specify a unique condition constraint for the shard key. You can also have other unique indexes if and only if the shard key is the prefix of their attributes. In other words, MongoDB does not guarantee its uniqueness in multiple shard environments. As long as there is no restriction on uniqueness, you can create other non-uniqueness indexes.

Scale limit

The target is to support up to 1000 shards. So far, the cluster test is limited to a certain number of shards (such as 100 ). If you encounter scale restrictions in the future, more information will be updated here in the future.

There is no hard encoding limit on the size of the set, but remember the descriptions in the previous chapter. You can create a shard set and add data to it. The corresponding data is added to the corresponding shard. Of course, as long as your query can be quickly queried.

Query speed

Queries that contain the shard key can be returned quickly. The query speed is the same as that used to perform queries in a non-sharded environment.

A query that does not contain a shard key uses the distributed/converged method. It sends the query to all shards. When you have 10 shard instances, the performance is good, but when you have 1000 shards instances, the performance may be very poor (if there are few queries, the performance will also be good ).

Slice an existing set

You can partition an existing set, but there are some restrictions. In other words, if you have a single node (or a single replication group), it is possible to upgrade it to the sharding configuration.

The current limits are large and small.

1. Size: In version 1.6, we set the maximum size of the original set to 25 GB (increased to 1.8 GB in version 256 ). This limit will increase or be canceled in the future. If your application has exceeded this limit and you have also split the set, it can work. However, all your data will start with a data block, resulting in a very slow initial distribution. In practical applications, if your collection contains many large documents, this limit may be greater (due to the method of counting split computing points ). A work und is to increase the default data block size (such as MB or 1 GB) in db. config. settings, so that the initial split and migration can be enabled. In this way, when data is inserted, large data blocks are naturally split.
2. Time: it takes some time to partition an existing set. Slice is performed in the background, so other operations will not be significantly affected. In any case, it takes a lot of time to migrate/balance data in a large set. For example, in a system with 10 shard, 90% of the data in the collection needs to be migrated to other places to achieve a balance (the reminder is only to balance the data in large sets, if the set is small (for example, less than 400 MB), we recommend that you do not partition it ).