Hacker News Reader

Comment by threeseed | Hacker News Reader

You do understand how MySQL et al are used in those cases right ? They are treated as dumb key value stores and sharded horizontally with joins done in the application layer. They are NOT your typical SQL deployment and the features you talk about are often meaningless.

And you are 100% wrong about MongoDB not scaling well. The stories you hear of people switching are never going back to PostgreSQL or MySQL they are going to the next level in scalability e.g. HBase or Cassandra.

View on HN

Like I said because the relational database doesn't scale horizontally you are forced to build a sharding layer into your application which introduces complexity into the application layer and limits your ability to use the relational features of the relational database. At that point you might as well just be using a key-value store that does the sharding for you and offers greater flexibility.

there is still transaction in one shard beyond SQL. I believe that ACID is the main benefit comparing with NoSQL store

My NoSQL store of choices gives me document-level ACID semantics along with eventual consistency, MapReduce, and replication.

Here's an example that explains how to get transaction-like guarantees from this kind of NoSQL data-store:

http://guide.couchdb.org/editions/1/en/recipes.html https://en.wikipedia.org/wiki/BigCouch

Interesting, that isn't transaction, it is just a workaround, and I don't think you can design your app like that which treat document as a transaction log. And then using view to generate the real information.

that's exactly how I design the parts of my app that need a transactional nature. Map/reduce views make it a breeze to query for a consistent aggregate view of the world.

This is not something new it's a well established technique from the relational world called "event sourcing"

http://www.martinfowler.com/eaaDev/EventSourcing.html

when everything is a write you don't have to worry about conflicts or locks, so that's nice, plus couch is really good at scaling write thoughput with small documents.

It's only a problem if your app needs cross-shard reporting. And things like Gearman can help you out with the application layer complexity of horizontal scaling.

Urban Airship switched from MongoDB to PostgreSQL.

I see they have since switched from PostgreSQL to Cassandra, though.

Reply on news.ycombinator.com