MongoDB tutorial for startups. Most of you are aware of SQL, but MongoDB is not SQL, it is NoSQL. More about it here.
Starting up? Here is a blog you would love to follow. Here, I share everything I learnt while building my startup that you could also learn and lead yourself to building a successful startup. Here I am learning MongoDB, a NoSQL database for my application.
Problems With SQL That Led to the Introduction of NoSQL
SQL databases did not scale to millions and millions of entities.
SQL database forced you to have a predefined structure. So, eventually if your application logic required a different data organization, SQL did not make it easy to change.
Startups need to be flexible with their data organization as their application logic keeps changing often. SQL did not give the flexibility startups needed and that is why NoSQL found its popularity.
There are mainly two types of data stores
- Document Oriented
Tabular Data Stores
Tabular data stores are databases where data is kept in tables. And different tables are interconnected using Primary Keys and Foreign Keys. A Primary Key is copied and placed in another table and is called Foreign Key. This helps you to connect the rows of the two table. Say, in Table 2 you have a Foreign Key column with a row having the value 512. You can look up in Table 1’s Primary Key Column for the value 512 and you find the related row.
The problem with tabular databases are that it will not work well if you drop some important columns. For example, if you drop the Foreign Key column, you won’t have a way to connect the tables. You might also get an error. That is not the case with NoSQL databases. You are free to play around with data, since there is no tables (columns and rows) involved.
Document Oriented Data Stores
Data is stored in the form of documents. Similar to putting related data in word files. That is the philosophy of document oriented data stores. Example, all data about you will be put in YourName file and all data about me will be put in MyName file. Your file may have your bank account details, while mine may have bank account details as well as passport details and my qualifications. There may be another document about our friend named HerName file. It may have her hobbies and no information that is on our files.
MongoDB has a replication mechanism that acts as a security to your data in case one or more of your machines go down. MongoDB gained its popularity mostly because of its flexibility. It may not be the best database for all purposes but for most cases it works well.
MongoDB is written in C++.
Tabular vs Document Oriented With Example
Here you can observe that in Accounts table, all rows that have the foreign key value as 0 have data about row 0 of Account Holders table. All rows that have the foreign key value as 1 have data about 1 of Account Holders table. ID column in Account Holders table is Primary Key, while Holder column in Accounts table is Foreign Key. Values in Primary Key column are unique. While, the same is not true for Foreign Key column. You can have multiple rows having same values in Foreign Key column, just like in the image example above.
Say, you want to delete data about Steven. To do that you will have to delete all rows from Accounts table that have Foreign Key value as 0, and only then you can delete the first row from Account Holders table. That is because, if you delete the first row from Account Holders table without deleting related rows in Accounts table, the rows will be pointing to nothing and that will throw an error.
This is what a data in a Document Oriented Data Store looks like. It is written in BSON (Binary JSON). If you observe, here, all data about Steven is stored together and all data about Sam is stored together. So, once you have the ID of Steven, you can access to all his information without looking for it in other places, such as separate tables like you do in Tabular Data Stores.
Take some time out and observe in the images how the same data is stored in Tabular and Document Oriented Data Stores.
In MongoDB, you can search for a document using any of the variables. It need not necessarily be Primary Key. Other than MongoDB, even CouchDB and DocumentDB of Microsoft use Document Oriented Data Stores.
Can We Store Files in Nosql Databases?
It is not wise to put files in SQL or NoSQL databases. Databases should have data that you can query against. You cannot query against a song or PDF file. For files like images, songs, or PDF files you must use storage places like Amazon S3. You can keep a pointer to the location of the files in the database to retrieve them at a later time. There is an overhead when you blow up your database size. There are better solutions to it, such as the Amazon S3 storage. We will be using Amazon S3 later. You can learn about it then.
NoSQL is not ideal for Big Data
Big Data is data in terabytes. NoSQL provides flexibility and can be scaled up but it does some trade offs to provide that scalability. NoSQL is more for flexibility. For Big Data something like Hadoop is ideal.
Be the first to get notified of our latest articles and stay ahead of competition. No need to share email address. Subscribe with just a click!
If you prefer watching videos over reading, you can go through the tutorial in the video below.