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

81–90 of 133 posts

Re: A Year of MongoDB

#81

Post by AlisdairO »

cmircea wrote: post #63
mst wrote: post #58

Earlier quoted context omitted.

"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.

That blog post is based on some pretty flawed understandings. The reason for normalisation (which I assume is what it's referring to) is not simply to improve write performance - indeed, it can make that slower too. It's because normalisation makes maintaining data integrity vastly easier. It can also improve performance, in as much as it improves the cacheability of your data by reducing its size. Further, when it comes to more complex data types, that's not a fundamental limitation of relational DBs - Postgres, for example, supports some quite rich datatypes.

I have no doubt that document stores save you a bit of time in the early stages of a system. Not sure if I'd trust them to be reliable in the long run as your application-stored schema changes over time, though.

Re: A Year of MongoDB

#82

Post by davidw »

AlisdairO wrote: post #79
shin_lao wrote: post #69

Earlier quoted context omitted.

You are pretty violent against MongoDB. Any reason why?

I suspect the reason that Mongo attracts so much hate is that it's more heavily marketed/evangelised than other NoSQL DBs - so more in the public eye and people expect more from it. Since the reality is that Mongo is not yet a technically strong product (regardless of its merits in terms of ease of use and getting simple things done quickly), it's bound to attract more negative attention.

Bingo. My brief experience with Mongo a few years ago was in a situation where it got selected in order to use something "new and cool". My job was to produce some reports from the data. Guess what reports require? Joins. The whole mess was slow and sucked, and the client belatedly realized that MongoDB was a shitty choice for what they needed, which could have been handled by Postgres without breaking a sweat.

Re: A Year of MongoDB

#83

Post by cmircea »

frenchy wrote: post #65
cmircea wrote: post #49

Earlier quoted context omitted.

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'?

http://en.wikipedia.org/wiki/Relational_database

Re: A Year of MongoDB

#84

Post by jbigelow76 »

cmircea wrote: post #17
jonny_eh wrote: post #11

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

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

>> If you're using C#, I'd recommend RavenDB

I would give anything to get back the time I spent developing my app using Raven and develop it with SQLServer instead. Ironically I feel so trapped by the schemalessness now that there is a not insignificant amount of data to port if I do need to make a significant schema change.

DO NOT FEAR THE JOINS!

Re: A Year of MongoDB

#85

Post by adambard »

eranation wrote: post #29
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…

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…

When I develop against MongoDB in python, ruby, or clojure, I consider it less a database and more a persistence layer for my dicts/hashes/hash-maps, with a handy-dandy query functionality built in.

Hell, in clojure I usually develop against a hash-map of hash-maps stored in-memory until the project gets far enough to re-implement the data layer (which I've hopefully abstracted well enough to not be a big deal).

Think of Mongo less like a schemaless postgres, and more like a persistent redis. Ease-of-use is its true advantage, and I think anyone who exceeds its capacity should be happy to have the problem.

Re: A Year of MongoDB

#86

Post by smiler »

jbigelow76 wrote: post #84
cmircea wrote: post #17

Earlier quoted context omitted.

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

>> If you're using C#, I'd recommend RavenDB I would give anything to get back the time I spent developing my app using Raven and develop it with SQLServer instead. Ironically I feel so trapped by the schemalessness now that there is a not insignificant amount of data to port if I do need to make a significant schema change. DO NOT FEAR THE JOINS!

What did you not like about raven?

Re: A Year of MongoDB

#87

Post by Xorlev »

zimbatm wrote: post #76
jdoliner wrote: post #36

Earlier quoted context omitted.

Disclaimer, I work for RethinkDB a competitor of MongoDB. I completely agree with you that NoSQL is not a pure-white solution but I disagree that it's only useful for specific use-cases. NoSQL has frequently been touted as this magic concept that makes databases scale well. It doesn't as many of the poorly scaling NoSQL databases on the market today show you. The most you can say is that it maybe lets you ignore a fe…

Isn't Google BigQuery a SQL on top of a schemaless database ?

Well, SQL and NoSQL get thrown around a lot but generally people mean 'standard relational' vs. 'newer, potentially schemaless' DB.

By a 'SQL/NoSQL' view, Cassandra has CQL which isn't ANSI standard but close enough to be a SQL.

Re: A Year of MongoDB

#88

Post by Xorlev »

mattzito wrote: post #21
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 used to spend a lot of time in the RDBMS space, and I'd hear the DBAs bitch about how NoSQL was just a bullshit excuse for not having any discipline around your data model, and I'd defend it, saying, "Well, you have to understand, certain use cases, etc. etc. etc." And then I see an presentation like this and think, "Yes, of course, you should have put that stuff in a relational database, what were you thinking". O…

I tend to take the view of RDBMS works until it doesn't. Most cases that things like click data or event data that ends up taking billions of rows, in which case you aren't going to want it in a RDBMS anyways (you'd like to, but hah).

I'd like LevelDB on MySQL personally.

Re: A Year of MongoDB

#89

Post by Xorlev »

thedufer wrote: post #41
ericcholis wrote: post #16

Earlier quoted context omitted.

Agreed on all counts. Sounds like he is complaining more about issues with VM performance than MongoDB performance on VMs. The joins statement kills me. If somehow the database design requires joins, Mongo is fast enough to run two queries and then let you work with them in code.

> If somehow the database design requires joins, Mongo is fast enough to run two queries and then let you work with them in code. That's definitely not true. What if you were planning on filtering after the join? You may find yourself pulling millions of records. The bandwidth alone would bring you down. I work with MongoDB, and once in awhile I really miss joins. You can't emulate joins in any reasonable amount of t…

+1 joins are efficiently done by databases, not by applications. At least in any reasonable dataset.

Joining in application works for a few thousand records.

Re: A Year of MongoDB

#90

Post by Xorlev »

adambard wrote: post #85
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…

When I develop against MongoDB in python, ruby, or clojure, I consider it less a database and more a persistence layer for my dicts/hashes/hash-maps, with a handy-dandy query functionality built in. Hell, in clojure I usually develop against a hash-map of hash-maps stored in-memory until the project gets far enough to re-implement the data layer (which I've hopefully abstracted well enough to not be a big deal). Thin…

I tend to treat Mongo similarly. At my job, we hate Mongo and I've stood up and cursed it more than once.

Plenty of personal projects end up running on Mongo, because it has a rich query layer for quick hacking. I also never expect these to exceed the amount of RAM on my machine either.

Post reply on HN