Slide 31
Slide 31 text
31
When not to use Cassandra:
• Tables have multiple access paths. Example: lots of secondary indexes.
• The application depends on identifying rows with sequential values. MySQL
autoincrement or Oracle sequences.
• Cassandra does not do ACID. LSD, Sulphuric or any other kind. If you think you need
it go elsewhere. Many times people think they do need it when they don’t.
• Aggregates: Cassandra does not support aggregates, if you need to do a lot of them,
think another database.
• Joins: You many be able to data model yourself out of this one, but take care.
• Locks: Honestly, Cassandra does not support locking. There is a good reason for this.
Don’t try to implement them yourself. I have seen the end result of people trying to do
locks using Cassandra and the results were not pretty.
• Updates: Cassandra is very good at writes, okay with reads. Updates and deletes are
implemented as special cases of writes and that has consequences that are not
immediately obvious.
• Transactions: CQL has no begin/commit transaction syntax. If you think you need it
then Cassandra is a poor choice for you. Don’t try to simulate it. The results won’t be
pretty.