Create templates to quickly answer FAQs or store snippets for re-use.
I'll start with answers to your three questions.
Does it still have keys?
Yes. There are in MongoDB keys. Keys concept doesn't changed between MongoDB and classical RDBMS.
Does it use SQL?
Does it use SQL?
Nope. There is specific comparative query language which allow you to perform CRUD operations and data aggregation. Here is a nice page from MongoDB documentation which compares MongoDB statements to SQL statements.
Are there web viewers (similar to phpMyAdmin)?
Yes. There are several tools. Some are commercial some not.
- MongoDB Compass
So let's back to explanation about MongoDB.
MongoDB as a document database. In case of MongoDB we're storing documents which are in JSON notatnion.
(This is a little lie, because they are physically stored as BSON (Binary JSON) sorry for that :))
MongoDB stores documents in containers named collections. MongoDB allows documents in collections to have different shape. Of course you can have nested documents in collection. You can't join documents across collections. MongoDB doesn't support transactions as well.
By the way maybe you're familiar with LAMP acronym (Linux Apache MySQL PHP). Nowadays there is a new acronym MEAN (MongoDB, Express, Angular, NodeJs).
This is only an introduction to an introduction of MongoDB. If you're interested in MongoDB there is MongoDB University page. It provides free online courses which can help you to discover and udnerstand MongoDB. I encourage you to try it.
I hope my explanation will be helpful for you. If you had more questions just ask me.
How often is MongoDB used nowadays with the rise in popularity of PostgreSQL? Is the MEAN stack obsolete with the rise in popularity of other technologies like AWS, Azure, and Heroku, and frontends like React and Vue?
How often is MongoDB used nowadays with the rise in popularity of PostgreSQL?
In my opinion we shouldn't compare NoSQLs like MongoDB with relational database systems. MongoDB isn't silver bullet for problems with database performance. In my opinion MongoDB is high performance in terms on reads and writes (and it also depends on data model) but it doesn't apply to scenarios which contain data aggregation and/or transactions.
Great example of MongoDB usage is as a persistent store in RabbitMQ. It fits all requirements for storing messages. But MongoDB is unsuitable for any king of transactional systems.
I personally faced the problem that customers don't trust MongoDB and they want to keep traditional databases like PostgreSQL. That in my opinion stops expansion of MongoDB. Please keep in mind that I'm not saying that we should throw away relational databases and replace it with NoSQLs.
Here is a list of MongoDB customers from official site. It's possible that you're using MongoDB without awareness (like in example with RabbitMQ).
Is the MEAN stack obsolete with the rise in popularity of other technologies like AWS, Azure, and Heroku, and frontends like React and Vue?
Maybe the peak of popularity of MEAN is behind us. MEAN as a concept was introduced in 2013. I agree that especially frontend technologies are changing rapidly (2-3 years for a frontend framework is an age). So nowadays React and/or Vue became popular too. That gives us ME R N or ME V N but it doesn't sound so nice like MEAN :)
AWS, Azure, Heroku are only platforms. For example you can ithout problem you can host your MEAN solution on Azure. You can create and host Node.js app use an Express as a backend framework, an Angular as a frontend framework and communicate with MongoDB or CosmosDB with exposed MongoDB API without any problems.
Please remember that are only my opinions. You can disagree with all my opinions, especially about frameworks lifecycle or MongoDB future. I'm not a technology oracle :)
Oh no, that's what I was wanting to get. I just wanted to hear from your experience if certain parts of that stack feel like they are showing their age a little bit or if you think they can still be considered modern.
Assuming you're a 5 year old that understands JSON, files, folders and RDBMS:
Conceptualise the basics as storing JSON files in a folder. A single JSON file can contain anything you want. That is one "document" in Mongo-speak, or one "row" in RDBMS-speak. The main difference you see right away is that an RDBMS row is typically only a flat key-value association (though some databases support types like arrays and JSON for columns), while a JSON document is an arbitrarily complex object.
Such JSON documents are lumped into one "collection"; think of a folder. The collection can be entirely heterogeneous, there need not be any fixed schema a document must adhere to. The analogue in RDBMS is a table, though again the lack of schema makes this comparison unsuitable and a folder is the better metaphor. Such collections are part of one database, and a single Mongo server can contain many databases.
The advantage Mongo brings over a simple folder full of JSON files is that it adds database capabilities to it. That includes a query language, an indexing system, richer types than plain JSON offers, replication across machines etc. The query language is necessarily very different from SQL, since the structure of the data you're querying is very different. As you might imagine it's also harder to cross-reference (join) data across heterogenous collections of JSON documents as compared to fixed-schema relational data, so a lot of SQL JOIN queries you might be used to need a different approach. Due to the "eventually consistent" replication model, transactional operations are also… different, largely non-existent.
Overall, you need to rethink a lot of concepts you might have learned vis-à-vis database normalisation. In RDBMSs you typically spread a logical record (e.g. a user record) across several tables with one-to-many or many-to-many relationships, which necessitates transactional updates to keep the data consistent. In Mongo you'd rather store all that in a single complex document in a single collection. When working with such data, you need to keep in mind that data across different collections may not be consistent at any one point in time, so there's not typically a lot of cross-referencing going on in a Mongo database. Mongo data storage is best suited for many small individual data blobs, not so much for highly correlated data with a strong need for internal consistency.
Basically instead of flattening everything out to tables or saving objects as strings, you can store objects like how they appear natively in a js app
I don't have the time to write a "likeimfive" answer, but just take a free online course from their "university", you will understand better and faster by just using it.
Basically noSQL are used to Scale big data sets, natively can be distributed across many many servers. SQL and noSQL are used together in the same app, storing different things that serve different purposes.
To fast start your MongoDB env just copy my docker gist, you will have a running instance and a (phpmyadmin) like admin. If you do not have docker you should get it, it will help you a lot on the long run.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.