3 ms·

These 'from the ground up' totally all-new-code approaches to DBs are just a scary proposition. Think of the thousands of man-years of effort that went into bui

These 'from the ground up' totally all-new-code approaches to DBs are just a scary proposition. Think of the thousands of man-years of effort that went into building MySQL, testing its codebase, and perfecting it's robustness (fail-proof-ness). What does MongoDB bring that couldn't have 'built on top' of MySQL codebase, and used MySQL transational layer as it's underpinnings. Sure, MongoDB gets all its performance gains from delaying writes to the DB (eventually consistent), caching in memory, and dispensing with ACID, however there is nothing about MongoDB that couldn't have been written to use the DB layer of MySQL at the point where it actually does its writes to disk. In this way, MongoDB would have revolutionized the world rather than mostly "fragmenting" the storage space. I guess there are those who will say that even using batch-commits, that MongoDB could never have achieved the performance it currently does (by bypassing any ACID) if it was built on top of MySQL. But regardless, why not focus efforts on improving MySQL batch processing performance rather than throwing it all out, starting from scratch, and writing directly to disk. I know MongoDB became a success, but I think that is 'in spite of' their decision to start from scratch and not 'because of' it. 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 if you need NoSQL and also ACID in an app, which 99% of apps DO NEED, at some point, once an app grows beyond the round-one funding startup-toy phase and MongoDB falls flat in it's RDB capabilities.

hmottestad 10y ago
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.
- ClayFerguson 10y ago
  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.
  - davidbanham 10y ago
    Build Rust on top of the JVM? Buddy, you're a long way out to sea on that one.
    - ClayFerguson 10y ago
      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.
aphyr 10y ago
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.
- ClayFerguson 10y ago
  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
  - aphyr 10y ago
    http://www.slideshare.net/NorbertoLeite/mongodb-wiredtiger-internals http://www.slideshare.net/NorbertoLeite/mongodb-wiredtiger-i...
    - ClayFerguson 10y ago
      WiredTiger is a great way to correct from the original 'wrong turn' mongo took when they decided not to build on an existing (RDBMS). WiredTiger may be vastly superior to the MySQL codebase, afaik, but i would tend to doubt it. And you know the code overlap would be at least 80%, in terms of what's going on, which proves my original thesis, which is they should have built on top of RDBMS to start with.
squeaky-clean 10y ago
> 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.
- ClayFerguson 10y ago
  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.

hmottestad 10y ago

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.

ClayFerguson 10y ago
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.
- davidbanham 10y ago
  Build Rust on top of the JVM? Buddy, you're a long way out to sea on that one.
  - ClayFerguson 10y ago
    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.

aphyr 10y ago

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.

ClayFerguson 10y ago
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
- aphyr 10y ago
  http://www.slideshare.net/NorbertoLeite/mongodb-wiredtiger-internals http://www.slideshare.net/NorbertoLeite/mongodb-wiredtiger-i...
  - ClayFerguson 10y ago
    WiredTiger is a great way to correct from the original 'wrong turn' mongo took when they decided not to build on an existing (RDBMS). WiredTiger may be vastly superior to the MySQL codebase, afaik, but i would tend to doubt it. And you know the code overlap would be at least 80%, in terms of what's going on, which proves my original thesis, which is they should have built on top of RDBMS to start with.

squeaky-clean 10y ago

> 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.

ClayFerguson 10y ago
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.