10gen raises $20m for MongoDB (opens in new tab)

(techcrunch.com)

94 pointsnosh14y ago23 comments

23 comments

9 comments · 2 top-level

zerosanity14y ago· 4 in thread

I really wish they would straighten out their documentation. I've only looked a few times but it seems very conditional in the description of features like replication sets, etc. I think they should have it organized like the MySQL site has it. E.g. view 5.0 documentation here, or 5.1 here, etc.

The way it is now I couldn't tell you right away what version supports what just by glancing at the docs for a minute.

knbanker14y ago

Thanks for mentioning this. We're just now starting on a massive reorganization and rewrite of the docs. Look for some solid initial progress by mid-October.

jqueryin14y ago

I definitely concur with the statement on organizing by release cycle (or perhaps using the PHP convention of showing deprecation and support version information for different calls).

I recently ran into issues with replicaSet myself; finding it hard to locate documentation on using user-based authentication. It boiled down to me eventually locating the necessary info on the Master-Slave page for ensuring I did a db.addUser() on the slave's local db. All in all, I'm much looking forward to a rewrite of the documentation.

kennu14y ago

And I hope they spend some resources in making MongoDB a first class citizen for Django / Rails projects. Like a complete drop in replacement for MySQL. It's already pretty close. Life would be so good if you could use MongoDB as the default for any project and all gems/apps would just work with it. Goodbye migrations, hello autosharding.

TylerE14y ago

I don't really think that's desirable. Trying to make a document database pretend it's a relational database may work "ok" for simple things, but when you have code that expects to do things that practical in SQL (think: joins, etc) it'll all end in tears.

1 more reply

deweller14y ago· 3 in thread

From what I've read, I wouldn't pick MongoDB my first choice for a large data warehouse. Maybe 10gen can change that.

colonhyphenp14y ago

Can you go into some more detail why you would not choose it? I am curious.

deweller14y ago

I don't have facts to back up my opinion - It is formed by memories of articles I've read.

I believe CouchDB is a better choice for very large data sets because of its design.

+ CouchDB uses a Map Reduce design that I believe would scale better over very large data sets. + CouchDB always stores data in a consistent state on disk. You can literally pull the plug on the server at any time and the data will never be inconsistent.

MongoDB is geared for performance and is a great bridge between a relational database and a high-performance No-SQL database. But I don't recall that it's strength is handling large datasets.

3 more replies

noodle14y ago

i would not use it in future projects, myself, because my company is currently using it in several products in several different ways, and it has been nothing but headaches, problems, etc..

the theory behind the thing is great. in reality, its buggy and not fun to work with.

j / k navigate · click thread line to collapse