2

I am looking to store data in Cassandra, due to the fact that I have many writes that need to perform well, and all my reads can be done based on primary key. While doing the data modeling, however, I have come across a question.

I am planning to store (potentially) large chunks of text in my rows, and for some rows, there will potentially be several (or in extreme cases, as many as hundreds) of these columns in a single row. In the most extreme of these cases, it is possible that a row could comprise up to hundreds of MB of (uncompressed) text.

I am wondering what the performance implications of this arrangement are, and whether I would be better off changing my data modeling or going with a completely different storage strategy. I understand (from [1]) that an SSTable, once written to disk, will contain whole partitions, but I'm also wondering whether the same is true for the commit log; would adding a column to the row result in the entire row being written to the commit log?

[1] https://docs.datastax.com/en/cassandra/2.2/cassandra/dml/dmlHowDataWritten.html

2
  • Will your application often be deleting these columns often, or rarely? Frequent deletes of columns in large rows can lead to more CPU/memory churn in Cassandra, due to needing to read the rows until the "active" column cell is found.
    – Castaglia
    Jul 13 '16 at 16:13
  • Updates would happen frequently to static columns, but never to the clustered columns. There would be deletes of whole partitions, but never of clustered rows.
    – Mark
    Jul 13 '16 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.