Introduction
Non-tabular databases (sometimes known as "not just SQL") keep data differently than relational tables. The data model of NoSQL databases is used to classify them. The most popular types are document, key-value, wide-column, and graph. They feature adaptable schemas and can easily manage large amounts of data and high user loads.
Many NoSQL databases contain the following qualities at a high level:
- Adaptable Schemas
- Horizontal scaling
- queries are quick.
- Simple to utilize.
This blog will compare two of the popular NoSQL databases, i.e., MongoDB and RavenDB.
Must Recommended Topic, Generalization in DBMS.
Recommended Topic, Schema in DBMS
MongoDB vs RavenDB
1. Horizontal Scaling / Sharding
- Sharding at the database level allows Mongodb to scale horizontally. It is the process of dividing data into non-overlapping sub-datasets (known as chunks in MongoDB) and hosting each chunk on its machine. To make such an operation work, we'll need to create a sharding key that will indicate which server will host the page.
- RavenDB does not support sharding at the database level.
Also See, difference between sql and nosql
2. Replication
- The primary purpose of replication is to provide data redundancy and high availability.
- A replica set is used to achieve replication in MongoDB. Writer operations are submitted to the primary server (node), which replicates the data by applying the operations across secondary servers. If the primary server fails (due to a crash or a system failure), one of the secondary servers takes over and is elected to become the new primary node. When that server fully recovers, it becomes a secondary node, assisting the new primary node.
source: mongodb.com
- RavenDB does not replicate a single document at any given time. We send a huge amount of data at once when we need to replicate data between nodes. RavenDB determines the batch size and content based on criteria such as the amount of data to be transmitted, the number of documents to be delivered, and a few other implementation-dependent factors (such as the speed of replication). RavenDB assures that writes done in the same transaction will always be sent in a single batch to the other database instances, rather than being split into multiple batches. To put it another way, we retain atomicity across replication.
3. Query Language
- MongoDB uses a JSON-like technique to query creation.
- The RavenDB client uses C# LINQ expressions (a mix between SQL and functional language pipelines) to allow users to express queries directly in code.
4. Indexing
| MongoDB | RavenDB | |
| Primary Indexes | Yes | Yes |
| Secondary Indexes | Yes | Yes |
| Auto Indexes | No | Yes |
| Multiple fields in one index | Yes (Compound Index) | Yes (Map Indexes) |
| Spatial Index | Yes (GeoSpatial Index) | Yes (Spatial Data) |
| Full-text Index | Yes (Text Index) | Yes (Full-Text Search) |
| Multi-collection indexes | No | Yes |
| Hierarchical indexes | No | Yes |
| Aggregate data in indexes | No | Yes |
5. Cloud Offering
- While RavenDB has a simple configuration tool, MongoDB Atlas has many more knobs and switches.
- Both services use the same pricing model: the first 1GB is free, after which you'll have to pay per gigabyte per month.
- RavenDB is slightly more expensive in a quick comparison.
6. Multi-Document Transactions
- Multi-document transactions guarantee data integrity, give a globally consistent picture of data and impose all-or-nothing execution. The properties of the transactions will be as follows. All data changes made during a transaction are stored when it is committed.
- Both support multi-document transactions, but they took different paths to get there. It was a design decision from the beginning in RavenDB, and it was added to MongoDB in version 3.4, with an actual implementation coming only in version 4.2. MongoDB transactions were limited to a total size of 16 MB until version 4.0. In version 4.2, this restriction was lifted.
Read about Batch Operating System and Checkpoint in DBMS here.
34+ registered 
