4 ms·

I don't really understand why one would accept the trade-offs of "NoSQL" if you aren't interested in "magic scaling sauce" (and clustered redundancy). What's t

by nupark2 15y ago

I don't really understand why one would accept the trade-offs of "NoSQL" if you aren't interested in "magic scaling sauce" (and clustered redundancy). What's the advantage here? Less rigorous schema, moving data modeling and constraints into the more complex application code that's much more likely to have bugs? I can't tell you how many times database constraints have caught application bugs with fatal data correctness consequences on the products we've worked on. The only reason I can see for abandoning those declarative constraints is because of the scalability issues one must contend with (and even then, I'm somewhat unconvinced that they matter for all but the highest-load entities).

pjscott 15y ago
Some the the databases grouped under the over-broad NoSQL umbrella have reasons to use them other than magic scaling sauce. Redis, for example, is a ridiculously fast in-memory database that gives you data structures like sets, lists, hash tables, strings, numbers, and so on. It's tremendously useful for some problems. For example, at Greplin we're using Redis for our document analysis pipeline. We're pushing thousands of documents through Redis every second, using it to durably hold data while it gets passed around through our various back-end worker server clusters. We've been very happy with how Redis has been performing; it handles the write-heavy workload beautifully, and is way more resistant to data loss than most systems for doing this sort of thing. We'll be even happier when it gets server-side Lua scripting in a stable release, and we can define our own commands. The point is, though, that this would be crazy to do with a traditional SQL database, or even something like Riak or CouchDB or most of the other NoSQL databases. Redis fills a different niche, and filling a lot of cool niches is what I think the NoSQL stuff should be about.

by nupark2 15y ago

pjscott 15y ago

Some the the databases grouped under the over-broad NoSQL umbrella have reasons to use them other than magic scaling sauce. Redis, for example, is a ridiculously fast in-memory database that gives you data structures like sets, lists, hash tables, strings, numbers, and so on. It's tremendously useful for some problems. For example, at Greplin we're using Redis for our document analysis pipeline. We're pushing thousands of documents through Redis every second, using it to durably hold data while it gets passed around through our various back-end worker server clusters. We've been very happy with how Redis has been performing; it handles the write-heavy workload beautifully, and is way more resistant to data loss than most systems for doing this sort of thing. We'll be even happier when it gets server-side Lua scripting in a stable release, and we can define our own commands. The point is, though, that this would be crazy to do with a traditional SQL database, or even something like Riak or CouchDB or most of the other NoSQL databases. Redis fills a different niche, and filling a lot of cool niches is what I think the NoSQL stuff should be about.