5 ms·

redis is not a database. It's a key-value based cache. If you're using it as a database, you're gonna have a bad time.

by arpa 5y ago

cube2222 5y ago
Why so? It has persistence and I'm not aware of any reported data loss happening with it. It's also got loads of complex and useful instructions.
- arpa 5y ago
  Data loss can occur between flushes to disk, for example (by default every 2 seconds / every I_FORGOT megabytes). Perhaps (most likely) it is possible to fine-tune the configuration to have redis as a very reliable data store, but it doesn't come with such settings by default, unlike most of RDBMSes.
  - miohtama 5y ago
    Not all use cases require reliable data storage and it is ok lose few seconds of data. Think simple discussion forums, internal chat applications. There are some scenarios where ease of use and a single server scalability pays off in the faster development and devops cost.
    - arpa 5y ago
      GP was asking why redis is not a reliable storage solution/database. Redis is great as an unreliable (not source-of-truth) storage.
      - kwdc 5y ago
        For that temporary use case, how does it compare to memcached?
        jasonwatkinspdx 5y ago
        Mostly boils down to Redis having a richer API, and memcached being faster / more efficient. The new EXT store stuff allows you to leverage fast ssd's to cache stupid huge datasets. Memcached is also one of the most battle tested things out there in open source. I've used them both plenty over the years, but tend to lean towards memcached now unless I really need some Redis API feature.
    - charrondev 5y ago
      I work on a SaaS community forums service and I can assure you data loss is not acceptable to our clients. As a result we use MySQL w/ memcached, although we are considering a swap to redis for the caching layer.
      - deleted 5y ago
        [deleted]
    - EvilEy3 5y ago
      > Not all use cases require reliable data storage and it is ok lose few seconds of data. Think simple discussion forums, internal chat applications. That is definitely not ok. I'd be really pissed as a user if I wrote a huge comment and it suddenly disappeared.
      - miohtama 5y ago
        It only disappears if there is a catastrophic failure. The likelihood for such thing to happen when you write a huge comment are less than jackpot in Las Vegas, a sensible risk tradeoff for better development experience and cost.
        TheCoelacanth 5y ago
        How is that a sensible tradeoff compared to just using something that was actually designed to be a database when you need a database?
        miohtama 5y ago
        You do not need a relational database for a simple chat/forum application.
        obstacle1 5y ago
        > a sensible risk tradeoff Note the tradeoff doesn't make sense as soon as you're operating at a meaningful scale. A small likelihood of failure at small scale translates to "I expect a failure a million years from now", whereas at large scale it's more like "a month from now". Accepting the same percent risk of data loss in the former case might be OK, but in the latter case is irresponsible. Provided whatever you're storing is not transient data.
        miohtama 5y ago
        You are correct. I wrote the original comment as "single server" so I assume it does not mean a meaningful scale and can be more effectively dealt with a support ticket. Not everything needs to be growth trajectory SaaS.
- jasonwatkinspdx 5y ago
  Redis is inherently lossy as a matter of basic design, and that's not even touching on the many other issues born of NIH solutions rampant within it. You may not hit the behavior until you push real loads through it. If you talk to anyone who has, I'm confident they'll agree with the criticism that while it may be an excellent cache, it should never be treated as a ground truth database. It's excellent as a slower memcachd with richer features. It's not a database. You can also read Aphyr's reports over the years, which to be utterly frank, bent over backwards to be charitable.

redis is not a database. It's a key-value based cache. If you're using it as a database, you're gonna have a bad time.

by arpa 5y ago

redis is not a database. It's a key-value based cache. If you're using it as a database, you're gonna have a bad time.

Why so? It has persistence and I'm not aware of any reported data loss happening with it. It's also got loads of complex and useful instructions.

arpa 5y ago
Data loss can occur between flushes to disk, for example (by default every 2 seconds / every I_FORGOT megabytes). Perhaps (most likely) it is possible to fine-tune the configuration to have redis as a very reliable data store, but it doesn't come with such settings by default, unlike most of RDBMSes.
- miohtama 5y ago
  Not all use cases require reliable data storage and it is ok lose few seconds of data. Think simple discussion forums, internal chat applications. There are some scenarios where ease of use and a single server scalability pays off in the faster development and devops cost.
  - arpa 5y ago
    GP was asking why redis is not a reliable storage solution/database. Redis is great as an unreliable (not source-of-truth) storage.
    - kwdc 5y ago
      For that temporary use case, how does it compare to memcached?
      - jasonwatkinspdx 5y ago
        Mostly boils down to Redis having a richer API, and memcached being faster / more efficient. The new EXT store stuff allows you to leverage fast ssd's to cache stupid huge datasets. Memcached is also one of the most battle tested things out there in open source. I've used them both plenty over the years, but tend to lean towards memcached now unless I really need some Redis API feature.
  - charrondev 5y ago
    I work on a SaaS community forums service and I can assure you data loss is not acceptable to our clients. As a result we use MySQL w/ memcached, although we are considering a swap to redis for the caching layer.
    - deleted 5y ago
      [deleted]
  - EvilEy3 5y ago
    > Not all use cases require reliable data storage and it is ok lose few seconds of data. Think simple discussion forums, internal chat applications. That is definitely not ok. I'd be really pissed as a user if I wrote a huge comment and it suddenly disappeared.
    - miohtama 5y ago
      It only disappears if there is a catastrophic failure. The likelihood for such thing to happen when you write a huge comment are less than jackpot in Las Vegas, a sensible risk tradeoff for better development experience and cost.
      - TheCoelacanth 5y ago
        How is that a sensible tradeoff compared to just using something that was actually designed to be a database when you need a database?
        miohtama 5y ago
        You do not need a relational database for a simple chat/forum application.
      - obstacle1 5y ago
        > a sensible risk tradeoff Note the tradeoff doesn't make sense as soon as you're operating at a meaningful scale. A small likelihood of failure at small scale translates to "I expect a failure a million years from now", whereas at large scale it's more like "a month from now". Accepting the same percent risk of data loss in the former case might be OK, but in the latter case is irresponsible. Provided whatever you're storing is not transient data.
        miohtama 5y ago
        You are correct. I wrote the original comment as "single server" so I assume it does not mean a meaningful scale and can be more effectively dealt with a support ticket. Not everything needs to be growth trajectory SaaS.
jasonwatkinspdx 5y ago
Redis is inherently lossy as a matter of basic design, and that's not even touching on the many other issues born of NIH solutions rampant within it. You may not hit the behavior until you push real loads through it. If you talk to anyone who has, I'm confident they'll agree with the criticism that while it may be an excellent cache, it should never be treated as a ground truth database. It's excellent as a slower memcachd with richer features. It's not a database. You can also read Aphyr's reports over the years, which to be utterly frank, bent over backwards to be charitable.