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

21–30 of 133 posts

Re: A Year of MongoDB

#21

Post by mattzito »

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

Of course, most of the open source databases do sharding and replication and the like equally terribly, so it's not a perfect solution....

Re: A Year of MongoDB

#22

Post by ot »

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 developer. Or do they use a pre-made theme?

Re: A Year of MongoDB

#23

Post by nissimk »

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.

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) features are still in the development pipeline: Secondary indices, a db backup tool.

Re: A Year of MongoDB

#24

Post by lucian1900 »

jkldotio wrote: post #5

I just submitted a related article on Hyperdex which, although it's not Python, has a very good Python interface. https://news.ycombinator.com/item?id=5686973

Hyperdex looks quite interesting indeed, but after getting burned with new products claiming too much, I'm perhaps overly cautious. Also, it doesn't appear to be able to change schemas after creation, which is a significant issue.

Re: A Year of MongoDB

#25

Post by monstrado »

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.

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.

Re: A Year of MongoDB

#26

Post by tracker1 »

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 have to completely agree... in many cases a classic SQL RDBMS is probably best. In some (such as single records having very dynamically shaped data, where most instances can be brought forward based on a key alone, and searches are on a few keys), NoSQL is better. In some, having data replicated from one to the other works well, one for primary records, one for search/display. I've even contemplated scenarios where ElasticSearch could be a source record. It really just depends on what you want/need from your data and searching.

Re: A Year of MongoDB

#27

Post by jchrisa »

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…

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.

Re: A Year of MongoDB

#28

Post by realrocker »

In all of these discussions about MongoDb on HN, I always wonder why aren't people talking about the 1 % use cases for which it's good for. Maybe it is too obvious for most folks , but anyway I will just regurgitate the use cases Mongodb folks have documented officially. Here: http://docs.mongodb.org/manual/use-cases/. They have literally like three major use cases.

Re: A Year of MongoDB

#29

Post by eranation »

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 a good problem to have.

I would start with MongoDB, get a grip on what on earth the product is doing, finalize the schema on the fly based on A/B tests, customer feedback and analytics, only once the schema is finalized move it to a SQL database if needed.

If you are not using a good ORM + DB migration system, then MongoDB will make perfect sense when you are quickly iterating through ideas and trying to find a product / market match. You really have no clue how your data schema is going to look like in the end, why confine it at the start? the vast majority of startups sadly won't get even near the phase where they really reach scale related performance issues, so choosing MongoDB for prototyping your business absolutely makes sense to me.

Re: A Year of MongoDB

#30

Post by tracker1 »

ericcholis wrote: post #15

I think that some people misunderstand the primary purpose of Schema-less design. It's not about typing, it's about document flexibility. It's about getting rid of EAV tables (read: Magento) and storing document-specific information. Typing obviously comes into play, but is only half the topic. If you are building a system where the schema is the same for all records, then you really shouldn't be using Schema-less de…

In a few projects I've worked on in the past year and a half, I've used EntityFramework C#, and added a Data NVarChar(MAX) field to each table.. then I added a base class that has a UseData(Action) method that will pass a Json.Net based JObject in to be able to manipulate... adding additional properties that don't need to be indexed, and handling default values then becomes fairly easy with getters/setters. I also have a TempData table that is pretty basic where the core data is JObject based.

It's not the fastest option, but has worked pretty well for me. It did work out pretty well for holding temporary values, or other values that don't need to be indexed, or where the shape can change dramatically. I tend to store transaction details (credit-card, vs paypal, etc) in JObjects, since the shape can be different, with a key that can pull the right properties out via .ToObject()

In other cases, I've mirrored data to Mongo, so display versions of records can be pulled up denormalized from a single record/authority (the source records are across 30+ joins, and fairly expensive with a 50:1 view:edit ratio).

I will say that using MongoDB with NodeJS has to be the most seamless combination of tools I have ever worked with. I've written a few services based on this combination and love the development output. Fortunately my needs have been limited enough, that I have not hit too many walls. Most of the issues I have experienced relate to geo-indexes combined with other data, and the limits on multi-key indexes, and no secondary indexes.

I think more people need to consider how their data is shaped, and used and go from there.

Post reply on HN