Menu
This specifc question is in relation to using mongodb with the golang package mongo-driver, but I would assume this applies across most interfaces with mongodb.
When using Find to query some data from a collection, we can use both the bson.M- and bson.D-type to specify the filter for this find.
As per the documentation bson.D should be used if the order of elements matters and bson.M should be used otherwise.
D is an ordered representation of a BSON document. This type should be used when the order of the elements matters, such as MongoDB command documents. If the order of the elements does not matter, an M should be used instead.
Now my question is whether the use of either of these, i.e. ordered vs unordered, structures has an effect on the query plan generated by the mongo query optimizer.
In a classic SQL database the order usually doesn't matter as the optimizer is smart enough to use summary statistics, indexes, etc. to determine which queries to execute first.
Can I assume this to be the case here as well, or does using an ordered structure to query my collection somehow interfere with this / does using an ordered structure work similar to using optimizer hints? If there is some interference, is this influenced at all by if the fields to search through are indexed?
245
D : An ordered representation of a BSON document (slice) M : An unordered representation of a BSON document (map) A : An ordered representation of a BSON array.
Unlike systems that store JSON as string-encoded values, or binary-encoded blobs, MongoDB uses BSON to offer powerful indexing and querying features on top of the web's most popular data format.
BSON Document Size. 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.
MongoDB stores documents (objects) in a format called BSON. BSON is a binary serialization of JSON-like documents. BSON stands for “Binary JSON”, but also contains extensions that allow representation of data types that are not part of JSON. For example, BSON has a Date data type and BinData type.
You may use bson.M for the filter, it usually results in shorter and clearer filter declaration, the order of fields doesn't matter, the MongoDB server is smart enough to find matching indices regardless of the used order. E.g. if you have a compound index with fields A and B, using a bson.D filter listing B first then A will not prevent the server to use the existing index. So in this case you may use bson.M and bson.D, it doesn't matter.
The order does matter when you specify sort fields for example. It does matter if you sort by field A then by field B, it may be a completely different order than sorting by B first and then by A. So when you specify a sort document having multiple fields, you should definitely use bson.D.
The order may also matter (to you) when you insert a new document for example. If you use a bson.M as the document, the order of fields is not guaranteed to be the same in all your documents. When you use bson.D, then the order in the saved document will match the order as you list the fields in bson.D.
98
The key order applies to wire protocol, not query execution.
In MongoDB, BSON documents are ordered lists of key-value pairs.
BSON is used for serializing documents stored in collections as well as "command documents", which are the commands sent to the server.
When a server processes a command, it requires the command name to be the first key (remember keys are ordered). The purpose of this is to make command dispatching more efficient.
Once the command is dispatched, the order of keys in the rest of the command document, or in the payload (which includes the find condition in case of find), doesn't matter.
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
