Hi
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??
