Will REDIS give me fast In-Memory access to recent rows and fallback to a persistent store for long term entries?

Question

I'm looking into REDIS, and considering a scenario where I have a cluster with a master and one or multiple slaves.

Could I have a partially In-Memory database with REDIS? In-Memory for the most recent entries of a given table and stored in disk for the older entries?

Here's some requirements and what I'm expecting to deal with initialy

Characteristics

• Relational data base is not required
• Very few tables (only one is performance critical)
  • I guess this one won't matter in a key value db?
• Sub-second access to most recent entries
  1. Most recent entries are about 100k rows (In-Memory)
  2. The prevailing query filters by a column that matches multiple ids, with pagination and always sorted by most recent.
• Performance is not critical for older entries
• Performance is not critical for sorts other than the by most recent entries

Writes

• Very Few but Very Consistant where each write inserts 20+ lines every 60 seconds
• Zero concurrency

Reads

• Constant hammering on a single table for the most recent rows
• Paging can be greatly reduced if necessary by doubling the page size
• 20+ reads per second avg
• 200+ reads per second peak

Will REDIS fit the bill? And if not, what solutions might fit this scenario? Is partial In-Memory even a thing?

Thank you.

Answer 1

No, Redis is a pure in-memory data store. You could use Redis for caching, and complement it with a persistent store (and handle the logic of this mechanism in the application), but Redis alone will not fit the bill.

I would recommend you have a look at Couchbase or Aerospike to get the best latencies from primary key accesses, if this aspect is important to you.

Otherwise, considering the throughput, a good number of persistent SQL and NoSQL stores can probably take care of your workload. For instance, MongoDB, MySQL or its derivatives, can be configured to achieve your goals with an adapted database model.