4 ms·
> 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:
by ben509 8y ago
> 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.
- d4l3k 8y agoMongoDB 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. Multi-document transactions + strong consistency: https://docs.mongodb.com/manual/core/write-operations-atomicity/ https://docs.mongodb.com/manual/core/write-operations-atomic... Passes Jepsen test: https://www.mongodb.com/mongodb-3.4-passes-jepsen-test https://www.mongodb.com/mongodb-3.4-passes-jepsen-test Schema: https://docs.mongodb.com/manual/core/schema-validation/ https://docs.mongodb.com/manual/core/schema-validation/ Query Optimizer: https://docs.mongodb.com/manual/core/query-plans/ https://docs.mongodb.com/manual/core/query-plans/ Backups: https://docs.mongodb.com/manual/core/backups/ https://docs.mongodb.com/manual/core/backups/
- ben509 8y agoThanks 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.
- tracker1 8y agoDo 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.
- d4l3k 8y agoMongoDB 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 https://docs.mongodb.com/manual/replication/ https://docs.mongodb.com/manual/replication/ There's also Atlas which is the hosted version and makes it very easy to scale up https://www.mongodb.com/cloud/atlas https://www.mongodb.com/cloud/atlas They also just added a free tier if you want to play with that https://docs.mongodb.com/manual/tutorial/atlas-free-tier-setup/ https://docs.mongodb.com/manual/tutorial/atlas-free-tier-set...
- tracker1 8y agoYeah, 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 pointing out Atlas.
- rbyrne 8y agoThis is exactly how I feel. 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?
- collyw 8y agoBecause your data is probably relational and data being consistent is probably beneficial?
- collyw 8y agoNoSQL 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).