Hacker News Reader

> Also think of the power that would be available if there were some relational table capability (true real MySQL ACID) right inside MongoDB whenever it was needed, if they were the 'same animal', rather than having to use two totally and completely separate DBs

Just use Postgres (or several other options) then? It has all that built right in if it's what you need. But...

> if you need NoSQL and also ACID in an app, which 99% of apps DO NEED, at some point,

...I doubt 99% of apps really need this.

> once an app grows beyond the round-one funding startup-toy phase and MongoDB falls flat in it's RDB capabilities.

Or don't try to force MongoDB to behave like a RDB and you won't hit those problems? I just moved a system from Postgres to MongoDB, and it's running faster on way cheaper hardware now. Not because either database is inherently better than the other, but the use case lined up with mongodb perfectly and the old model was leveraging Postgres really poorly. Eventual consistency is fine, and I can denormalize certain data for faster reads because I know it won't be modified later.

I don't know Postgres, and I just consider MySQL to be the leading best-in-class open source DB engine available. I realize that's debatable. But personally my mind is made up on that.

I think relational-type queries are so common that any significant app will need them. For my own side project (meta64.com) I'm using JCR-SQL2, on Apache Oak jackrabbit, so I get to do lookups fairly easily, but it sure would be nice to have a full-blown ACID RDBMS engine sitting right there to use also, in the same engine.

What does MongoDB bring that couldn't have 'built on top' of MySQL codebase, and used MySQL transational layer as it's underpinnings.

There are two challenges here. One is that MongoDB has a different data model than MySQL: hierarchical, schema-less documents instead of uniformly-typed flat tables. It's possible to map one to the other--look at Postgres' support for JSON datatypes. That involves extensions to both the storage format and query language, but it's certainly doable.

The bigger problem is that MySQL's local transactional isolation is nice, but not particularly helpful in a distributed context. Distributed transactions--even single-document ones--are still tough to implement correctly and efficiently. As an example, consider Percona XtraDB, or MySQL+Galera Cluster. Both are building on a serializable single-node system--but in a distributed context, they wind up failing to provide snapshot isolation, let alone serializability.

The point is that MongoDB writes/reads directly to File system. It could have been (and still could be retro-fitted) to ride on top of an RDBMS for all it's actual IO, and create a hybrid. I'm aware of all the orthogonal points you raised which have nothing to do with ruling out RDBMS as I/O

http://www.slideshare.net/NorbertoLeite/mongodb-wiredtiger-i...

Probably because there has been a lot of development in distributed databases in the last few years. Raft is fairly new, for one.

Taking really old code and trying to make it do new things is very very hard. After you've invested all that time and effort making mysql better, it's still a database owned by oracle.

Think how Java would have turned out if Sun made it to be cross compiled to C rather than run in a VM.

I haven't seen the codebase of MySQL, but it's open source and not "owned" by Oracle. The only reason anyone should want to start over is if that codebase itself was crappy code. I bet it isn't. Implementations of a robust RDBMS takes decades. MySQL is very mature. That doesn't act against it, it acts in favor of it. The better analogy is Linux. I'd be more likely to say "Linux is bad because of age" long before I'd ever say "MySQL is bad only due to age."

There are plenty of examples in the Language world also: Go, Rust, etc. All those new languages SHOULD have built on top of Java, for the same reason Mongo should have built on top of MySQL. BTW, Java DID leverage C++. The Java compiler IS written in C. Mongo didn't use any part of MySQL, but Java uses EVERY part of C.

Build Rust on top of the JVM? Buddy, you're a long way out to sea on that one.

Yeah, you are taking that sentence too literally. What I mean is we don't need a new language created every week. Java is already perfectly fine, and IF somebody finds something Java can't do, they shouldn't start from scratch and create a new language, but instead build and improve on what already exists: Java. It's like you can either stand on the shoulders of giants or you can start out at dirt level. I don't like starting back in the dirt. Not to mention the fact that every time somebody reinvents an already existing wheel, they just fragment the industry, because half the script-kiddies out there (not knowing any better) will simply jump on the bandwagon of whatever language most recently went viral. The Sisyphus approach to technological advancement.