3 ms·
As the web grew, so did the scale of websites. Many sites and apps found themselves in a situation where they would gladly trade strong consistency, for more p
by jaredklewis 10y ago
As the web grew, so did the scale of websites.
Many sites and apps found themselves in a situation where they would gladly trade strong consistency, for more performance and eventual consistency.
Further, schema changes for relational databases with billions of rows have to be very carefully orchestrated to avoid downtime. Databases with more flexible schemas allow schema changes more easily (though obviously the code most accommodate the fluid schemas).
Various NoSQL solutions were developed to fill these needs.
Sure, they were overused for a bit (though that fad has basically passed), but they definitely arose to fill a real need.
- JustSomeNobody 10y agoI think it's like everything else, developers see what the top companies are using and think, well, if it works for them it has to be the best (and you can search for "what's the best..." on any developer forum and see what I mean). So in that sense, it's hype driven. I don't believe this is the best way to decide on a technology.
- TimJYoung 10y agoSchema changes, and how they affect up-time, are an implementation detail in relational databases. It's possible to design a relational database engine that doesn't require huge amounts of downtime to alter the schema of large tables. It's all in how the data is stored. Of course, the reality of the situation is all that matters, and most database engines at that time did not offer such features. So, I don't necessarily fault people for trying to find solutions that simply worked for their needs.