4 ms·

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 dat

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.

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.