Data modelling to replace Redis


I’m evaluating Scylla to replace Redis as key-value DB, which for our simple use case I’m quite confident that it would be a good alternative. We are more bound to read latencies than throughput, though seemingly low double-digit is quite possible for Scylla, which would meet our SLA.

I have a more obscure use case currently with Redis, and I’m wondering if the following data model would be acceptable/good/bad in the Syclla world. I am mainly used to document DBs, though sharding and ops cost of Mongo is awkward at best, and mongo’s defaults are quite loose and probably should be stricter, but then it loses its speed. Right now, we compress a JSON payload and just look it up by key. We could in Mongo, not compress it and filter/order by any property in the raw JSON payload. We do need low latencies, ideally less than 50ms, but closer to single digits would be ideal. We could layer Redis over Mongo, but that makes it more complex.

What I’m wondering is can we at insertion time break some of the key JSON payload properties out into columns and continue to store the compressed JSON, but use only the properties we care to sort on/filter on? I’m sure I can, but I guess the question is, is this a bad idea and will ultimately be more work and unpredictable? In my head, it would look like this

Current with Redis

Key Value
SHA compressed JSON

Possible Scylla model

Partition Key Cluser key Value
SHA age compressed JSON

And just extend this table as and when you needed more specificity or adjust sorting etc??

This should work fine, but do note that you cannot alter primary key columns in scylladb. So if you later want to add a new clustering key component, you have to create a new table for that. This includes sorting, which is a property of the clustering key.

Hi @Botond_Denes

Thanks for the reply here, yeah I was aware, though thanks for that extra info/help :smiley:

Thanks again!