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…
fwiw, postgresql 9.2 supports a json datatype. you can efficiently access/query json fields using plv8 ( http://code.google.com/p/plv8js/ ). so you could have: create table form_results ( id serial primary key, data json ); http://pgeu-plv8.herokuapp.com/ has more information.
Things I wish I knew about MongoDB a year ago
41–50 of 111 posts
Re: Things I wish I knew about MongoDB a year ago
#42Earlier 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.
Re: Things I wish I knew about MongoDB a year ago
#43Earlier quoted context omitted.
fwiw, postgresql 9.2 supports a json datatype. you can efficiently access/query json fields using plv8 ( http://code.google.com/p/plv8js/ ). so you could have: create table form_results ( id serial primary key, data json ); http://pgeu-plv8.herokuapp.com/ has more information.
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…
Re: Things I wish I knew about MongoDB a year ago
#44The inconsistent reads in replica sets is something we've come across with MySQL read slaves as well. I think it's a gotcha of that whole model of replication, rather than a MongoDB-specific issue.
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…
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 routes transactions directly to the node with the data so you don't use capacity forwarding transactions inside the cluster.
You get to keep transactions to. Now go figure out what you don't get to keep ;-)
Re: Things I wish I knew about MongoDB a year ago
#45Earlier 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…
fwiw, postgresql 9.2 supports a json datatype. you can efficiently access/query json fields using plv8 ( http://code.google.com/p/plv8js/ ). so you could have: create table form_results ( id serial primary key, data json ); http://pgeu-plv8.herokuapp.com/ has more information.
You can apply full text search on it, but that doesn't tell you if you're matching on a key or a value.
Re: Things I wish I knew about MongoDB a year ago
#46Earlier quoted context omitted.
Does Riak support distributed transactions? If not, I don't see how they handle the possibility of a read occuring during the replicated write.
No, Riak is nontransactional. But neither is mongo if it's important here. Riak is apparently getting some kind of strong consistency though. Calvin looks interesting for a nosql with distributed transactions.
Re: Things I wish I knew about MongoDB a year ago
#47Re: Things I wish I knew about MongoDB a year ago
#48Earlier 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!
Not sure what Wu-Tang has to do with this, but.... Seriously though, is Mongo an ODB, or a document oriented database? ODBs/OODBs imply a much different use-case and functionality, and I think we ought not conflate the two.
Re: Things I wish I knew about MongoDB a year ago
#49Earlier 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…
fwiw, postgresql 9.2 supports a json datatype. you can efficiently access/query json fields using plv8 ( http://code.google.com/p/plv8js/ ). so you could have: create table form_results ( id serial primary key, data json ); http://pgeu-plv8.herokuapp.com/ has more information.
Re: Things I wish I knew about MongoDB a year ago
#50Earlier quoted context omitted.
fwiw, postgresql 9.2 supports a json datatype. you can efficiently access/query json fields using plv8 ( http://code.google.com/p/plv8js/ ). so you could have: create table form_results ( id serial primary key, data json ); http://pgeu-plv8.herokuapp.com/ has more information.
It's just a JSON syntax validator. You can't index on part of the json, postgres treats it as a string. You can apply full text search on it, but that doesn't tell you if you're matching on a key or a value.