4 ms·

I think that the data model of some new database is more suitable for different use cases compared to relational DBs. Also it's not just a matter of scalabilit

by antirez 16y ago

I think that the data model of some new database is more suitable for different use cases compared to relational DBs. Also it's not just a matter of scalability: latency is a very important constraint. Finally I see a lot of small sites, forums, blogs, that can't scale easily to small numbers using relational DBs, since with the relational model and current implementation you have the illusion that can design a few table and then invent your queries, and instead this does not work and is dramatically slow. No need to have very large numbers to see how hard traditional DBs sucked. And the proof is the huge adoption of NoSQL in small companies: it's not just hype, people want to go home and sleep well and will not trow away working SQL solutions because there is the new hype. The reality is that they are experiencing serious problems even at the scale a small and mid-size company operates.

tkahn6 16y ago
I'm using Redis as a backend to store course availability information at my university. If the set contains the course ID it has an open seat. Data is scraped and processed continuously and there are ~7200 courses so Redis is a good fit.
- desigooner 16y ago
  Is there a matrix of features or use case scenarios for the various NoSQL options out there? e.g. i have a lot of person data with various attributes like applications, schedules, choices, demographics, courses, etc. (university). At certain times of the year, a lot of transactions would occur and at other times, it'll be getting very low traffic/transaction requests. MySQL tends to be a PITA if we try to modify certain things to add or remove tracking and so on while live hours and as things are run, unfortunately a lot of changes come in unplanned. How should I go about finding the best fit for this scenario?
coffeemug 16y ago
Finally I see a lot of small sites, forums, blogs, that can't scale easily to small numbers using relational DBs. When MySQL was in growth stage, about 50% of the downloads accounted for users who were downloading a database for the first time in their lives! (got that piece of info from early MySQL folks). If a small site, forum, or blog can't scale easily on a relational database it is because the developer doesn't know what they're doing. You can make an argument that relational solutions aren't user friendly because they have defaults not suited for small, high-performance sites, or too many features that cripple performance if not used correctly, but IMO that's a silly argument. People don't blame a programming language because their program is slow since they used a O(2^N) algorithm where O(N log N) suffices. Why do people blame a DBMS when they write nonsensical queries that couldn't possibly evaluate in real-time merely for giving them an option to write such queries? Also it's not just a matter of scalability: latency is a very important constraint. Many relational databases have sophisticated schedulers that reorder events to maximize queries per second, unless an event has been in the pipe for too long, in which case it is given higher priority and pushed through faster. Most NoSQL products do not even begin to approach this level of sophistication. Even MySQL gives excellent latency characteristics if you know what you're doing - just ask the Facebook folks, they're very serious about latency. Good latency performance is certainly not restricted to NoSQL stores. Most SQL vs. NoSQL debates usually have the same resolution: traditional DBMSes let you shoot yourself in the foot, while NoSQL solutions usually don't. With a traditional DBMS you better know what you're doing, while with a NoSQL solution you can usually get away with just jumping into it. Nine times out of ten, that's the value proposition. Most of the time it isn't performance, latency, a better/different data model, or anything of the sort.
sokoloff 16y ago
I'd wager that people you see with "small sites, forums and blogs that can't scale easily to small numbers using relational DBs" are doing something wrong and they're probably going to have a long road in the NoSQL world as well. Just because you can make a query return the result set you want doesn't mean you've written the right query/schema design. I assure you that there are plenty of performant sites running quite well on traditional SQL solutions that are FAR, FAR larger than those small blogs serving small traffic numbers that are having issues.

by antirez 16y ago

tkahn6 16y ago

I'm using Redis as a backend to store course availability information at my university. If the set contains the course ID it has an open seat. Data is scraped and processed continuously and there are ~7200 courses so Redis is a good fit.

desigooner 16y ago
Is there a matrix of features or use case scenarios for the various NoSQL options out there? e.g. i have a lot of person data with various attributes like applications, schedules, choices, demographics, courses, etc. (university). At certain times of the year, a lot of transactions would occur and at other times, it'll be getting very low traffic/transaction requests. MySQL tends to be a PITA if we try to modify certain things to add or remove tracking and so on while live hours and as things are run, unfortunately a lot of changes come in unplanned. How should I go about finding the best fit for this scenario?

coffeemug 16y ago

Finally I see a lot of small sites, forums, blogs, that can't scale easily to small numbers using relational DBs. When MySQL was in growth stage, about 50% of the downloads accounted for users who were downloading a database for the first time in their lives! (got that piece of info from early MySQL folks). If a small site, forum, or blog can't scale easily on a relational database it is because the developer doesn't know what they're doing. You can make an argument that relational solutions aren't user friendly because they have defaults not suited for small, high-performance sites, or too many features that cripple performance if not used correctly, but IMO that's a silly argument. People don't blame a programming language because their program is slow since they used a O(2^N) algorithm where O(N log N) suffices. Why do people blame a DBMS when they write nonsensical queries that couldn't possibly evaluate in real-time merely for giving them an option to write such queries? Also it's not just a matter of scalability: latency is a very important constraint. Many relational databases have sophisticated schedulers that reorder events to maximize queries per second, unless an event has been in the pipe for too long, in which case it is given higher priority and pushed through faster. Most NoSQL products do not even begin to approach this level of sophistication. Even MySQL gives excellent latency characteristics if you know what you're doing - just ask the Facebook folks, they're very serious about latency. Good latency performance is certainly not restricted to NoSQL stores. Most SQL vs. NoSQL debates usually have the same resolution: traditional DBMSes let you shoot yourself in the foot, while NoSQL solutions usually don't. With a traditional DBMS you better know what you're doing, while with a NoSQL solution you can usually get away with just jumping into it. Nine times out of ten, that's the value proposition. Most of the time it isn't performance, latency, a better/different data model, or anything of the sort.

sokoloff 16y ago

I'd wager that people you see with "small sites, forums and blogs that can't scale easily to small numbers using relational DBs" are doing something wrong and they're probably going to have a long road in the NoSQL world as well. Just because you can make a query return the result set you want doesn't mean you've written the right query/schema design. I assure you that there are plenty of performant sites running quite well on traditional SQL solutions that are FAR, FAR larger than those small blogs serving small traffic numbers that are having issues.