MongoDB review

Author: Eugeniy Marilev
Date of publication: 2014-09-03 19:54:54

In this article we will focus on MongoDb. Almost everybody has heard about it, but not everybody imagines what it is. Some people know from rumors that this is something interesting and something more useful than mysql. Some cannot even say this. And some have already used it in their projects, but did not quite understand why... simply because they were told to. This article should clarify some omitted points or fill in the gaps in knowledge, as mongoDb for a programmer is kind of like a monkey wrench for mechanic: you can handle it with something you are used to, but the result will be slower and sloppy.

General principles of mongoDB

MongoDB - a document-Oriented NoSQL database that translates: uses documents to store data, and to work with them is not using SQL. MongoDB can have zero or few databases inside. Each database consists of a collection, the collection - is an analogue of the table in a relational database. Each collection consists of zero or more documents, the document - is an analogue of a line in a relational database. Each document consists of fields, field - is analog of columns in relational databases. Indexes in mongoDB are identical to relational databases.

Advantages and disadvantages in comparison with SQL databases

The main advantage of mongo - structureless, as a result - no need to create the database in advance, collections, indexes etc., minimum discrepancy with the OOP (the collections are identical to classes, and the documents, in their turn, are identical to class' attributes that makes it very easy to project collection into classes), and accordingly - a flexibility that allows us to create nested documents. And as an output we get 1 document, which consists of 5 nested, and 5 nested, in their turn, consist of 3 nested, etc. It's quite time-consuming to implement join-s in SQLDB, but here we get the first little disadvantage of mongo - absence of any join and therefore - if you have to scale the data horizontally (e.g. hitch up values ​​of handbooks by id), you will have to implement join-s with your own hands on the client. An alternative is to record all related data to the array below, which in itself is very comfortable and it is an advantage. Another option is a denormalization.

categories: [
ObjectId(«4e209564203d83940f003»),
ObjectId(«4e209564203d83940f004»),
ObjectId(«4e209564203d83940f005»),
ObjectId(«4e209564203d83940f006»),
]

Another advantage of mongo - is the support of auto sharding. Sharding - a kind of scaling, when the data is stored on different servers. Example: A-server stores all the boys, B-server stores all the girls, C-server stores all the rest. Next one is a support of geospatial indexes that can store X and Y coordinates of the document, and then find nearby documents or documents in a circle or rectangle. The final tangible advantage is record without confirmation, which can significantly speed up the performance, but it's a minus as well, because it increases the chances of data loss. Another drawback - it is absence of transactions, I think, no need to talk about it, it's all clear. There are a number of minor flaws: there is no toolkit, as in a relational database, as nosql itself is much younger; lack of full-text search; inability to ensure the sustainability of storage on a single server, but this is solved by replication or journaling.

Examples of when to use mongoDB

I will give two examples:

  1. When logging. Moderate that mongo is recording without confirmation, logging speed will be significantly higher than in relational databases + we are not tied to the structure, and logs an arbitrary data structure - this is exactly what you need. The advantage of the same for this problem is that the collection writes documents in order of their receipt, that is the last document in the collection will always be last in the log. But that's not all, in mongo have the opportunity, as the installation size of the collection:
    db.createCollection('logs', {capped: true, size: 1048576})
    
    Thereafter, when the file reaches 1 MB, the old data will be overwritten and that, in my opinion, is very, very convenient.
  2. When creating entities that include other entities. Example: we have questions that contain text, an image or link, and the response options: Question1:
    {
    _id: objectId («4e209564203d83940f005»),
    type: «composite»,
    right: 1,
    items: [
    {
    type: «image»,
    url: «http://google.com/image.jpg»,
    alt: «gg»,
    title: «gl&hf»,
    },
    {
    type: «text»,
    text: «How many rabbits on the picture?»
    },
    ]
    }
    
    Question2:
    {
    _id: objectId («4e209564203d83940f006»),
    type: «composite»,
    right: 3,
    items: [
    {
    type: «link»,
    url: «http://en.wikipedia.org/wiki/Triple_Entente»,
    },
    {
    type: «text»,
    text: «How many countries were in Triple Entente?»
    },
    ]
    }
    

    As you can see we have no clear structure of questions, so we can arbitrarily set the data necessary for us. Next, we need to make a test, which will consist of the questions above. This is done very simply:

      Type «quiz»:
    {
    _id: objectId («4e209564203d83940f007»),
    title: «Some text»,
    type: «quiz»,
    items: [
    ObjectId(«4e209564203d83940f005»),
    ObjectId(«4e209564203d83940f006»),
    ]
    }
    

These 2 examples show the main advantages of mongoDB - flexible storage, the vertical scale (one entity includes several sub entity) and other pleasant things.

The best solution - is to use a combination of SQL and MongoDB

So what is better, mysql or mongoDB? Better both, but only where you need it. For example, in the example of the logs, mysql is not needed at all, but in the second example, the tests will be sent to someone, there will be some results, which means users will appear. If users appear - may appear groups. So, you can use and store data denormalization mongo, but better - to make structured data tables in mysql, and the bond of documents mongo with sql database to perform by key fields of the tables mysql (e.g., (mongo) somecollection .userId → (sql) user.id, (mongo) somecollection.groupId → (sql) group.id).

That's it, now you have an idea of ​​nosql. As you know, this is not a necessity, just a different approach that is more appropriate in some situations. Lazy will not learn it, and smart – will learn and apply in practice and increase their value in the labor market.

Article comments
Comments:
No results found.
Only logged users can leave comments.