What Are NoSQL Databases?

NoSQL databases (meaning: not only SQL), in the simplest words, are an alternative to traditional relational databases. NoSQL databases are non-tabular databases which store data differently than relational tables. These kinds of databases come in a variety of types which are based on their data model. The most common types you’ll find are document, key-value, wide-column, and graph. NoSQL databases provide flexible schemas and are quite useful for working with large sets of distributed data.  

A Typology of NoSQL Databases

When people use the term “NoSQL database,” they typically do so to refer to any non-relational database. MongoDB is an example of this kind of database, but it definitely is not one of a kind. You can differentiate NoSQL databases by the type of the content, such as key-value cache, key-value store, object database, graph database, document store, etc. MongoDB represents the last group – document store NoSQL databases. But you’ll find more of those, such as Azure Cosmos DB, ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, eXist-db, IBM Domino, MarkLogic, RavenDB, Qizx, RethinkDB, Elasticsearch, or OrientDB. As you can see, the variety is quite impressive. We encourage you to learn more about all of them, but in this article, we’ll just focus on MongoDB.

What’s MongoDB And How Can You Benefit From Using It?

MongoDB is an open-source document-oriented NoSQL database management program used for high volume data storage. As mentioned previously, MongoDB can manage document-oriented information; store or retrieve data. The difference is that instead of using tables and rows as in the traditional, relational databases, MongoDB makes use of collections and documents. Each database contains collections, and those, in turn, contain documents. Documents can differentiate in many fields, such as size, content, and structure.  

Structure And Scalability

It’s believed that this non-relational form is more in line with how developers construct their classes and objects in their respective programming languages. The rows (or documents, as they are called in MongoDB) don’t need to have a particular schema defined beforehand. Instead, the fields can be created as you work.

This kind of data model, offered by MongoDB, allows you to represent different hierarchical relationships, save some particular arrays, and even work on other, more complex structures with ease.

Another benefit is MongoDB’s scalability of the environments. It’s commonly used all around the world to store the data, since it allows to define and create clusters with many documents within the database,

Beware Of The Challenges

Having said that, now is the time to talk about the challenges of MongoDB, and trust us, you’ll face some. No worries though! We have a set of hacks, tricks and solutions which you might find helpful.

Querying

Al contrary to the relational database MongoDB does not support joins, resulting in making some queries to the database more difficult. Joining documents in MongoDB is not an easy task, and developers are still working on a dedicated function to support it. In case you need to pull some data from several collections, it’ll for sure require several separate queries, which will lead to a messy code and long turn-around times.

Lack Of Transaction Support

Introducing transactions to MongoDB was indeed a big step forward, but still, they do have some limitations that tend to cause certain issues. For situations that require reactivity between multiple documents (in single or multiple collections), MongoDB supports multi-document transactions. Transactions can be used across multiple operations, collections, databases, documents, and shards.

While ACID transactions (referring to the set of four key properties that define a transaction: Atomicity, Consistency, Isolation, and Durability) placed limitations on scalability that eventually broke the leadership of the relational database model, the lack of a transactional capability in MongoDB limited the range of applications in which the database could be used. Many users of MongoDB were forced to implement complex logic to work around these limitations. Because transactional behavior is still optional, these new capabilities don’t need to have a negative effect on scalability or availability.  

Memory Issues And Time Spans

There is a significant difference between MongoDB and almost all transactional databases that implement the Multi-Version Consistency Control (MVCC) model. While in MVCC, there’re multiple versions of each data and queries will always read a version that existed when the query commenced, in MongoDB data is kept only in memory. In other databases, these older versions can be moved to the disk. In order to avoid MongoDB’s memory filling up with these older versions of data, transaction times are limited. MongoDB transactions exist only for relatively short periods – in a span of only around one minute. This way, queries see a consistent view of the data, unaffected by transactions that are issued during query execution.  

Locking Mechanism

Another important difference with relational database models is that MongoDB implements a different locking mechanism from what programmers could be used to. In a typical RDBMS transaction, an attempt to modify a document that is currently changed by an uncommitted transaction would result in a blocking lock. The attempt to modify the item in question would have to wait until the transaction is completed, before being able to continue. The database typically implements a lock structure that ensures that session blocking is processed in the order.[Text Wrapping Break][Text Wrapping Break]In the case of MongoDB, there is a  lock mechanism on a document that is being modified by a transaction.  However, other sessions that attempt to modify that document won’t t get locked. Rather, their transaction is aborted, and they’re required to retry the transaction. This can waste some of your time, as other operations in the transaction will need to be re-executed, and also results in requests being serviced in a non-deterministic order.

Limit For Document Size. How To Handle More Extensive Documents?

MongoDB transactions are transmitted to other nodes in the cluster using the typical replication mechanisms. This means that each transaction is represented as a single “oplog” message. Oplog messages are limited by MongoDB to 16MB documents. Therefore, each transaction may change no more than 16MB of data. As a result, a large bulk of data updates or inserts cannot be processed in a single transaction. MongoDB simply will store it in multiple chunks.  

There are four types of data in our app — strings, numbers, dates and booleans. With a 16MB limit, a MongoDB document can easily store around 2 million values of 64-bit numbers. The situation looks different with strings, since each UTF-8 character takes one byte.  

How can you deal with it? There are a few simple hacks. The easiest one: you can use Stringify and zip string of values. Easy – yes, but still gets some of the work done. The second option is to use the Excel approach with a dictionary. Just create a dictionary, put unique strings into it, and replace the strings with indexes. This method is useful if there’re many repeated strings in a column. One last hack: create multiple documents for a single column. If the column fits 16MB, we store it as is. Otherwise, we split the column into chunks and save the chunks in other documents linked to the main document.

MongoDB Memory Consumption For Data Storage

Estimating how much RAM a MongoDB system will need is not an easy task. We have to consider: the size of all indexes and the number of all active documents multiplied by the average document size.

MongoDB is not an in-memory database, although there’s a way to configure it to run that way. It makes very liberal use of the cache, meaning data records are kept in the memory instead of on a disk for fast retrieval . This is done for performance reasons. MongoDB won’t release them until its memory increases up to 50% of the system’s memory (1 GB RAM by default). This means its memory use will be increasing continuously till this point. MongoDB won't free up the memory unless another process asks for it.

What’s the solution? Check your file system cache, the memory use, and available virtual memory in kilobytes – we recommend you to take advantage of the free monitoring service offered by MongoDB. You can find it hosted on their website, but that does‘ot mean you need to use their cloud service (Atlas). It’ll work perfectly fine with your servers.

Cloud Database Pricings

Using MongoDB databases allows you to keep the data on your local server (on-premise), as well as on cloud servers. However, the first option allows you to save some costs, since acquiring the cloud database services, such as those provided by Amazon, can be costly. MongoDB in the cloud does not compete with the services that cloud providers natively offer.  

For example, Atlas is MongoDB’s database-as-a-service. It provides users with a managed database service with a “pay-as-you-go” type of pricing. It initially allowed users to deploy on Amazon Web Services (AWS), with the support for Azure and Google Cloud Platform following not much later. MongoDB helps to run the service on-premise and MongoDB Professional provides businesses with support and access to the company’s Cloud Manager and other tools. Atlas fits somewhere between these two services. It allows anybody who wants to use MongoDB to quickly provision it in the cloud and receive support, paying only an hourly fee.

Should I Use MongoDB?

Well, we can’ot see why not! MongoDB definitely can provide its users with many benefits. Its flexible form facilitates data storing and management in a way that it makes it easy for programmers to work with. MongoDB is also made to scale up quickly and supports the majority of the features typical for modern databases, such as transactions. At the same time, before you dive in it’s always a good idea to investigate the challenges that MongoDB brings upon a developer. This article should give you a good start to this process!  

We hope that this portion of knowledge has at least has sharpened your appetite for more. In case you want to learn more about MongoDB or you just have some questions regarding this topic – please don’t hesitate to contact us by clicking the link below.

‍