Hacker News new | comments | show | ask | jobs | submit login

I don't have any experience with HBase and CouchDB, but Cassandra and MongoDB will only shard automatically and transparently if your application does not do much writing. :-P

Also, the number of tables has nothing to with the problem of sharding, it's the amount of data you're trying to store.




HBase guy chiming in. Sharding in HBase is a bit different than the other NoSQL guys. HBase is super fast when doing random lookups and scans, so the developer is in complete control of his failure or success, depending on the row key design.

Good thing about HBase is that it's designed to hold a massive amount of data, I've seen people with hundreds of thousands of columns on a single row, it's pretty remarkable.


I suppose you would have an issue with MongoDB specifically if you were trying to rebalance from day one. But generally you wouldn't. I know Foursquare is using MongoDB's Auto Sharding in production and they would definitely have a lot of writes.

And the number of tables DOES matter for sharding if you are implementing it yourself.


Foursquare's experience with sharding MongoDB has, as far as I understand, been far from automatic and transparent (based on their blog posts and the word on the street).


I've heard Foursquare having a lot of problems with the terrible behaviour of MongoDB once your indexes go above 95% of the machine's memory.

Never with the sharding part though.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: