February 12, 2015

MongoDB 3.0

Old joke:

A lot has happened in MongoDB technology over the past year. For starters:

*Newly-released MongoDB 3.0 is what was previously going to be MongoDB 2.8. My clients at MongoDB finally decided to give a “bigger” release a new first-digit version number.

To forestall confusion, let me quickly add:

I should also clarify that the addition of WiredTiger is really two different events:

I’m not aware of any other storage engines using this architecture at this time. In particular, last I heard TokuMX was not an example. (Edit: Actually, see Tim Callaghan’s comment below.)

Most of the issues in MongoDB write performance have revolved around locking, the story on which is approximately:

In understanding that, I found it helpful to do a partial review of what “documents” and so on in MongoDB really are.

*One consequence — MongoDB’s single-document ACID guarantees aren’t quite as lame as single-record ACID guarantees would be in an RDBMS.

By the way:

Since its replication mechanism is transparent to the storage engine, MongoDB allows one to use different storage engines for different replicas of data. Reasons one might want to do this include:

In theory one can even do a bit of information lifecycle management (ILM), by using different storage engines for different subsets of the database, by:

That said, similar stories have long been told about MySQL, and I’m not aware of many users who run multiple storage engines side by side.

The MongoDB WiredTiger option is shipping with a couple of options for block-level compression (plus prefix compression that is being used for indexes only). The full WiredTiger product also has some forms of columnar compression for data.

One other feature in MongoDB 3.0 is the ability to have 50 replicas of data (the previous figure was 12). MongoDB can’t think of a great reason to have more than 3 replicas per data center or more than 2 replicas per metropolitan area, but some customers want to replicate data to numerous locations around the world.

Related link

Comments

9 Responses to “MongoDB 3.0”

  1. clive boulton on February 12th, 2015 4:56 pm

    3.0’s ability to have multiple plug-compatible storage engines. Sounds like AWS Lamdba architecture minus elastic cloud. Paves the way to build your own modern ecommerce ERP on-premises / in-cloud?

    -Migrate data from 30 y/o Cullinet / Basic 4, S/2.
    -Bring your own ERP code or build from Node.js
    -Build your own SAP HANA appliance.

    Coda. Priceless granularity in your review.

  2. Tim Callaghan on February 12th, 2015 5:45 pm

    Tokutek is indeed offering a MongoDB storage engine, http://www.tokutek.com/2015/01/announcing-tokumxse-v1-0-0-rc-0/

  3. Mark Callaghan on February 13th, 2015 9:31 am

    I expect the engine API to be more successful for MongoDB than it was for MySQL. The MongoDB API requires less from a storage engine than MySQL, so it is easier to implement as more work is done above the engine by generic MongoDB code. The outcome will be more robust implementations to choose from — WiredTiger, Tokutek, RocksDB and others I have yet to discover.

  4. Curt Monash on February 13th, 2015 9:56 am

    Mark et al.,

    Cool would be something that was a joint storage engine for MySQL and MongoDB, with good performance for both. Akiban could perhaps have been a basis for that if it had survived long enough. A little extra concurrency control would be needed to serve two top-layer masters at once, but I doubt that would be the biggest of problems.

  5. Tim Callaghan on February 13th, 2015 10:02 am

    Tokutek uses the same underlying storage technology in it’s MySQL and MongoDB offerings. As Mark said, the complexity of the MySQL storage engine API is so much more complicated than for MongoDB, so the cost of entry is likely higher than most are willing to pay.

  6. Mark Callaghan on February 13th, 2015 10:48 am

    Only Tokutek has managed to implement both MongoDB and MySQL engine APIs. RocksDB is attempting to repeat that. The MySQL engine API has always been hard and it is getting harder with more functionality pushed into it. InnoDB has gotten much better since Oracle became the owner of MySQL, but that also means we might end up in an InnoDB-only world — https://twitter.com/morgo/status/565207495035990017

    Maybe MySQL will target engine diversity when innovation and interest moves over to MongoDB. MyISAM could have been a lot better many years ago just by making it crash-safe for single-writer, multi-reader workloads.

  7. Tim Callaghan on February 14th, 2015 11:43 am

    Is it possible for MySQL to both innovate/improve InnoDB while retaining a storage engine API for others to participate? I’m starting to believe that an InnoDB-only world is inevitable.

  8. Multi-model database managers | DBMS 2 : DataBase Management System Services on August 24th, 2015 4:07 am

    […] two-policemen joke seems ever more […]

  9. MongoDB update | DBMS 2 : DataBase Management System Services on September 10th, 2015 6:33 am

    […] which was the biggest deal in MongoDB 3.0, will become the default in 3.2. I continue to think analogies to InnoDB are reasonably […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.