MongoDB CTO: How our new storage engine will earn its stripes | Hacker News Reader

MongoDB CTO: How our new storage engine will earn its stripes

zdnet.com

71 pointslucasjans53 comments

Open articleView on HN

BDB... seriously?

At this point why not just:

apt-get install postgres psql < "CREATE TABLE mongodb (key varchar[1024] NOT NULL PRIMARY KEY,value jsonb);"

then you get the best of both worlds.

Easy replication & sharding is appealing.

And replication for postgres is not easy? Sharding in postgres requires some plproxy/pgbouncer knowledge - but they don't cause as many problems in the future as mongodb. Me personally, when it comes to databases i go for the reliable first - then i can play with scalability.

That almost certainly implies you're not working on anything that requires horizontal scalability. That's a luxury not everyone can afford. Scalability, in almost all cases that actually require it, is the first priority.

It's like saying it's more important that the car drives reliably rather than everyone that needs to travel fitting into the car in the first place.

I think there are probably way too many people out there doing scaling before they're doing "getting things right". It's premature optimization that causes a lot of problems.

Naturally, there are plenty of people who do need to scale a lot, too, but presumably by the time they need to, they have a good idea of the problem and exactly how best to scale it.

That may be generally true but those two things are not mutually exclusive. Scalability doesn't come at the expense of getting things right, it just might come at the expense of certain features which applies to most distributed system problems.

Vertical scaling can take you a surprisingly long way

Choosing MongoDB isn't always about scaling immediately. It can be about ease of use and easy to configure replication. See my post here [1] here about our use case.

[1] -- https://news.ycombinator.com/item?id=8657458

The point at which you need to scale horizontally is (for most applications) when you hit data scale in terabytes.

When this is the case, you probably have enough money to hire someone who knows what they're doing with databases in order to set up a migration properly - you don't really need the ease of use configuration features.

SQL databases give data durability and transactions, integrity constraints, joins etc, which makes writing software a simpler experience (with a smaller chance of corrupting your data etc) which is generally a nice property to have when you're a small company that's moving fast and breaking things.

There are ton of IoT/data analytics startups with data scale in the terabytes that don't have enough money/resources to hire dedicated systems admin.

I currently work with postgres cluster with 16 shards on 4 machines. Overall database size is bigger than a few terabytes. Horizontal scaling with postgres is possible and it works more reliable than mongos. What's more, the exact data in mongo would require a few(dozens) times more disk space - so maybe scaling in mongo is easier, but the way i see it, mongo tries to solve problems that it actually creates.

eknkc has a point. Let me explain our needs and why we chose MongoDB over PostgreSQL (and I have been a huge fan of PGQL since before the MySQL/PGSQL flame wars).

Replication is not very easy to setup in PGSQL. Sure, I can do it, but our product is an on-prem product that our users are responsible for configuring and maintaining. Having them configure PGSQL replication would be something they're not willing to do. MongoDB's configuration of replica sets is quite trivial compared to PGSQLs.

I bring this up every time someone says "PGSQL > MongoDB", even on PGSQL threads where PGSQL devs participate and they admit it's not quite there yet, but that they're working on it.

And all that said, it is getting demonstrably better to configure replication in PGSQL, so it's going to get there some day and I can't wait.

>I bring this up every time someone says "PGSQL > MongoDB", even on PGSQL threads where PGSQL devs participate and they admit it's not quite there yet

Do you have a link to such a thread where pgsql devs admit its inferiority?

Here's a link to my thread. I don't know that I'd say "inferior" just "harder to configure." Please bear that in mind, that's all I'm saying here.

https://news.ycombinator.com/item?id=6693027

If your users have problems with configuring replication for something give them a tool to do it, i advise some template engine i simple python script. Once you write data to mongo, it is not your data - don't forget it.

Tell me how to set up a PG cluster where nodes can come and go as they like (for example without the need to reseed databases when they come online) in less than 30 minutes.

If you want to scale your system horizontally in 30 mins, you probably don't need to do it. It is fun in tutorials, but when you are dealing with tera(peta)bytes of data, you probably need to be more cautious.

This is just an incorrect assumption in my opinion. Say you are running on Microsoft Azure for example. There are no uptime SLA unless you run your service on at least two machines, because machines needs to reboot, be upgraded etc.

Also, if you take a look at perf when running PG on for example Azure or EC2, you will realize that IO is pretty slow but nodes are cheap. So you want to scale out early.

Running stuff on a single machine sounds like a perfect single point of failure to me. The actual size of the data does not affect wheter single point of failures are acceptable in a business.

I've seen so many people recommend PGSQL, saying its very simple, but when actually asked about how to set up a simple cluster which fulfills the absolutely basic requirements, then everyone just responds somethin similar to what you wrote. I find it very annoying to be honest.

seems fairly easy in pg et al too: http://instagram-engineering.tumblr.com/post/10853187575/sha... https://news.ycombinator.com/item?id=3058327

Question, how much data do you store in your Mongo cluster?

How many QPS does it perform?

What's your read/write balance?

Sorry, ticked off my OCD :)

It's better to say "key text" instead of "key varchar(1024)" and primary key already implies not null.

He was just going for an insult, it's not like he knows what he's talking about.

No, it's not BDB, from what I can see it's a storage engine designed by one of the architects of BDB. Looks quite interesting, but time will tell.

And I still wouldn't use Mongo!

I'm not a huge MongoDB fan, but I think it is great to see competition and evolution in this space.

From the article:

"In addition to compression and record-level locking, WiredTiger also gives MongoDB multi-version concurrency control (MVCC), multi-document transactions, and support for log-structured merge-trees, or LSM trees, for very high insert workloads"

I'd also love to see them add document joins at some point. That's a a big differentiating feature for RethinkDB, although I've found Rethink's syntax to be difficult to reason through.

Why do you consider joins a big differentiating feature for NoSQL storage solutions?

I can't speak for everyone, but I recently started on a project I chose RethinkDB for because of the support for joins. It's very nice to store documents, but it's a pain to have to resort to an SQL database every time you have relational data, or digress and issue multiple queries to patch in your relations. Just basic join support allows you to have both documents and relational data in the same database, made the sell for me anyway.

Most real world data is some mix of relational and unique / big bag of properties. The best solution is often somewhere in between (which is, for me, probably pgsql and its support of JSON, though I've achieved the same versatility with xml data types).

Here is a link to some more 'thorough' benchmarks that compare WiredTiger to many other database back-ends.

http://symas.com/mdb/inmem/

I'd say the MongoDB folks made a pretty safe choice here, since WiredTiger offers both LSM and Btree engines. I've recently completed some more benchmarks on all of the above-tested engines, and will be publishing the report soon (as soon as it's done being written...). Testing on-disk, with DBs 5x larger than RAM, at data sizes of 24, 96, 384, 768, 2000, and 4000 bytes per record. The important result to note is that LSM's high write speed advantage only exists for small record sizes, and for short durations. On long duration tests the compaction overhead stops them in their tracks, and at data sizes above 2000 bytes per record, LSM write amplification is too expensive (regardless of test duration). I.e., above 2000 byte records, Btrees are always faster than LSMs.

This result is particularly relevant for MongoDB, since a document store tends to have large records containing multiple fields, as opposed to individual values being stored as separate small records.

And in cases where that applies (large records), nothing comes anywhere close to LMDB's performance.

(A preview of the on-disk test results I mentioned was presented at BuildStuff.LT last week http://symas.com/mdb/20141120-BuildStuff-Lightning.pdf pages 103-on)

Howard I always found your benchmarks as well as your comments and explanations of the results to be very thorough and easy to understand. So thanks for that. I wonder if you had a look at ForestDB which is also based on a B+-tree like structure instead of LSM and claims to have very low write amplification. They have published benchmarks[1] but there is no LMDB or WiredTiger included.

[1] https://github.com/couchbaselabs/forestdb/wiki/Performance-R...

I attempted to test it a while ago; the test driver is included along with all the others https://github.com/hyc/leveldb/tree/benches/doc/bench

It crashed in all of my test invocations though, so I haven't looked at it since.

By the way, for those of you who are happy with just the raw data and coming to your own conclusions, you can get the advance look here: http://symas.com/mdb/ondisk/

Page now updated with formatted results and conclusions.

Gee, someone else collected all my forestDB comments together... http://www.reddit.com/r/programming/comments/2iau1n/forestdb...

With perfect candor, I believe forestDB's announcement was extremely premature.

But the old one is crap, right?

I am glad they finally introduced LSM trees and per document locking. But I think thats too little too late :-)

Agreed

Why on earth would it be too late? MongoDB is comfortably in the top 3 in terms of traction and they just fixed what many consider the primary technical argument against using it. Too late for what?

Here's my guess about some of the most utilized/popular databases:

* SQLite - it's everywhere thanks to mobile phones.

* Oracle.

* Microsoft's thing has to have a big following.

* Mysql.

* DB2 is not as big as Oracle, but IBM isn't some lightweight, either.

MongoDB gets talked about a lot, and probably used among people trying new stuff out, but I think a lot of mostly silent people wouldn't touch something like that for their important data with a 10 foot pole.

> SQLite - it's everywhere thanks to mobile phones.

and browsers...and tons of other pieces of software

"Microsoft's thing"

SQL Server is definitely one of Microsoft's best products - as well as being an excellent database engine it also is used by SharePoint, the various Dynamics applications (CRM & ERP) as well as being the "natural" choice for application development in .Net

If I had to guess I would suspect that, at least in terms of revenue, SQL Server probably tops Oracle and DB2.

I think you overestimate the reach of Oracle. They are no where outside fortuine 500 and thats not a lot of deployments.

MySQL is most likely the most deployed thanks to the LAMP stack's proliferation across all sorts of small and medium sites. After that it really would be a toss up between MS-SQL who has traction in the SMB space due to it being used for sharepoint and exchange, and PostgreSQL

but lets be honest the most utilized database is Access.

I do a lot of work with geo-spatial analysis and often work with with various counties and municipalities in my experience everybody has an Oracle database stuffed away somewhere storing the regions canonical geo-spatial data.

Even if each town had an oracle database squirreled away ( which they don't ) That still would not even come close to just the wordpress deployments (60 Million).

Sadly many more people use Excel as their database when they should be using Access.

I am generally curious about the source for your claim. Would you mind sharing, please?

MongoDB is placed 5th at DB-Engines, and I would suspect SQLite should actually be ranked higher since it used virtually everywhere.

http://db-engines.com/en/ranking

Cool site, and I like their methodology:

http://db-engines.com/en/ranking_definition

It's kind of how I did http://langpop.com/ back in the day (subsequently sold and it looks like they don't maintain it).

Reputation is hard to fix. Mysql today is still considered 'toy' db, even trough it is very stable and has good features. I think they lost industries with most money (financial and enterprise) to Cassandra and other competitors. Plus there are now solutions with aim to reimplement MongoDB API and be drop in replacement.

> Mysql today is still considered 'toy' db, even trough it is very stable and has good features.

I'd actually say that its feature set relative to other equally stable open-source DBs has gotten worse over the years, not better. Not because its gotten absolutely worse, but because other open source databases have gotten better faster.

Mysql has good selection of engines and good clustering.

MongoDB had a ton of momentum a few years ago but I think the argument being made is that it lost most of it due to the growing perception that it had fundamental design defects. Just anecdotally, a large number of companies I deal with had MongoDB at one time but I can't think of a one that uses it today. It was not replaced with a single thing but it was replaced for a variety of reasons.

As a long time observer of the database market with no skin in this particular game, in terms of regaining market momentum it is difficult to get past the reputation of being technically defective once that perception is broadly in place. To make matters worse, needing to completely replace the storage engine with a proper design will be viewed by some as an admission of that rather than an upgrade per se. It may be too little, too late for its long term prospects. By contrast, PostgreSQL is doing great right now; just about every company I talk to is using it somewhere.

Putting on my database engine designer hat, MongoDB did need to start from scratch with that storage engine; the original one was a naive design with a lot of problems. The sharding/replication design is still quite dodgy, which will hinder practical scalability. A new storage engine is a start but not enough if MongoDB wants to regain their momentum.

I have been waiting for this since a long time. Having implemented an OLTP application using MongoDB (luckily their write loads were low), I stopped using Mongo 2 years back because of the write bottleneck (it was still good for OLAP though). Good decision by the MongoDB team since they already have the market traction.

Reply on news.ycombinator.com