Most of the time,we just get the result from database,and then save it in cache server,with an expiration time.
When do we need to persistent that key/value pair,what's the significant benifit to do so?
views:
46answers:
2
+1
A:
If you need to persist the data, then you would want a key/value database. In particular, as part of the NoSQL movement, many people have suggested replacing traditional SQL databases with Key/Value pair databases - but ultimately, the choice remains with you which paradigm is a better fit for your application.
Justin Ethier
2010-04-09 16:17:52
How can key/value databases replace SQL databases with such limited functionality?
Gtker
2010-04-09 16:19:46
They aren't drop-in replacements, they're less functional by design so that you get the tradeoff of speed. If you want to track relationships and constraints and all that, you then basically have to implement that logic yourself. At which point you should strongly consider just using an RDBMS :)
Daniel DiPaolo
2010-04-09 16:25:21
Can you give a single case when NoSQL significantly beats the classical combination of SQL+cache server ?
Gtker
2010-04-09 16:29:01
That's a great question that anyone who thinks they need to scale should be asking themselves. Apparently key/value databases do scale better, but then you would have to implement "queries" in your application layer. Anyway, I agree that for most applications a SQL database will be fine as long as you are willing to learn how to use one properly, and to tune your queries, indexes, etc as-needed.
Justin Ethier
2010-04-09 16:31:48
@Runner - You may find what you are looking for here: http://stackoverflow.com/questions/2476280/example-of-moving-from-mysql-to-nosql
Justin Ethier
2010-04-09 16:33:01
@Justin Ethier ,the link is talking about **how** to do NoSQL,but that I won't do if I don't know **why** to do it
Gtker
2010-04-09 16:35:50
A:
Use a key/value database when you are using a key/value cache and you don't need a sql database.
When you use memcached/mysql or similar, you need to write two sets of data access code - one for getting objects from the cache, and another from the database. If the cache is your database, you only need the one method, and it is usually simpler code.
You do lose some functionality by not using SQL, but in a lot of cases you don't need it. Only the worst applications actually leave constraint checking to the database. Ad-hoc queries become impractical at scale. The occasional lost or inconsistent record simply doesn't matter if you are working with tweets rather than financial data. How do you justify the added complexity of using a SQL database?
Tom Clarkson
2010-04-18 00:51:16