3 ms·

Redis has been called a "data structure server". Isn't that what a database is? Is there anything fundamentally better about Redis than say, a single connecti

Redis has been called a "data structure server". Isn't that what a database is? Is there anything fundamentally better about Redis than say, a single connection to Postgres? Except with Postgres you would be allowed many concurrent connections and greater throughput, while having the same external behavior thanks to transaction serializability. It's as if the operations got applied by a single thread in a defined order, but in reality can be parallelized. Redis cannot do that intelligently. I use Redis occasionally because it's a very simple system and it's easy, and has been micro-optimized very well. I don't think it necessarily contains any good computer science ideas. Am I wrong here? Tidis is more evidence that Redis's single threaded design leaves a ton on the table.

meowface 9y ago
Many in-memory databases don't have native data types for sets, sorted sets, hash tables, bitmaps, HyperLogLogs. Postgres and Redis have different use cases.
- etaioinshrdlu 9y ago
  A unique index in Postgres is an efficient set data structure. A sorted set is a index in Postgres, stored as a B-Tree. Postgres has hash indexes, basically the same as a hash table. And you can run Postgres in memory if you want via tmpfs. Bitmaps and hyperloglogs are basically math functions running in the database, and Postgres supports user-defined math functions. It seems disingenuous to point out individual math functions when both databases support arbitrary user defined math functions.
  - matthewmacleod 9y ago
    You are conflating structures used internally to implement a relational database, and structures exposed as a first-class building block for your own systems. Think of Redis a a shared, in-memory, well-tested implementation of basic data structure primitives that takes care of a lot of the fiddly nonsense around them without you having to do the work. Postgres is awesome, but it's targeted at a different use case and has different characteristics; it's overkill for something like a shared key-value store, for example.
ComputerGuru 9y ago
Our use case for redis is strictly in-memory cache only, basically what it was originally designed for. It’s used solely with the caveat that it cannot be trusted as a source of truth, that its data may disappear at any time, that the data is local to the node it is running under, etc. For us, redis takes the place of IPC and “persistence” by not sharing lifetimes with its consumers, ie while redis May go down and our microservices restart all the time, the two have separate lifetimes and redis being around between the two bridges the temporal gap. Using redis to store structured data is ineffective once you need something even remotely structured, requiring too many commands to perform what should be an atomic operation.
nemothekid 9y ago
Redis excels at sub-millisecond operations - thats what you get when you use an in-memory data store. If you are conflating Postgres and Redis then it's doubt you really actually needed either. Strong persistence or consistency isn't something that is very popular in Redis (or at least I haven't seen it done). In most cases you are right - if you are willing to trade latency for persistence or consistency there are other tools available. I wouldn't read that much into tidis - it seems like a hobby project for now. Another interesting redis project is pedis (https://github.com/fastio/pedis https://github.com/fastio/pedis). It takes advantage of multiple cores by, at a high level, sharding the keyspace per core.
manigandham 9y ago
You're specifically talking about a relational database which are the most flexible data systems available with decades of development. You can model pretty much every other datastore on top of a relational database, including Redis. But Redis is designed for a different use-case It's far simpler to install and operate, and much faster to run by being completely in-memory. It has optional persistence when you need it, easy replication, and a simple single-threaded architecture with primitive access to data structures. So yes, you won't get the flexibility of a relational database, but you get performance and simplicity and there are a great many uses for that. If you can't think of a reason to use it, then that's a good sign that you just don't have a need for it.

meowface 9y ago

Many in-memory databases don't have native data types for sets, sorted sets, hash tables, bitmaps, HyperLogLogs. Postgres and Redis have different use cases.

etaioinshrdlu 9y ago
A unique index in Postgres is an efficient set data structure. A sorted set is a index in Postgres, stored as a B-Tree. Postgres has hash indexes, basically the same as a hash table. And you can run Postgres in memory if you want via tmpfs. Bitmaps and hyperloglogs are basically math functions running in the database, and Postgres supports user-defined math functions. It seems disingenuous to point out individual math functions when both databases support arbitrary user defined math functions.
- matthewmacleod 9y ago
  You are conflating structures used internally to implement a relational database, and structures exposed as a first-class building block for your own systems. Think of Redis a a shared, in-memory, well-tested implementation of basic data structure primitives that takes care of a lot of the fiddly nonsense around them without you having to do the work. Postgres is awesome, but it's targeted at a different use case and has different characteristics; it's overkill for something like a shared key-value store, for example.

ComputerGuru 9y ago

Our use case for redis is strictly in-memory cache only, basically what it was originally designed for. It’s used solely with the caveat that it cannot be trusted as a source of truth, that its data may disappear at any time, that the data is local to the node it is running under, etc. For us, redis takes the place of IPC and “persistence” by not sharing lifetimes with its consumers, ie while redis May go down and our microservices restart all the time, the two have separate lifetimes and redis being around between the two bridges the temporal gap. Using redis to store structured data is ineffective once you need something even remotely structured, requiring too many commands to perform what should be an atomic operation.

nemothekid 9y ago

Redis excels at sub-millisecond operations - thats what you get when you use an in-memory data store. If you are conflating Postgres and Redis then it's doubt you really actually needed either. Strong persistence or consistency isn't something that is very popular in Redis (or at least I haven't seen it done). In most cases you are right - if you are willing to trade latency for persistence or consistency there are other tools available. I wouldn't read that much into tidis - it seems like a hobby project for now. Another interesting redis project is pedis (https://github.com/fastio/pedis https://github.com/fastio/pedis). It takes advantage of multiple cores by, at a high level, sharding the keyspace per core.

manigandham 9y ago

You're specifically talking about a relational database which are the most flexible data systems available with decades of development. You can model pretty much every other datastore on top of a relational database, including Redis. But Redis is designed for a different use-case It's far simpler to install and operate, and much faster to run by being completely in-memory. It has optional persistence when you need it, easy replication, and a simple single-threaded architecture with primitive access to data structures. So yes, you won't get the flexibility of a relational database, but you get performance and simplicity and there are a great many uses for that. If you can't think of a reason to use it, then that's a good sign that you just don't have a need for it.