3 ms·
From 2009 to 2012 I had a distributed database startup that competed with MongoDB. We used Paxos for replication and built the database with on-disk consistency
by Maro 12y ago
From 2009 to 2012 I had a distributed database startup that competed with MongoDB. We used Paxos for replication and built the database with on-disk consistency guarantees --- like the ones this article looks for and rightly obsesses over --- in mind.
https://github.com/scalien/scaliendb https://github.com/scalien/scaliendb
Outcome: you've never heard of ScalienDB; MongoDB brilliantly won by winning the hearts and minds of hackers and coders who don't care about such issues, but were able to get started quickly with Mongo (and got cool free cups at meetups). It turns out that's most engineers out there, definitely the initial critical mass to target for a database startup like Mongo.
Btw. the story behind Oracle is similar: early versions were basically write-only; read Ellison's book 'Softwar'. Of course there are other ways to get started: for example DBs coming out of academic research like Vertica seem to avoid this problem; in that case initial funding is basically provided by the gov't and when they create the company to commercialize they're already shooting for Enterprise contracts, skipping the opensource/community building phase of Mongo.
- dublinclontarf 12y agoI don't know, I got started with Mongo because ... it was so easy to start with, but come deployment time got bitten by a LOT of issues (which essentially negated any advantage in using Mongo). As a result of this experience I almost exclusively use PostgreSQL, and I've never EVER been burned by taking this approach. Sometimes I do use another DB but there has to be a seriously good reason for it.
- nazka 12y agoSame thing. I was a software dev, then I went to the back end with MongoDB and NodeJS, and I learnt what ACID means... Also about MySQL, many people forget it isn't ACID compliant either and just look at benchmarks or use MySQL "because Facebook uses it". I am sure that if any startup would use PostgreSQL it would avoid many problems on the road.
- toolslive 12y agowe actually evaluated scaliendb extensively (even contributed patches) but decided against it because it was immature and notoriously instable. Somewhat later, the open source repo scaliendb got pulled only to resurface years later. What happened?
- Maro 12y agoDo you mean Keyspace, the tech we had before ScalienDB? Anyway, the reason it was unstable was because we were early in the lifecycle, and as I described in the post, we couldn't get traction, so we also couldn't get investment, so it was just the two co-founders working on it. That's not enough, you need more manpower to do extensive testing of a distributed database which has its own storage engine, esp. when all of it is written in C++ for high-performance. Eg. we only had money to buy 3 servers, we used virtualization to test, but a virtualizated env. is _not_ a proper way to test a database.
- mdasen 12y agoIt's very true that MongoDB was able to target developers who didn't know or care about a lot of issues in the databases world. However, I wouldn't attribute Vertica's success to coming out of the academic world and being funded by the government. MongoDB targets a part of the market that is well served. There are loads of other options that work well like PostgreSQL. If you were targeting a truly distributed transactional database, you might have been trying to build something that has that order-of-magnitude-better characteristics, but MongoDB doesn't seem like that. Vertica, on the other hand, really targeted an area that wasn't well served and a decade after C-Store this area still isn't well served by anyone other than Vertica. ParAccel/Redshift isn't really comparable, though many go with it because Amazon will manage it for them. For MongoDB, the question is "how can we win over developers' hearts and minds?" Why use Mongo? Well, you like the query DSL and get annoyed by joins, and they have a great website and documentation, and we all know that joins are slow so without them everything must scale nicely. But realistically, there are a bunch of other options that could be substituted for it. And you're right that Vertica skipped the community aspect. The reason why is that something like Vertica isn't interesting if you don't have a lot of data. MongoDB targeted people who might have GBs of data that they wanted to store. There's a lot of people and community relations is going to matter, especially because there are lots of battle-tested alternatives. Since Vertica is most interesting when you have more data than can fit on a single machine's hard drives and might take hours to run analytics queries against, they're going to be targeting a much different market. Vertica also had the advantage of being associated with the biggest names in databases. Stonebraker has a Turing award. Even beyond that, the names you'd think of when you think databases were involved in C-Store and Vertica. If you're really creating something that has order-of-magnitude-better characteristics, you probably shouldn't target people that have 10GB of data to store. Someone once said something to the effect of: once there were more than 200 websites on the internet, it made more sense to target web frameworks at the websites that weren't the top 100 than solving for the problems of the top 100 sites. Most sites aren't going to need a massively distributed database. They might have dreams that the same codebase will scale from 100,000 visits/day to Facebook-scale, but they're just dreams. The fact is that for 10GB worth of data, your database probably wouldn't be better simply because that's already well-handled. In fact, distributed consensus on such small data would probably make your database worse. You really need to target people that you're solving a problem for. Vertica just isn't interesting technology for the vast majority of users and so they don't sell to the vast majority of users. MongoDB is interesting for those who want an alternative DSL and such.