MongoDB is a NoSQL, cross-platform, document-oriented database program
offering many useful features, as mentioned by my colleagues across the previous
slides.
Which covered the technology MongoDB uses, the architecture associated with it as
a database and some typical use case that the program is ideal for.
So, in short, when are the best times to use MongoDB?
When you have naturally document-shaped data, which does not require separate
occasions for read and write actions, then MongoDB being able to do so
simultaneously creates a fast and very responsive database.
Such examples of this are user profiles and preferences, where multiple fields are
updated simultaneously or even where catalogue items with varying attributes are
stored, and with the Internet of Things being the greatest source of data these days,
then the ability to have device data payloads stored in the once instance is just some
of the benefits seen from the architecture.
If you are in a changing environment where the schema may have to evolve or
change on a frequent basis, so rather than having to redesign the tables, and
migrate data across on a repeated basis the MongoDB is the better as data can just
be plugged directly into the documents without any redesign required.
Other occasions to use MongoDB are when you are envisaging just doing simple
queries and rendering the whole object in the one, then using Mongo demonstrates a
fast ability to fulfil this type of query.
This speed and responsiveness is also beneficial for high write throughput and event
heavy systems, such as application logs and telemetry data and background job
events, where the database needs to be fast and its response rate is not detrimental
to the system.
The nature of MongoDB and the rendering of whole objects means that the system is
very tolerant of denormalisation and can easily handle duplicate data, ensuring that
reads have a fast response time.
Another benefit of MongoDB is that it is easy to set up and performs well in early
development environments, as it supports horizontal scaling, which is achieved by
means of using sharding to maintain response rates whilst also dealing with very
large datasets.
This might all seem very glowing and make you think “why use SQL for anything”,
but there are occasions when we should not use MongoDB.
When you are working with a domain that is heavily reliant on relationships and very
join-heavy, such as when reporting across multiple tables, relational databases, such
as MySQL, are your go-to for a better fit with features.
Such areas of use are within accounting and finance ledgers, or where complex
scheduling systems with many constraints exist.
Another area where we should think twice about using MongoDB is where there is a
requirement for strict data integrity via constraints; then a relational database is the
better candidate. MongoDB can be used to enforce validation rules; however, this
does not afford the same level of integrity as can be provided by those constraints
within an SQL system.
When there is a requirement to conduct complex analytics, the SQL ecosystem
remains the go-to option due to its support for complex grouping and easy tooling.
If you are unable to determine the access patterns to the data, then the flexibility of
MongoDB can prove problematic as it is hard to query consistently as the schema
drifts, which is common due to the ” easy to store anything approach”.
To boil it down here is a summary of the Pros and Cons of Mongo DB and I will dwell
for a moment.
These references support the technical and academic discussion of MongoDB and
NoSQL systems presented in this presentation.