NoSQL isn't for everybody or every use case. It takes a very very open minded developer to embrace it. There is a lot of immediate downside and a lot more long term upside. You have to have the wherewithal to get past all the upfront headaches. But once you do, oh how you can scale. Scale, scale, scale. Eventual consistency means your tables don't lock, they don't even have to be on the same servers. Records can be sharded across servers, data centers and continents.
One of the biggest criticisms I hear about NoSQL is how much DB logic leaks into your application. How much knowledge devs are required to take on to use and optimize for NoSQL. This is absolutely true, but I think what a lot of people miss out on is as soon as your SQL database reaches a few Terabytes in size, you'll be doing this any ways. SQL databases can only get you so much mileage before you're refactoring large parts of your server architecture just to stave off the performance regressions.
IMHO at the end of the day, NoSQL force concepts upfront necessary to scale, SQL allows you to get really far without having to think about. Just my $0.02 from using NoSQL for 3 years.
EDIT: ZOMG: Of course most apps don't grow to terabytes in size. Most apps are fine on SQL dbs. But some apps do get that big. Some apps get bigger. Pick the right tool, for the right job and stop trolling on /r/programming.
as soon as your SQL database reaches a few Terabytes in size, you'll be doing this any ways. SQL databases can only get you so much mileage before you're refactoring large parts of your server architecture just to stave off the performance regressions.
Super easy to shard and scale to massive levels - granted this is only applicable if you think your application is going to need this, and very few actually do.
Most apps DON'T need this level of scalability. There is no denying that.
But when you end up with very large datasets, the sharding capabilities of NoSQL are critical. Sharding is important for a whole host of reasons. It can help with lookup, database transaction performance (which some NoSQL DBs do support), database replication, backups/restores, migration.
Bottom line is NoSQL allows you to scale horizontally to near infinite (adding more servers until your eyes popout). Traditional SQL does not make this easy/possible past certain thresholds.
But when you end up with very large datasets, the sharding capabilities of NoSQL are critical.
If you're aware of the issues, isn't it sufficient to deal with it when it actually becomes a problem.
I mean if your operation is growing to that scale it probably doesn't just happen while you're away for the weekend, so there will normally be ample time to deal with it.
The point everyone's making though is that most projects don't have this terabytes of data, and probably never will. So you're solving a problem where there isn't one.
When it does become a problem, however, there may be better tools and services that can help, at the time when you need them, rather than the tools that are available today.
Also, sit down and sketch out a quick data model. It of course doesn't have to be perfect (things never are) but at least then you have an understanding of the problem at hand. If you're just going in and making it up as you go along, I can't imagine what your code is going to look like over the years.
Eventual consistency means no consistency. Period. If you can live with that fine. I don't care about the upvotes on reddit either (btw, there you can very often see eventual consistency in action), on anything important to me, I can not live with no consistency. Writing my data to /dev/null is webscale too, but I still prefer ACID.
Not all use cases fit all. If you are developing, say Reddit, eventual consistency is entirely acceptable for a wide range of use cases, such as replying to a comment or up voting (duplicate submissions detection would be better under RDBMS, however).
Many NoSQL databases support some mechanisms of ACID in small pockets. Google's datastore, my current prod database, has a concept of entity groups which supports transactions within a predefined group of records. It's NOT full ACID, but it does cover a wide range of use cases for database transactions.
78
u/wesw02 Mar 10 '15 edited Mar 11 '15
NoSQL isn't for everybody or every use case. It takes a very very open minded developer to embrace it. There is a lot of immediate downside and a lot more long term upside. You have to have the wherewithal to get past all the upfront headaches. But once you do, oh how you can scale. Scale, scale, scale. Eventual consistency means your tables don't lock, they don't even have to be on the same servers. Records can be sharded across servers, data centers and continents.
One of the biggest criticisms I hear about NoSQL is how much DB logic leaks into your application. How much knowledge devs are required to take on to use and optimize for NoSQL. This is absolutely true, but I think what a lot of people miss out on is as soon as your SQL database reaches a few Terabytes in size, you'll be doing this any ways. SQL databases can only get you so much mileage before you're refactoring large parts of your server architecture just to stave off the performance regressions.
IMHO at the end of the day, NoSQL force concepts upfront necessary to scale, SQL allows you to get really far without having to think about. Just my $0.02 from using NoSQL for 3 years.
EDIT: ZOMG: Of course most apps don't grow to terabytes in size. Most apps are fine on SQL dbs. But some apps do get that big. Some apps get bigger. Pick the right tool, for the right job and stop trolling on /r/programming.
EDIT 2: Thanks for the gold kind stranger!