If you have a clue, as you say, and still believe that it's a good idea to store critical data with NoSQL then I don't know what to say.
Obviously you don't care enough that almost every NoSQL solution out there has been found to make false claims about their guarantees. The billions that have been sunk in the blackhole that's called NoSQL in the last decade is unprecedented.
You don't have to change my mind. I have(and still use) both. And I still maintain that people who use NoSQL for 99% of their projects are making the wrong choice.
It is a NoSQL database with a novel architecture. It uses schemas, supports transactions, historical queries, and it doesn't use a client server model.
My big concern with so-called NoSQL solutions is the "culture" that seems to be brewing there.
If you go to the "Don't use MongoDB" post ( http://news.ycombinator.com/item?id=3202081 ) you will read some, IMO, extremely worrying comments from a few pro-NoSQL users including antirez (Redis).
For some reason NoSQL now apparently means "unreliable datastore for unimportant, throwaway data" and defaults are chosen accordingly. Why the hell is that?
NoSQL for me doesn't imply anything other than "no SQL", and at a stretch "no schema" - this makes a lot of sense for many of us who routinely need to create databases that are logically trivial. In many cases they are a bunch of glorified persistent hash tables that usually don't fit in memory. But this doesn't mean they aren't critical. Why would it have to? This isn't anything new either, we've had Berkeley DB for a long while. It's just a bit of the dry side and it may fall short in many cases.
What I was looking forward to and I hoped I could find in the "NoSQL scene" is an alternative to traditional DBs but without the overhead that many times is not necessary (but sometimes is, and I intend to continue using PostgreSQL when appropriate). Ideally, something as simple as mongoDB appears to be (tried the interactive tutorial).
So when exactly NoSQL stopped meaning "no SQL" and started meaning "unreliable cache"? Other than the simplicity, I fail to see where it would fit in the market then (other than the amateur market). There are better, stablished DB caching solutions. There are persistence libraries in any moderately language. There are reliable databases that are fast enough when you have the budget to scale to several dedicated servers.
Does this release add any features that would keep you from going for a NoSQL solution? How does it for instance compare to MongoDB in terms of raw performance and scalability? (Not mentioning of course the difference in schema-less and relational design)
What is your exact question? To me it makes sense that you’d not want to use NoSQL if you’re dealing with data that’s already relational, and heavily leveraging features common in relational DBs that may not come out of the box with NoSQL DBs.
They’re saying basically that NoSQL DBs solve a lot of horizontal scaling problems but aren’t a good fit for their highly relational data, is my understanding. Not that they can’t get NoSQL functionality at eg the query level in relational DBs.
At this point I have yet to work on something that absolutely needs a NoSQL database so I may be a bit biased, but my general impression is they're a solution looking for a problem- or rather, the wrong solution to the wrong problem. I have used things like key-value stores such as memcached but it's also the kind of tools you don't use liberally unless you absolutely must. Perhaps a bit of obscurity isn't that bad of a thing after all.
Doesn't help that people have been talking about the issues with NoSQL for quite a few years now [0]
I was referring more to the marketing aspects of the term (and proposing their solution as a counterpart to "NoSQL"), than the concept itself. There are a lot of people who think that "NoSQL" is all about magic scaling sauce, and this isn't really helping.
I think people only use it because it stores JSON and let's you query it arbitrarily on demand. It appears to be as good as CouchDB, but with on-demand queries, as good as Postgres, but with JSON (!). It appears to be quick and easy and the tool for the job.
Also, when people say NoSQL they actually mean MongoDB.
What about other NoSQL solutions?
reply