91–100 of 133 posts
Moral of the story is unless you can justify a NoSQL datastore for your particular solution and you can live without joins, stick with a regular SQL db.
After 6 intensive months with MongoDB to build my MVP, I just love it. For sure, it's not perfect. Lack of joins is a shame, but can be quite easily solved outside the database. But the ease of use and speed of development are such a HUGE advantage. Not having to break my schema into normalized relations and define it in the DB saved me literally days of work. I can imagine a case that 1 year from now, when our produ…
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…
That statement doesn't make sense to me. One of the first things you do with a sql database when you reach moderate scale is denormalize data so you don't have to do joins, or shard which prevents a lot of joins. Joins are super convenient, but they don't scale.
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…
"till it reached some kind of moderate scale where I realized it was a terrible choice going with a NoSQL db (Sometimes, I'd have to duplicate data because there were no Joins, etc)" That statement doesn't make sense to me. One of the first things you do with a sql database when you reach moderate scale is denormalize data so you don't have to do joins, or shard which prevents a lot of joins. Joins are super convenie…
On nearly all of the cases, they are very usefull, but once in a while one of them gets too slow, so you make a bit more of work enforcing the consistence by hand, accepts a bit more of risk, and denormalize it.
Throwing all of them away because a few may create problems later is a bit of an over reaction.
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…
Earlier quoted context omitted.
"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 just don't like the "right tool for the job" argument. Then say the "right technology for the task" then. There is no ONE database that works perfectly in every situation.
Earlier quoted context omitted.
"[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.
I agree in general though.
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…
Earlier quoted context omitted.
"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.
Another thing that you win with the document model is lots of primary key lookups, making it easy to model your data access around your hot path. http://blog.couchbase.com/performance-oriented-architecture