MongoDB

Every document must have an _id. MongoDB creates a unique index on it that cannot be dropped, the value is immutable after insert, and it may hold any BSON type except an array. If you omit it, an ObjectId is generated.

Attach a validator to the collection — normally a $jsonSchema object listing required fields and their bsonType — using createCollection or collMod. MongoDB then checks every insert and update against it and rejects writes that break the rules.

An ObjectId is 12 bytes: a 4-byte Unix timestamp in seconds, a 5-byte value random per process, and a 3-byte incrementing counter. From one you can read its creation time to the second and infer rough insertion order.

The bucket pattern stores many small, time-ordered measurements in one document — an hour of readings for one sensor, say — instead of one document per reading. It cuts document count, index entries and per-document overhead for time-series workloads.

The computed pattern stores the result of a calculation — a count, sum, average or rollup — in the document and maintains it on write, so reads fetch a value instead of recomputing it. It pays off when reads far outnumber writes.

No. A find() projection is either an inclusion list or an exclusion list, and mixing the two raises an error. The single exception is _id, which may be excluded inside an otherwise inclusive projection.

It matches documents where tags is exactly the string "red" and documents where tags is an array containing "red" as an element. MongoDB applies the equality predicate to the field's value and to each array element.

updateOne with $set changes only the named fields and leaves every other field intact. replaceOne swaps the whole document for the one you pass, so any field the replacement omits disappears. _id cannot be changed either way.

Two conditions written side by side may be satisfied by different array elements; $elemMatch requires one single element to satisfy all of them at once. On a non-array field the two forms are equivalent.

Every write that touches a single document is atomic in MongoDB, no matter how many fields, embedded documents or array elements it changes. Atomicity stops at the document boundary: a write spanning several documents needs an explicit transaction to be all-or-nothing.

In $group, _id is the grouping-key expression: one output document per distinct _id value. Setting it to null puts everything in one group. Totals come from accumulators, for example revenue: { $sum: "$amount" }.

$lookup is a left outer join: for each input document it adds an array field, named by as, holding every document from the from collection whose foreignField equals the input's localField. No match yields an empty array, never a dropped document.

$unwind emits one document per array element, copying the other fields. A document whose array is empty, missing or null produces no output at all — it is dropped — unless you use the object form with preserveNullAndEmptyArrays: true, which passes it through once.

Use the pipeline form: let binds fields of the input document to variables, and the sub-pipeline runs against the foreign collection with those variables available as $$name. Compare them inside a $match with $expr, then $project or $limit to trim what comes back.

Only a leading $match becomes an indexed query on the collection, so filtering first shrinks the stream before expensive stages run. MongoDB's optimizer moves $match ahead of $project, $addFields or $sort only when the filter uses no field those stages create.

COLLSCAN means the server read every document in the collection; IXSCAN means it walked index keys and touched only matching entries. A COLLSCAN on a filtered query over a large collection signals a missing index.

A unique index rejects any write that would create a second document with the same indexed value, returning an E11000 duplicate key error. On a compound unique index the whole key combination must be unique, not each field on its own.

ESR orders compound-index keys as Equality first, then Sort fields, then Range fields. Equality pins the scan to a narrow contiguous key range, the sort fields then arrive already ordered, and range predicates go last because they destroy ordering for the keys after them.

They are the work-versus-result ratio of a query. nReturned is what the client got; totalKeysExamined is index entries read; totalDocsExamined is documents loaded. Ratios near 1:1:1 mean a well-matched index; large gaps mean wasted work.

A background thread wakes roughly every 60 seconds, finds documents whose indexed date is older than expireAfterSeconds, and deletes them with ordinary delete operations. Expiry is therefore approximate, not instant, and only the primary performs the deletes.

The primary is the only member that accepts writes and records them in its oplog. Secondaries hold full copies of the data, replay that oplog, and can be elected primary. An arbiter stores no data and only votes.

A w: "majority" acknowledgment means the write reached a majority of the replica set's voting, data-bearing members, so it survives an election and cannot be rolled back. It does not mean every member has it.

Electing a primary needs a strict majority of the configured voting members. Three members need two votes, four need three, so both survive exactly one loss. The fourth vote adds cost and tie risk without adding fault tolerance.

So an entry can be replayed any number of times with the same result. Secondaries and recovering members may re-apply the tail of the oplog after a restart or a sync-source switch, and a relative operation replayed twice would corrupt the data.

Run both operations inside one causally consistent client session, write with w: "majority" and read with readConcern: "majority". The session carries a cluster timestamp so the secondary waits until it has applied that write before answering.

A chunk (range) is a contiguous span of shard-key values owned by exactly one shard and recorded in config-server metadata. The balancer migrates ranges from the shard holding the most data for a collection to the shard holding the least.

A filter containing the shard key — or a leading prefix of a compound shard key — lets mongos map values to chunks and contact only the owning shards. Any other filter, including one on _id when _id is not the shard key, is broadcast to all shards.

A good MongoDB shard key has many distinct values, no single value that dominates the data, values that do not grow monotonically, and it appears in common query filters so requests reach one shard.

The recipient clones the range's documents and then catches up on changes; the donor enters a short critical section that blocks writes to that range while the config metadata is committed; afterwards the donor deletes the moved documents in the background as orphans.

Run explain() through mongos on the hot query shapes: a SHARD_MERGE stage with every shard named in the winning plan means scatter-gather. Compare per-shard keysExamined against nReturned, then fix the filter to carry the shard key rather than adding shards.