4 ms·
I respectfully disagree: there's plenty of room for NoSQL, even if your users are next to none. For example, at times, it is just more convenient to store data
by madhouse 16y ago
I respectfully disagree: there's plenty of room for NoSQL, even if your users are next to none.
For example, at times, it is just more convenient to store data in a schema-less database (while still being able to query said data relatively easily). One such thing are my logs: I parse and tag them before storing them, and the relational model does not lend itself to that kind of storage.
Document stores, however, work beautifully. I can store entries like this:
{
program: { name: 'sshd', pid: 1234 },
date: { year: 2010, month: 1, day: 5, ... },
useracct: {
mehtod: 'pubkey',
source: '::1',
port: 45678,
service: 'ssh2',
username: 'user',
type: 'login'
},
message: 'Accepted publickey for user from ::1 port 45678 ssh2'
}
Obviously, some of my log messages won't have half of the properties from the example above, or have other kinds of fields. Storing that in SQL, while maintaining easy queryabilty would be a huge pain in the backside, to say the least.
With a document store, it's a piece of cake.
- yowsa 16y ago>the relational model does not lend itself to that kind of storage >Storing that in SQL, while maintaining easy queryabilty would be a huge pain in the backside, to say the least I don't think those words (SQL, Relational Model) mean what you think they do.
- geophile 16y agoBy "NoSQL" I'm referring distributed key/value stores. I know that's not quite right, there are other kinds. Also, I'm not saying that NoSQL doesn't have any purpose. It definitely does, and long before NoSQL was hot, there were standalone b-trees like BerkeleyDB, Faircom and many others. It may have been unfair for me to drag NoSQL into this, but the question sure sounded like it was suggesting that the sun was setting on SQL due to something, and NoSQL was a reasonable guess for what that something was.
- madhouse 16y agoYep, that was my interpretation of the question too. But I wouldn't have put down the document or key/value stores so harshly, since they do have their uses, even outside of high-scalability scenarios. As for BerkeleyDB and the rest: I'm not too familiar with them, but my impression before was that querying them wasn't as elegant as it is with some of the recent key/value or document stores. Probably that's the reason these new things receive such a hype: they do have something for them, even if the hype makes those bigger than they really are.