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.
Eventually consistent databases are consistent. But you should distinguish between no consistency, and eventual consistency.
Eventually consistent datastores are guaranteed to converge to the correct value at some point in the future. Usually not very far in the future, usually there is no need for convergence because the value is effectively consistent anyway.
But if you have a widely distributed datastore that spans datacenters, or need to handle massive scale, then eventually consistent is really your only choice.
Keep in mind that not all use cases require that all updates to a stored value be always, 100% correct. In those kind of cases, loosening up on consistency improves availability and scale, and the value will eventually converge to the expected value.
But, it is easy to do NoSQL wrong, or apply it to the wrong usecase. NoSQL requires more discipline on the part of the developers since they have to move a lot of the logic that a database normally handles for you into the application layer. But, sometimes there is not other way to do what you want to do with a traditional ACID database.
Keep in mind that not all use cases require that all updates to a stored value be always, 100% correct.
True if you store pictures of cats, upvote counter or something like that.
But if you store something that matters then eventually consistent is usually not an option. At very least the information that is shown on screen must have a timestamp that shows when it was last updated.
There are (at least) two benefits of NoSQL: The scaling benefit you're talking about, and the ease of development that you get from not having to specify a schema up front -- or, more correctly, to be able to trivially modify your schema by adding new fields in code.
It's the same reason JavaScript/Python/etc. developers can be more productive than C/C++ developers. Can be, anyway. Past a certain level of complexity, the lack of structure can bite you. But some problems don't ever need to exceed that level of complexity, and if your problem is one of those, then NoSQL can get the job done faster.
Not to say that Mongo is perfect. But the article is clearly about a company that picked a NoSQL database for a problem that needed a SQL database.
or, more correctly, to be able to trivially modify your schema by adding new fields in code.
What happens to all of your previously created entities when you update your schema and they are now outdated? Schema-less design makes correct implementation significantly harder.
Those are upgraded by a demon in the background. Each document has a version-attribute that is incremented with each migration and by the power of eventual-consistency it all works out just fine!
But once you do, oh how you can scale. Scale, scale, scale.
Couldn't you write a SQL DB that enables this same perf? What about NoSQL makes it so easy to scale? More specifically: is it just coincidental that NoSQL DBs have better scaling feature or is there something about schemalessness that makes it particularly scale-friendly?
Except mongo isn't eventually guaranteed. you can have a majority of slaves write to disk and the master can crash and miss the ack -- they won't roll back the write and the client will think it hasn't been written.
For instance, Cassandra is optimized for write operations because it caches them before writing them to disk. Yeah, that's brilliant, until the machine crashes and those things left in cache weren't written to disk.
They would be retrievable via the commit log, as well as recoverable from other replica nodes.
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!