3 ms·

There's Something About Redis

4 points by r11t 17y ago

tptacek 17y ago
Respectfully, it's posts like this that are keeping me from investigating the new k-v stores for our (large) Rails app. I don't want "awesome", I don't want a "lifestyle", and I'm certainly not motivated by the idea of replacing something that is fast enough, but not as fast as it could be. You've got every right not to care what I think of Redis (or Couch or whatever), but if you do and you're wondering how to address people like me --- ie, people who would rather add one more tiny feature to a product that sells than talk about NoSQL --- can you tell me how Redis fits in alongside a MySQL/AR setup? If I'm already committed to AR, where does Redis (or Couch or whatever) make my existing app better?
- kvstorefool 17y ago
  It's all about the use case. Duh! "Using the right tool for the job!" --someone smart No one claims that key-value stores will entirely replace relational databases. But there are use cases for it where it doesn't make sense to use a relational store, cause no relations are required. E.g., I've personally created a property table in MySQL before. But a key-value store would have been way more suitable for it. And not just more suitable, but also faster. But don't worry, *SQL excels on other fronts. Also, Redis is not CouchDB, not even close. CouchDB is not a key-value store but a documented oriented database. Suitable in case it's hard to normalize your data (or you're fucking tired of doing it again and again). It's also extemely fast on read and easy to integrate (HTTP). I suggest further reading. Less complaining. Maybe attend one of those conferences. Don't waste your time on Hacker News. =)
  - tptacek 17y ago
    So your take is, I should run two whole seperate databases so I can store my property tables in a k-v store instead of in a trivial table?
    - kvstorefool 17y ago
      If it's more efficient? Hell yeah. Also, say you end up with memcached, or redis, why not cache session data in it so you don't need to query the database or the fs, etc.. Usually there are a lot of things to put into a cache. And memory is always faster than disk. But that's all assuming you really need it. I wouldn't throw anything new at an app when it's not necessary. You need to know that yourself.
    - janl 17y ago
      The take is, just because you already have a database, it might not be the best place to but all your data.
      - tptacek 17y ago
        In what way are my users going to notice that I stored a prop table in Redis instead of MySQL? Because I don't think they're going to notice ever, but I could be wrong.
        kvstorefool 17y ago
        Ouch. They'll notice when your application is faster and more robust. You don't use a key-value store to impress your users. Robustness can also lead to easier development, more features, better service, whatever.

4 points by r11t 17y ago

Respectfully, it's posts like this that are keeping me from investigating the new k-v stores for our (large) Rails app. I don't want "awesome", I don't want a "lifestyle", and I'm certainly not motivated by the idea of replacing something that is fast enough, but not as fast as it could be. You've got every right not to care what I think of Redis (or Couch or whatever), but if you do and you're wondering how to address people like me --- ie, people who would rather add one more tiny feature to a product that sells than talk about NoSQL --- can you tell me how Redis fits in alongside a MySQL/AR setup? If I'm already committed to AR, where does Redis (or Couch or whatever) make my existing app better?

kvstorefool 17y ago
It's all about the use case. Duh! "Using the right tool for the job!" --someone smart No one claims that key-value stores will entirely replace relational databases. But there are use cases for it where it doesn't make sense to use a relational store, cause no relations are required. E.g., I've personally created a property table in MySQL before. But a key-value store would have been way more suitable for it. And not just more suitable, but also faster. But don't worry, *SQL excels on other fronts. Also, Redis is not CouchDB, not even close. CouchDB is not a key-value store but a documented oriented database. Suitable in case it's hard to normalize your data (or you're fucking tired of doing it again and again). It's also extemely fast on read and easy to integrate (HTTP). I suggest further reading. Less complaining. Maybe attend one of those conferences. Don't waste your time on Hacker News. =)
- tptacek 17y ago
  So your take is, I should run two whole seperate databases so I can store my property tables in a k-v store instead of in a trivial table?
  - kvstorefool 17y ago
    If it's more efficient? Hell yeah. Also, say you end up with memcached, or redis, why not cache session data in it so you don't need to query the database or the fs, etc.. Usually there are a lot of things to put into a cache. And memory is always faster than disk. But that's all assuming you really need it. I wouldn't throw anything new at an app when it's not necessary. You need to know that yourself.
  - janl 17y ago
    The take is, just because you already have a database, it might not be the best place to but all your data.
    - tptacek 17y ago
      In what way are my users going to notice that I stored a prop table in Redis instead of MySQL? Because I don't think they're going to notice ever, but I could be wrong.
      - kvstorefool 17y ago
        Ouch. They'll notice when your application is faster and more robust. You don't use a key-value store to impress your users. Robustness can also lead to easier development, more features, better service, whatever.