61–70 of 111 posts
>Range queries are indexed differently If I'm reading your description right, this is hardly mongo-specific. Try it in mysql, for example: (index is [:last, :first]) select first from names where last in ('gordon','holmes','watson') order by first; An index is an ordering by which a search may be performed - to illustrate, the index for my small table looks pretty much like this: gordon, jeff holmes, mycroft holmes,…
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…
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…
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.
Postgres does the same---its an incredibly powerful database with a large suit of features that make application development both easy and sane. To the vast majority of projects where you won't outgrow a single server, it makes sense to use it.
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.
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 back in (if by "vertical scaling" you mean "scaling on one box"), and probably for a while.
Postgres is doing an excellent job at both.
I do agree with the less-exaggerated point that postgres really needs to improve its multi-machine scaling. But it's far from a solved problem on any system under discussion.
Earlier quoted context omitted.
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.
As far as I can tell, Riak blows mongo away for this particular criteria.
Earlier quoted context omitted.
When you have so many writes that sharding isn't enough. When you make changes so fast you need a liquid schema. When you want to make your boss learn map-reduce so he can query the data. When the application can take care of integration and not the database itself.
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…
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.
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-based, only relying on MongoDB as a flexible store).
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…
For those like me who have no ides what ETL stands for: https://en.wikipedia.org/wiki/Extract,_transform,_load
Here is a presentation (slides + video) I gave about a Ruby ETL, for instance. It illustrates the typical use cases I run into.
Earlier quoted context omitted.
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.
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.
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).