3 Tips for SQL Users New To MongoDB

As the digital world continues to store data that’s exponentially growing in amount and complexity, the advantages of using a NoSQL database such as MongoDB become crystal clear.

NoSQL databases are easier to scale. No schema or a predefined structure means more flexibility in data handling, especially if you have variable data. But companies still need a data model, that only if carefully thought-out, will translate to better and faster query performance.

Developers and database admins (DBAs) recognize these advantages. DB Engines ranks MongoDB as the 5th most popular database among all SQL and NoSQL databases. It is far and away the most widely deployed NoSQL database.

The move from SQL to MongoDB is happening, but it doesn’t necessarily mean it’s absolute. In our recent survey of Studio 3T users, around 80% still use a SQL database in their daily work, painting a reality that’s not as clear-cut as expected. Developers are dabbling in NoSQL land, but with one foot still firmly in SQL territory.

With this trend in mind, here are our top 3 tips for SQL users new to MongoDB that should help ease the transition – or database coexistence.

1. No Schema ≠ No Database Design

Many companies have decided MongoDB is the way to go, while others still question if the switch from SQL to NoSQL is worth it.

Square one for developers should always be to fully understand the database requirements. Only then can they can appropriately decide if SQL, NoSQL, or a hybrid approach best suits their project.

Companies like Wanderu opted to go for a NoSQL database completely from the get-go. They needed maximum flexibility to address their diverse set of train and bus travel data, which MongoDB sufficiently addressed.

But they also understood that this solution would be even better if they fused two NoSQL database types: one acting as a document store (MongoDB) and the other for graphs (Neo4j).

The result? A “docugraph” hybrid solution that syncs both MongoDB and Neo4j.

Wanderu is a perfect example of a database design process done well. They understood their data’s complexity and volume, which made NoSQL the irrefutable choice. And they pulled off a hybrid NoSQL approach in-house, knowing that this would further optimize data management.

Instead of combining two NoSQL databases, other companies have gone for a hybrid SQL + NoSQL approach.

MongoDB cites Craigslist as an example:

“For much of the history of Craigslist, MySQL was the only option for data storage, including its massive archive of classified posts. These posts are retained for years after they were initially posted for access by users (e.g., reposting an old job listing). The original Craigslist archive application simply copied the existing live database. If the live database schema changed, those changes needed to be propagated to the archive system.

This result was a hodgepodge schema and lengthy delays in making simple changes. For example, each ALTER TABLE statement took months to complete on the MySQL archive. When making changes to billions of rows in their MySQL cluster, Craigslist could not move data to the archive. Archive-ready data would pile up in the production database. During these periods, performance on the live database deteriorated.

Craigslist migrated their archive to MongoDB, keeping the live listings on MySQL. MongoDB’s flexible data model could easily accommodate changes to the schema, without affecting the performance of the live site.”

Main takeaway: Understand and anticipate your database requirements before making any major changes.

Consider especially how your reporting needs might be likely to evolve: a relational database is always going to be hard to beat for fast and efficient analytics.

But, as your needs change over time, MongoDB allows you to be agile, as seen in companies that have addressed problems by implementing hybrid approaches.

2. Master the MongoDB Query Language
(Or Use an IDE)

MongoDB uses BSON (Binary JSON), which is based on JSON (JavaScript Object Notation). If you know JavaScript, congratulations: you’ll breeze through writing those command lines.

But knowing JSON or JavaScript is not the whole story.

The mongo shell interface is quite cumbersome to navigate. And while MongoDB has excellent documentation, there’s a lot to learn, especially as queries can get pretty complex and time-consuming, pretty quickly.

Take a look at the db.collection.findAndModify(document) command, which is used for modifying and returning a single document.

A MongoDB GUI turned IDE like Studio 3T can serve as the ideal leg-up in such instances, especially when exploring collections and querying data.

Instead of writing out the entire shell script manually – with the inevitable typos, dropped brackets, and other bugs creeping in – you can simply locate the document to modify through an intuitive drag-and-drop visual query builder:

And edit the data in-place:

Studio 3T also has convenient tools to help beginners get accustomed to the MongoDB query language.

Take for example Query Code, which is an in-tool driver code generator that converts any query done through drag-and-drop to one of five languages: Java, JavaScript, C#, Python, and the mongo shell language (PHP was also recently added).

Or SQL Query, which benefits users two-fold. It allows them to use SQL to query MongoDB collections, while simultaneously showing how it translates to the MongoDB query language, as well as Java, JavaScript, C#, Python, and PHP.

Main takeaway: You will probably need to master BSON and the MongoDB query language to be an expert. And if you’re already there, congrats.

But for the rest of us data mortals, a purpose-built MongoDB IDE like Studio 3T can get you moving a lot faster through the somewhat alien NoSQL data landscape.

3. Get to Know How SQL Maps to MongoDB

As you transition from SQL to MongoDB, it’s important to familiarize yourself with how your SQL knowledge transfers to MongoDB.

MongoDB has compiled a helpful SQL to MongoDB Mapping Chart which outlines all the corresponding terms and statements.

SQL users might recognize MongoDB features like the Aggregation Pipeline which mimics the aggregation capabilities in SQL. But it will pay off to get accustomed to how aggregate operations map between SQL and MongoDB, so that you can take full advantage of MongoDB’s aggregation pipeline.

The Aggregation Pipeline is recommended for most MongoDB aggregate operations, but MongoDB also provides another aggregation method called Map-Reduce.

Unlike the aggregation pipeline which filters results as you apply operators at various stages, the map-process matches the data based on your query and emits them in key-value pairs, which are then further condensed and aggregated in the reduce-process.

The use cases for map-reduce are diminishing among MongoDB users, but the map-reduce feature might still be familiar to users of certain SQL databases like Oracle, where the functionality can be easily implemented.

If you’re still working on your MongoDB query language fluency, don’t worry. You can still get aggregate queries done easily with tools like Studio 3T.

Tools like the visual Aggregation Editor (above) and Map-Reduce make the querying process actually fun, while taking only half the time.

Main takeaway: Harness your SQL knowledge and find out precisely how that translates to MongoDB using their comprehensive documentation.

MongoDB features like Aggregation Pipeline and Map-Reduce might ring a bell among SQL users. But, as with related human languages, beware of false friends and mistaken assumptions, especially as you’re working your way towards MongoDB query language fluency.

Use a MongoDB IDE like Studio 3T to bridge the knowledge gap in the short-term, and save time on complex querying in the long-term.