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

81–90 of 111 posts

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

#81

Post by jeltz »

thibaut_barrere wrote: post #70
sgolestane wrote: post #26

Earlier quoted context omitted.

Since we are a mysql shop, for this use-cases I serialize and store the form as xml in a CLOB column. For any field that needs to be searched on, I create an additional column. Disadvantage of this is you can't run mysql queries against the data stored in the CLOB column.

Adding column per searchable field is precisely what I wanted to avoid :-) If you need to store multiple forms types, it gets hairy very fast. MongoDB allows to query inside the data (which is not a blob in that case).

So does PostgreSQL, but I have no idea about MySQL. You can run xpath queries against XML documents, and you can also index specific xpath queries (there is no general indexing infrastructure for XML in PostgreSQL). For JSON no path lookup functions are included in the core yet, but I assume there are extensions which add them.

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

#83

Post by jeltz »

mattparlane wrote: post #23
dia80 wrote: post #5

Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low leve…

My number one reason for choosing MongoDB is replication that just works out of the box and doesn't require either a read lock or shutting down the master to set up a new slave.

Serious question: What database requires read locks or shutting down the master for setting up a new slave? Is it MySQL?

Both sounds like really weird requirements for replication which defeats half the purpose of having it. PostgreSQL has never had any of these two problems. Still working on improving usability but with the addition and improvements of pg_basbackup I would say it is almost there. Hopefully 9.3 will get timeline switching to simplify failover.

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

#84

Post by leif »

DanWaterworth wrote: post #66
leif wrote: post #40

Earlier quoted context omitted.

This will be obvious, but I work at Tokutek. > When you have so many writes that sharding isn't enough. TokuDB does indexed insertions very fast. [1] We've even plugged ourselves in underneath MongoDB (just for fun) and we beat them too. [2] > When you make changes so fast you need a liquid schema. TokuDB supports lots of schema changes with zero downtime. [3] > When you want to make your boss learn map-reduce so he…

In my experience, it's not just throughput that's important, but also 99th percentile latency. If I understand fractal trees correctly, you sometimes need to rewrite all of your elements on disk. How do you do this without causing lag?

That's happily not how fractal trees work, at all. We have a few talks online describing how they work. Zardosht has one here http://vimeo.com/m/26471692 . I thought Bradley had a more detailed one at MIT but I can't find it right now. (EDIT: found it! http://video.mit.edu/watch/lecture-19-how-tokudb-fractal-tre...)

Basically, I think you're thinking of the COLA. What we implement does have a literal tree structure, with nodes and children and the whole thing, so at any point you're just writing out new copies of individual nodes, which are on the order of a megabyte. At no point do we have to rewrite a large portion of the tree, so there aren't any latency issues.

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

#87

Post by andyzweb »

jeffdavis wrote: post #64
taligent wrote: post #53

Earlier quoted context omitted.

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.

"And the database world is moving towards scaling horizontally rather than vertically." I think that's an oversimplification. Two counterpoints: * Database systems will always need to make heavy use of locality. The speed of light means that synchronizing access over long distances (even medium distances -- light only goes about a foot per nanosecond) will always be a challenge. * Multi-core means vertical scaling is…

postgres does horrible with multicore unless you have many concurrent pooled connections. fork-and-forget

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

#88

Post by jeremyjh »

dia80 wrote: post #5

Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low leve…

One issue with MySQL in large databases is that schema changes are extremely expensive, so much so that you'll be making design decisions around it (e.g. how do we implement this feature without executing our two-day alter table statement). Not all RDBMS have this problem to such a degree but none can escape it entirely.

A lot of the gotchas that he notes are related to design trade-offs with different default behavior than an RDBMS typically would have. For example as your system gets large enough in MySQL you may find you have to do asynchronous replication as well, and then you will have similar problems with dirty reads.

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

#89

Post by jsemrau »

jameswyse wrote: post #85

One thing I love MongoDB for is it's geospatial indexing abilities: http://www.mongodb.org/display/DOCS/Geospatial+Indexing Was a really nice surprise when I was building a location based web app.

That was our use-case as well. And it works fine for this but just in the application layer. We are not using Mongo for data storage (at least we are not trusting it to hold it for long)

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

#90

Post by thibaut_barrere »

jeltz wrote: post #80
thibaut_barrere wrote: post #72

Earlier quoted context omitted.

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.

PostGIS is miles, miles ahead, for sure! Yet even "create extension" sounds a bit weird to most newcomers (me included at first!), especially against "built-in basic GIS".
Post reply on HN