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

61–70 of 133 posts

Re: A Year of MongoDB

#61

Post by mglukhovsky »

cmircea wrote: post #51
mglukhovsky wrote: post #34

Earlier quoted context omitted.

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.

That's right-- an enterprising soul is working on porting us to FreeBSD (https://github.com/rethinkdb/rethinkdb/pull/688), but we are notably missing Windows support-- we hope to get to it after adding some more core features (secondary indexes, etc.)

Re: A Year of MongoDB

#62

Post by daurnimator »

cobbzilla wrote: post #50
eranation wrote: post #29

Earlier quoted context omitted.

All I can say is this: if the saying "Always plan to throw away your MVP" is true, then I can't see any other storage solution other than MongoDB (or a similar schema-less document storage DB) for MVPs. The speed of development and flexibility are simply worth it. Yes, it is hard to refactor a live product and move it from MongoDB to MySQL / Postgre but was done before and you only do that if you get traction, so its…

You make a VERY big "if" in your first sentence, one that (admittedly anecdotally) I've very rarely seen hold true in tech companies. Much more often, the MVP becomes the product, and all those shortcuts and poor design decisions come back to kill your productivity when it becomes necessary to refactor foundational tech/designs that have metastasized throughout the codebase. I am curious if this is other folks' exper…

MVP is used to get funding; which extends your runway so you have time to make your product correctly.

Re: A Year of MongoDB

#63

Post by cmircea »

mst wrote: post #58
cmircea wrote: post #48

Earlier quoted context omitted.

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.

http://ayende.com/blog/153026/embracing-ravendb

The points in the blog post apply to most non-relational databases.

Re: A Year of MongoDB

#64

Post by frenchy »

jeffdavis wrote: post #40
jchrisa wrote: post #27

Earlier quoted context omitted.

Please don't conflate MongoDB and NoSQL. NoSQL is about the right tool for the job. For instance many of our Couchbase customers are very technical and risk averse. They choose Couchbase because other solutions (often MySQL or Oracle) have become the wrong tool for the job, as requirements change. Mongo is a little different bc they actively position themselves as a MySQL replacement for your average Rails app.

"NoSQL is about the right tool for the job." I never liked that rationale: * The job almost certainly will change. Data lives a long time, usually much longer than the original application. * It's likely to conflate marketing claims with actual fitness for a purpose. A special-purpose system with special-purpose marketing may sound great if the special case lines up with what you're doing. But that doesn't mean that…

I've heard DBA complain that many programmers see data as not all that important: that the data simply exists to run the program. This obviously not the case in any serious real-life environments, but I think it's the sort of attitude that many NoSQL supporters have.

Re: A Year of MongoDB

#65

Post by frenchy »

cmircea wrote: post #49
nissimk wrote: post #23

Earlier quoted context omitted.

RethinkDB sounds like it's document oriented from their site: "RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn." Also not sure why relational == Meh. RthinkDB does sound promising though not ready for primetime. The following (critical)…

My apologies, I thought RethinkDB was a relational database; the mention of joins gave me the thought, as I don't know of any other non-relational database that directly supports joins.

What do you mean by the term relational? Do you just mean 'Doesn't use JSON'?

Re: A Year of MongoDB

#66

Post by nissimk »

mglukhovsky wrote: post #35
nissimk wrote: post #23

Earlier quoted context omitted.

RethinkDB sounds like it's document oriented from their site: "RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn." Also not sure why relational == Meh. RthinkDB does sound promising though not ready for primetime. The following (critical)…

Definitely, we're leaving the production-ready tag off until we've built in some of these features. Secondary index support is ready to go, we'll be releasing v1.5 with it in a few days.

I read your site and your system sounds very promising as I said in my previous post. It seems like you've identified some of the key problems with earlier noSQL implementations and that you're trying to solve them. Schema free was always a feature I could understand but "no joins" always sounded like an anti-feature to me. The promise of consistency and automatic sharding / replication is very nice but I'll remain skeptical until I hear about some production implementations.

Re: A Year of MongoDB

#67

Post by rwj »

ionforce wrote: post #59
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?

In this case, I believe it means all benefit and no disadvantage.

Re: A Year of MongoDB

#68

Post by [deleted] »

ionforce wrote: post #59
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?

[deleted]

Re: A Year of MongoDB

#69

Post by shin_lao »

camus wrote: post #60
shin_lao wrote: post #43

Earlier quoted context omitted.

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 ,…

You are pretty violent against MongoDB. Any reason why?

Re: A Year of MongoDB

#70

Post by davidw »

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…

> PIOPs are the way around this but local instance storage is also an option.

PIOP is not ringing a bell - I'll stick my neck out and ask what it is.

Post reply on HN