Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I wish I knew about MongoDB a year ago

snmaynard.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: Things I wish I knew about MongoDB a year ago

#71

Post by thibaut_barrere »

jandy wrote: post #19
thibaut_barrere wrote: post #13

Earlier quoted context omitted.

MongoDB kicks ass in the following situations (real projects I did as a freelancer): - dealing with semi-structured input (forms with some variability) and storing as a document, all while being able to query across the data - used as a store to provide very flexible ETL jobs (with ability to upsert, filter/query, geonear etc) For those situations, I would definitely use MongoDB again. As a RDBMS replacement, I would…

To elaborate on the semi-structured input point: Monogo and it's kin are great for EAV systems ( http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%... ), where your entities can have an arbitrary number of fields (often user defined). Trying to build this kind of system in a traditional RDBMs can be quite tricky.

Thanks for elaborating! This is much needed and spot on :-)

A long while back I built a somewhat complex survey app: I can confirm it's fairly more complicated to handle with a RDBMs, compared to a document store.

Re: Things I wish I knew about MongoDB a year ago

#72

Post by thibaut_barrere »

gbog wrote: post #43
vidarh wrote: post #41

Earlier quoted context omitted.

Very interesting presentation, though the title of "heralding the death of nosql" is either intentionally exaggerating, or indicates the author doesn't understand all the reasons why people go to nosql databases. In fact, the presentation demonstrates why: Postgres has tons of really fantastic, awesome features that next to nobody uses because they are hidden behind layers of SQL-type incantations and/or require vari…

So you'd rather install a completely new storage engine and learn to use it than check a doc and install an extension to postgres?

The thing is that 10gen did a really, really good job at polishing the install process and documenting it to get people started.

No surprise to see the GIS part of MongoDB is built-in instead of an extension of some kind. I know a couple of people who used PG without even knowing there was a GIS extension.

Re: Things I wish I knew about MongoDB a year ago

#73

Post by jalada »

dude_abides wrote: post #22
thibaut_barrere wrote: post #13

Earlier quoted context omitted.

MongoDB kicks ass in the following situations (real projects I did as a freelancer): - dealing with semi-structured input (forms with some variability) and storing as a document, all while being able to query across the data - used as a store to provide very flexible ETL jobs (with ability to upsert, filter/query, geonear etc) For those situations, I would definitely use MongoDB again. As a RDBMS replacement, I would…

To slightly rephrase the OP's question: In what use cases does mongo kick postgres's ass? To the two points you mentioned: - semi-structured input can be saved as hstore type or as json type; - and for flexible jobs, you can use pretty much any popular language - PL/R, PL/Python, even PL/C if performance is really critical.

I don't know about JSON type but the annoying thing about hstore is everything is a string; there are no types.

Re: Things I wish I knew about MongoDB a year ago

#74

Post by np422 »

taligent wrote: post #53
diminoten wrote: post #11

Earlier quoted context omitted.

Mongo isn't so important to this question as ODB vs RDBMS. Here's some light reading: http://en.wikipedia.org/wiki/Object-relational_impedance_mis... MongoDB is just ODB, and MySQL is just RDB. Besides, postgres is the real future!

PostgreSQL is the PAST and it will forever remain there until it solves its biggest problems. It is the hardest out of all databases I've used to cluster, replicate, shard and manage. And the database world is moving towards scaling horizontally rather than vertically. I can push a button in say CouchDB to replicate and shard. Try doing that in PostgreSQL.

You have obviously never used Oracle RAC .. :)

Re: Things I wish I knew about MongoDB a year ago

#75

Post by niels »

dude_abides wrote: post #22
thibaut_barrere wrote: post #13

Earlier quoted context omitted.

MongoDB kicks ass in the following situations (real projects I did as a freelancer): - dealing with semi-structured input (forms with some variability) and storing as a document, all while being able to query across the data - used as a store to provide very flexible ETL jobs (with ability to upsert, filter/query, geonear etc) For those situations, I would definitely use MongoDB again. As a RDBMS replacement, I would…

To slightly rephrase the OP's question: In what use cases does mongo kick postgres's ass? To the two points you mentioned: - semi-structured input can be saved as hstore type or as json type; - and for flexible jobs, you can use pretty much any popular language - PL/R, PL/Python, even PL/C if performance is really critical.

You can't query the json type as easily in postgres. I would guess that is an important use case.

Re: Things I wish I knew about MongoDB a year ago

#76

Post by lmm »

arielweisberg wrote: post #44
mgummelt wrote: post #12

Earlier quoted context omitted.

I'm not aware of any database that solves this problem. Is there one? As far as I know, mysql reads must be distributed to the slaves at the application level, which has no knowledge of master/slave inconsistency. I suppose the time delta between master and slave can be queried, but that still doesn't protect from race conditions/inconsistent reads. This is actually why we chose to only utilize slaves for data redund…

Shameless plug (hey Tokutek is doing it), in VoltDB replication is synchronous so it doesn't have this problem. Latency in the current version is nothing to write home about, but in V3 latency with replication is 600-1000 microseconds. Group commit to disk is every 1-2 milliseconds. V3 also allows reads to be load balanced across replicas and masters so you gain some additional read capacity from replication. V3 also…

>Now go figure out what you don't get to keep ;-)

Cross-datacenter replication becomes a Really Bad Idea?

Re: Things I wish I knew about MongoDB a year ago

#77

Post by lmm »

chris123 wrote: post #68

Is MongoDB more marketing hype than quality product? I've heard it before and this article seems to point in that direction as well.

Yes, but only because it has ~infinite marketing hype.

It isn't and shouldn't be a general replacement for a RDBMS; it makes some interesting sacrifices for performance that you have to understand before using it. But it is very much a quality product; it makes some easy things very easy and some very hard things possible.

Re: Things I wish I knew about MongoDB a year ago

#78

Post by kokey »

chris123 wrote: post #68

Is MongoDB more marketing hype than quality product? I've heard it before and this article seems to point in that direction as well.

I think it's generally full of gotchas similar to that of SQL databases like MySQL and Oracle. In fact, most of the issues mentioned in this article, like delayed replication, indexed queries and using 'explain' are issues I've had to deal with in MySQL and Oracle. Most of these databases are fine out of the box for small scale use, but when you scale up you have to deal with these 'gotchas' like indexing, partitioning, bulk loading, and having to profile everything etc.

Re: Things I wish I knew about MongoDB a year ago

#79

Post by d0ugal »

thibaut_barrere wrote: post #67
dude_abides wrote: post #22

Earlier quoted context omitted.

To slightly rephrase the OP's question: In what use cases does mongo kick postgres's ass? To the two points you mentioned: - semi-structured input can be saved as hstore type or as json type; - and for flexible jobs, you can use pretty much any popular language - PL/R, PL/Python, even PL/C if performance is really critical.

I would have replied something similar if that was the question :-) (I use PG a lot these days). Agreed on the first point (but I'm not sure you get exactly the same type of flexibility in all my use cases - I'll have to make a closer comparison). For the second point, well not having to handle the schema for ETL jobs is sometimes fairly useful and removes a lot of cruft, that was part of my point (those ETL are code…

You can't query JSON easily and hstore is only one level deep. So, no, its not as flexible.

Re: Things I wish I knew about MongoDB a year ago

#80

Post by jeltz »

thibaut_barrere wrote: post #72
gbog wrote: post #43

Earlier quoted context omitted.

So you'd rather install a completely new storage engine and learn to use it than check a doc and install an extension to postgres?

The thing is that 10gen did a really, really good job at polishing the install process and documenting it to get people started. No surprise to see the GIS part of MongoDB is built-in instead of an extension of some kind. I know a couple of people who used PG without even knowing there was a GIS extension.

But on the other hand PostGIS being independent from PostgreSQL has resulted in the best opensource GIS database. And with the recent addition of CREATE EXTENSION the PostgreSQL extension installation process has been heavily streamlined. Before CREATE EXTENSION it was a mess for larger extensions.
Post reply on HN