NoSQL and MongoDB — a practical deployment

Relational databases have been the backbone of enterprise IT for decades. But what if your data has no fixed schema? What if you need horizontal scalability without an Oracle licence? MongoDB 2.6 had just been released and we deployed it to production. Here is our experience.

Why we reached for MongoDB¶

Our client — a mid-sized e-commerce player — was dealing with a classic problem: a product catalogue with thousands of attributes that differed from category to category. In MySQL this meant either an EAV model (slow, complex) or hundreds of columns filled with NULLs. Neither option was sustainable.

MongoDB offered a document model where each product could have a different set of attributes. No ALTER TABLE, no migrations. Want to add a new attribute? Simply write it into the document. For catalogue use cases this was a game changer.

Deployment architecture¶

We deployed MongoDB 2.6 in a replica set configuration — three nodes, one primary and two secondaries. For our data volume (approximately 50 GB) sharding was not necessary, but the architecture was ready for future growth.

# Replica Set configuration
mongod --replSet rs0 --port 27017 --dbpath /data/db1
mongod --replSet rs0 --port 27018 --dbpath /data/db2
mongod --replSet rs0 --port 27019 --dbpath /data/db3

# Initialisation
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017" },
    { _id: 1, host: "mongo2:27018" },
    { _id: 2, host: "mongo3:27019" }
  ]
})

The application layer ran on Node.js with Mongoose ODM. Choosing Node.js was not accidental — JSON in, JSON out, no impedance mismatch between the application and the database. In 2014 this combination is still relatively fresh, but it works surprisingly well.

Data model — documents instead of tables¶

The biggest mental shift for a team accustomed to relational databases: denormalisation is OK. In MongoDB we do not do JOINs — instead, we embed related data directly into the document.

A product document looked roughly like this: name, description, price, category, an array of variants (each with its own price and stock level), embedded reviews, and metadata. A single query returned everything the frontend needed. No JOINs across five tables.

Of course, there are trade-offs. When a category name changes, you have to update it in all products. But for a read-heavy e-commerce workload this was an acceptable trade-off.

Indexing — the key to performance¶

MongoDB without proper indexes is slow. Very slow. We learned this the hard way. Our first deployment had response times above 500 ms for simple queries. After analysis using explain() we discovered that MongoDB was performing full collection scans.

• Compound indexes — combinations of fields that are most frequently queried together
• Text indexes — for full-text search in the catalogue (new in 2.6)
• TTL indexes — automatic deletion of session data after expiry
• Sparse indexes — for fields that only exist in a subset of documents

After proper indexing we achieved response times below 10 ms. The difference was dramatic. The lesson: MongoDB will not tell you that you are missing an index. You have to actively monitor and profile.

What surprised us positively¶

Development speed. Without the need to define a schema upfront, we iterated much faster. A new feature requiring a new field? Just start writing it. No ALTER TABLE, no migrations, no waiting for the DBA.

Aggregation Framework. MongoDB 2.6 brought an improved aggregation pipeline that covered most of the analytical queries we previously handled with complex SQL. Pipeline stages such as $match, $group, $unwind, and $project are intuitive.

Replica Set failover. We simulated the failure of the primary node. Election of a new primary completed in 12 seconds. The application automatically redirected writes. No manual intervention required.

What hurts¶

No transactions. MongoDB in 2014 does not support multi-document transactions. For the order process — where you need to atomically decrement stock and create an order — we had to implement the two-phase commit pattern by hand. Complex and fragile.

Write concern gotchas. The default write concern in the driver was “fire and forget”. Without explicitly setting w:majority you could lose data on failover. The documentation mentioned this, but not loudly enough.

Memory-mapped storage engine. MongoDB uses mmap for storage. On a server with 64 GB RAM and 50 GB of data this worked great. But as soon as the working set exceeded RAM, performance dropped dramatically. The WiredTiger engine promises improvements but is still experimental.

When MongoDB yes, when no¶

After six months in production we have a clear picture:

• Yes: product catalogues, CMS, real-time analytics, session storage, IoT data, prototyping
• No: financial transactions, systems requiring complex JOINs, reporting with complex relations
• It depends: user management (simple profiles yes, complex roles/permissions more suited to a relational DB)

MongoDB in the enterprise — with care¶

MongoDB is not a replacement for PostgreSQL or Oracle. It is a tool for specific use cases where the document model makes sense. Deploy it where the relational model creaks — and leave relational databases where they excel. Polyglot persistence is not a buzzword. It is pragmatism.