> I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript.
NoSQL caught on because of what it doesn't do: attempt to implement the relational model.
A lot of people were using MySQL in infamous LAMP stacks to set up websites with virtually no business logic.
So you had:
1. An application that didn't need the relational model
2. A DBMS that had a very poor implementation of SQL, which itself is a poor implementation of the relational model
3. A large community who didn't know anything about database theory.
When you're using MySQL as a glorified hashtable, you get none of the benefits of the relational model, and all the downsides.
From their understanding of the technology, throwing all that out made a lot of sense. It's pretty reasonable to use a distributed hashtable if what you want is a distributed hashtable.
I think the backlash now is that NoSQL marketed themselves as a capable alternative to SQL DBMSs. But they had no query optimizer, no transaction support, no reliable backups, and no schemas. The last was supposedly a selling point, but the reality is that your data always has a schema, and code will crash if the data doesn't match it.
Great marketing, but people were sold half a car and then told building the rest themselves was a feature.
> One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database.
Another problem is that object-orientation is fairly broken, and ORMs tried to figure out how to shoehorn relational databases into inheritance hierarchies. If current notions like value classes had been around, a more straightforward mapping would have been possible.
MongoDB certainly was missing a lot of things when they first launched and were very hyped, but now pretty much everything you could want in a database is now in MongoDB.
Do they have a scale/redundancy option for write scaling beyond shard + mirror set? I think my bigger issue with mongo, is you really need 6+ servers for a production deployment in many scenarios. It's great for getting a single developer instance up and running. But if I'm sticking to one instance or a couple mirrors for production, I may just reach for ms-sql or postgresql.
Aside: I'm sad that RethinkDB didn't get more of a foothold.
MongoDB supports a combination of shards and replica sets. Each replica set uses a protocol similar to raft for strong consistency. The replicas are a lot better than just active-secondary mirroring
Yeah, sorry for using mirrored instead of replica. I've worked with 3+ replica sets where I needed read scaling, and that worked well enough. But there are cases where I want read scaling and don't want to have a full copy of all data on all servers, but do want redundancy.
I really like, by comparison, how RethinkDB, Cassandra and others do it with clustering that has sharding + replication. It seems to be a better model in a lot of ways when you want to spread things out (read/write) but also want some replication of data. It's just a different way of working with things.
Thanks for posting that; I haven't had a good reason to look at it in quite a while. It makes sense that they're adding those features as they all exist in SQL DBMS's because they're a need.
I am currently working on a project for a client where they expect to have about 3,000 users each with some basic profile information, and the ability to upload some documents etc - nothing too crazy. I don't think they ever have to worry about scaling to 50,000 users and performing any data-intensive database queries. Why not use something like Mongo in this situation?
NoSQL caught on because our industry is like the fashion industry and we need to follow the fads year after year. Plus a lot of FUD about relational databases not scaling (it's true that NoSQL will scale certain problems way better than relational, but the vast majority of people were/are not writing applications at that scale).
NoSQL caught on because of what it doesn't do: attempt to implement the relational model.
A lot of people were using MySQL in infamous LAMP stacks to set up websites with virtually no business logic.
So you had:
1. An application that didn't need the relational model 2. A DBMS that had a very poor implementation of SQL, which itself is a poor implementation of the relational model 3. A large community who didn't know anything about database theory.
When you're using MySQL as a glorified hashtable, you get none of the benefits of the relational model, and all the downsides.
From their understanding of the technology, throwing all that out made a lot of sense. It's pretty reasonable to use a distributed hashtable if what you want is a distributed hashtable.
I think the backlash now is that NoSQL marketed themselves as a capable alternative to SQL DBMSs. But they had no query optimizer, no transaction support, no reliable backups, and no schemas. The last was supposedly a selling point, but the reality is that your data always has a schema, and code will crash if the data doesn't match it.
Great marketing, but people were sold half a car and then told building the rest themselves was a feature.
> One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database.
Another problem is that object-orientation is fairly broken, and ORMs tried to figure out how to shoehorn relational databases into inheritance hierarchies. If current notions like value classes had been around, a more straightforward mapping would have been possible.