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

A Year of MongoDB

speakerdeck.com

Post reply on HN
Print view View original

51–60 of 133 posts

Re: A Year of MongoDB

#51

Post by cmircea »

mglukhovsky wrote: post #34
cmircea wrote: post #17

Earlier quoted context omitted.

Seems RethinkDB is still relational. Meh. If you're using C#, I'd recommend RavenDB.

Mike @ RethinkDB here-- the document model is similar to MongoDB in that you store JSON documents, and there are no schemas, so it's not a relational database. Our query language (ReQL) does support a lot of SQL-like queries, such as group-by and JOINs, but there are no relations defined. It's also worth noting that a great team has sprung up to build a C# / .NET driver for RethinkDB ( https://github.com/mfenniak/ret…

Hi Mike!

That's good to know, I'd like to give it a try, but only OS X and Linux seems to be supported.

Re: A Year of MongoDB

#52

Post by [deleted] »

ot wrote: post #22

Completely off-topic (well that's my nickname) but I'm seeing on HN more and more beautiful slide decks, from a purely esthetical point of view. This deck has beautiful fonts and a beautiful color scheme, and it is nicely designed. My question is: how are they made? Keynote, Powerpoint, HTML...? Are they made with the help of a graphic designer? They look completely outside of the reach of the average technical devel…

[deleted]

Re: A Year of MongoDB

#53

Post by pbreit »

ot wrote: post #22

Completely off-topic (well that's my nickname) but I'm seeing on HN more and more beautiful slide decks, from a purely esthetical point of view. This deck has beautiful fonts and a beautiful color scheme, and it is nicely designed. My question is: how are they made? Keynote, Powerpoint, HTML...? Are they made with the help of a graphic designer? They look completely outside of the reach of the average technical devel…

Similarly off topic: does speakerdeck provide a mbile version (not app)?

Re: A Year of MongoDB

#54

Post by walshemj »

mglukhovsky wrote: post #34
cmircea wrote: post #17

Earlier quoted context omitted.

Seems RethinkDB is still relational. Meh. If you're using C#, I'd recommend RavenDB.

Mike @ RethinkDB here-- the document model is similar to MongoDB in that you store JSON documents, and there are no schemas, so it's not a relational database. Our query language (ReQL) does support a lot of SQL-like queries, such as group-by and JOINs, but there are no relations defined. It's also worth noting that a great team has sprung up to build a C# / .NET driver for RethinkDB ( https://github.com/mfenniak/ret…

Interesting will have to have a look.

I built a tool to track rankings for part of Reed Elsevier and I used mogodb but in a hybrid form using mysql db for the fixed stuff and mongodb for the representation of the first 120 results for a given language,engine,locale tripple

Re: A Year of MongoDB

#55

Post by jbellis »

jeffdavis wrote: post #45
dmytton wrote: post #14

A few comments on the problems: * CPU bottleneck. The mongod is no usually bound by CPU except for building indexes on existing data (which shouldn't really happen in production). The issue he's talking about is contention between the web server (or workers) and the mongos. This isn't anything unexpected. It's recommended to put the mongos onto the application server and then you scale this by adding CPUs initially b…

"[EBS is] fine as a basic file store but should never be used for databases." Doesn't Heroku use EBS for all of their postgres databases? It may be the case that postgres works better on EBS than mongo does. Postgres has a traditional write-ahead log that minimizes (and spreads out) block writes and hides latencies. Mongo does not.

WAL only helps so much, since you also need seeks for reads. Cassandra has a WAL + log-structured storage + no read-before-update design, so it basically eliminates seeks on writes entirely, and EBS is still ass for workloads that don't fit in cache. Which, if you're bothering to use C*, is almost all of them.

Re: A Year of MongoDB

#56

Post by lebski88 »

bjt wrote: post #4
serichsen wrote: post #3

I can confirm that the map-reduce thing does not hold up to any performance-wise expectations.

I assume your experience was on version Now that 2.4 is out I'm interested in seeing how much the switch to multithreaded V8 has improved that. http://docs.mongodb.org/manual/release-notes/2.4-javascript/

I've run quite a few m/r queries against 2.4.2. The performance is still poor enough that'd I'd say it's only usable for occasional ad hoc work.

More seriously though running queries against a master node will regularly (maybe one in two queries) cause it to failover and elect a new primary. You'd think you should be able to run the queries against a slave, which you sort of can. Unless the result set is bigger than the maximum document size (16megs), in which case you're limited to the master as you can't write to a collection on a slave.

We're using Mongo fairly successfully but it has a lot of issues, particularly around administration tasks. Map reduce work gets done in Hadoop.

Re: A Year of MongoDB

#57

Post by jdoliner »

jonny_eh wrote: post #11

Sounds like rethinkDB would be the answer to our prayers. How close is it to being "ready"?

Hi jonny_eh,

We're currently winding down on release 1.5 which will include Secondary Indexes. After that the next release will be all about being production ready and having better performance. We're hoping to have that out 3-4 months from now. We'll be posting updates about the process via github twitter and our blog.

Re: A Year of MongoDB

#58

Post by mst »

cmircea wrote: post #48
monstrado wrote: post #25

Earlier quoted context omitted.

1. RethinkDB is a document orientated database, you store data very similarly to how you would in MongoDB / CouchDB. 2. Relational == Meh? Please elaborate, we're all waiting.

The relational model is not suitable for what most people are using relational databases for. That's why there's a whole bunch of ORMs, with varying degrees of magic. It's also the reason some people were crazy enough to use relational DBs for key-value storage (eg. Reddit).

"is not suitable" is no more a concrete answer than "meh".

Please try and give reasons rather than restating the assertion.

Re: A Year of MongoDB

#59

Post by ionforce »

neya wrote: post #19

This is the problem with most of the guys who go with MongoDB. Obviously, this person is very technical, so I am not flaming him nor accusing him, but this is my view of the rest of them who pick MongoDB without exactly having a clue as to why (hipsters) or when they should use a NoSQL db and when they shouldn't. I do not hesitate to admit that I was a hipster sometime back too. I chose MongoDB for many of my project…

What does "pure-white solution" mean?

Re: A Year of MongoDB

#60

Post by camus »

shin_lao wrote: post #43
neya wrote: post #19

This is the problem with most of the guys who go with MongoDB. Obviously, this person is very technical, so I am not flaming him nor accusing him, but this is my view of the rest of them who pick MongoDB without exactly having a clue as to why (hipsters) or when they should use a NoSQL db and when they shouldn't. I do not hesitate to admit that I was a hipster sometime back too. I chose MongoDB for many of my project…

I think the big problem is that most "NoSQL" engines are naive in their approach, thinking that the people at Oracle, Sybase, IBM, etc. are stupid. Very few people need scalability beyond what a regular RDBMS can do. So yes, RDBMS have limits, but you'll most likely never reach them.

No , there is something specific to MongoDB. Some NoSQL dbs are fine for some purposes ( multi-master sync for couchdb ,graphs for Neo4j ... )

MongoDB problem is that it promises too much and fail to deliver on a lot of levels. You cant expect to do all the operations one can do on a RDBMS on a NoSQL database and still scale horizontally,while maintaining data integrity. A good NoSQL db should have little features , but features that work very well. I like CouchDB for instance i use it in my apps to store customer infos that need to be synced accross multiple device, but i would NOT build an ecommerce app with it only...

NoSQL dbs solves specific problems. It does not solve the problems relational databases are for.

So selling MongoDB as a replacement for PostGreSQL or Mysql is a blatant lie.It will not work.

Post reply on HN