MongoDB provides the flexibility to configure write and read operations according to the requirements of a specific application. MongoDB has four levels of write concern, and five levels of read concern, which can be set on a per-operation basis, or can be set as the default for the entire database or collection.
## Write Concern
Write concerns determine the level of acknowledgment requested for write operations, which includes the number of replicas that need to acknowledge receipt of a write operation. In MongoDB, the available write concerns are:
- **w: 0**: This is the lowest level of acknowledgement, where a write operation does not wait for any acknowledgement from the replica set members. This write concern is useful for write operations that are not critical and where missing data is acceptable.
- **w: 1**: This is the default write concern, where a write operation waits for acknowledgement from the primary member of the replica set. This ensures that the data has been written to at least one member of the replica set.
- **w: majority**: A write operation waits for acknowledgement from the majority of the replica set members. This ensures that the data is written to a majority of the members, which makes it more durable and less prone to data loss in case of failures.
- **w: tag**: This write concern allows to specify an individual replica set tag or multiple tags with which to confirm that the write operation has propagated to the specific replica set members tagged with the corresponding values.
### Example
Assuming we have a replica set comprising of three nodes ‘NodeA, NodeB, and NodeC‘, we can set the write concern for a write operation as follows:
db.collection.insertOne(
{ name: "John", age: 35 },
{ writeConcern: { w: "majority" } }
);This will wait for acknowledgment from the majority of replica set members before confirming that the operation is successful.
## Read Concern
Read concerns determine the level of consistency required for read operations, which includes the number of replicas that should be read, and whether stale or unread data should be allowed. The available read concerns in MongoDB are:
- **local**: The read operation returns the most recent data available on the node handling the query, which may be stale data. This read concern is useful for read-intensive applications where data accuracy is not critical.
- **available**: The read operation returns the most recent data available from the replica set, and does not wait for any new data to be written. This read concern is useful for read-intensive applications where data accuracy is important but waiting for new data is not acceptable.
- **majority**: The read operation waits for data to be written to a majority of the replica set members and reads from the most up-to-date data available from the majority of the replica set members.
- **linearizable**: The read operation returns the most up-to-date data available from the replica set members, with a guarantee that any subsequent read operation will be guaranteed to see that data. This ensures that the data that is read is accurate and the latest version available.
- **snapshot**: The read operation returns data from a single point in time, preventing other write operations from interfering with the data read. The snapshot read concern is ideal for analytical queries.
### Example
Assuming we have a replica set comprising of three nodes ‘NodeA, NodeB, and NodeC‘, we can set the read concern for a read operation as follows:
db.collection.find(
{ name: "John" },
{ readConcern: { level: "majority" } }
);This will wait for data to be written to a majority of the replica set members before returning the most up-to-date data available from the majority of the replica set members.