Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My background is in Cassandra and one company I worked for last year insisted that we use DynamoDB for a project.

Here are a few things that ended up being show stoppers.

1. Both the partition key and the sort key are capped at 1 field. In an attempt to "think Cassandra data model", the ugly workaround was to stringify and concatenate things at the application layer, then parse / split on the other side. This made the code unreadable.

2. DynamoDB-Spark integration is a second-class citizen. (Cassandra-Spark integration is first-class and well-maintained.)

3. The other thing that made code unreadable was the accidental complexity introduced by exception handling / exponential backoff we needed to implement to protect against accidental read capacity underprovisioning.

Although I made repeated pleas to switch to Cassandra, the (non-technical) CEO insisted that we keep using DynamoDB. I'm no longer at that company but I hear they have meanwhile switched to RedShift.



Cassandra isn't any better in those regards. For 1, Cassandra just does the concatenation under the hood and 3 happens all the time on Cassandra. The broken thing is using NoSQL as a DB, not Cassandra or DynamoDB.


Quick! Someone should tell Netflix and Apple, that. They've been using Cassandra and Datastax as their main DB for almost a decade.

They're always hiring. You should apply and show them the error of their ways.


Cassandra allows multiple clustering columns, it's not simple concatenation under the hood.

There are no hidden exponential backoffs in Cassandra in any of the hot query paths, period.

Suggesting that using nosql as a DB is broken is so ludicrous I'm not even going to try to refute it - you simply don't know what you're talking about.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: