No SQL Databases Mongo DB

Introduction

• A document-oriented database (commonly known as NoSql) is a data store of a group of documents (instead of group of rows).
  • In case of MongoDB, group of JSON documents are stored in the database.
• In general, NoSQL provides a way to bypass schema definition and let store whatever you want in any field, you need not define fields before developing the application. So, a lot of efforts are saved and you have flexibility in future.
• Let us skip forward the theory and dive into the practicals, while reading through you can try out the commands in the MongoDB Web Shell

Comparison with SQL database

Lets take an example of a pizza restaurant application with users and their orders.

• Use case: Store orders placed on the web application.
• Example entities in document-oriented database like MongoDB

    Orders: [{
      id: 93843,
      userId: 82734,
      items: [{
       id: 67834,
       quantity: 2,
       customisation: {
        pizzaBase: 4352
       }
      },{
       id: 54756,
       quantity: 1,
       customisation: {
       toppings:[{
        id: 32433
       }]
      }],
      vouchers:["FREEMEAL"]
    }]

   Users: [{
    id:82734,
    name:"John",
    email:"john.wesley@yahoo.com"
   }],

   Menu: [{
      id: 67834,
      name: "Margherita Pizza Medium"
   }, {
      id: 54756,
      name: "Garlic Bread"
   }]

   Toppings: [{
       id: 32433,
       name: "Cheese spread"
   }]

   Vouchers: [{
       id:"FREEMEAL",
       description: "50% off* (max discount Rs.50/-)."
   }]

Representing same data and relationships in trivial relational database say MySQL using different types of normalization:
   We would require following tables :
    User
    Menu
    Toppings
    Vouchers
    Orders
   In addition, we would require at least following additional tables for storing relationships.
    VoucherOnOrder          orderId|voucherId
    OrderMenu               orderId|menuId
    OrderMenuToppings       orderId-menuId|toppingId
    OrderMenuCustomisation  orderId-menuId|cutomizationType|cutomizationId

Benefits of document-oriented approach

We can see in above example, we do not need all the mapping tables because in case of document store we can store arrays in our order document to link the related entities.

• Schema-less: We do not need to define a database schema at the database level i.e. no need to define collections, fields and field types. With this, we get the flexibility to store even different types of documents in the same collection, although storing completely different documents does not make sense, but some variations allow flexibility, ease of transition when we want to store new fields. Did you notice how easily we could have a field for pizzaBase instead of topping for one of the order that required pizza base customisation. For storing this data in SQL, we would either require new set of tables or would need to tweak it into the toppings table.
• Easy to use with Javascript apps as both the application and database use JSON data structure, so we could possibly save on marshaling/un-marshaling of data.
• No complex joins required with embedded documents.
• Deep query-ability. MongoDB supports dynamic queries on documents using a document-based query language that’s nearly as powerful as SQL
• Indexing on fields or nested field values, compound indexes.
• Ease of scale-out: MongoDB is easy to scale, we can add shards and replicas to the database at any time required and MongoDB will balance the storage and requests.

How to decide what to use

• Document-oriented storage can be used across all general domains and we can simplify storage of relationships.
• It becomes more promising in case we have a completely unstructured data, say for a data-mining/analytics project.
• Also helpful in case of big data projects due to the ease of scalability.
• Unlike SQL by default, MongoDB is non-transactional, which means a single document crud operation is atomic, but a set of operations together are not. Single-document atomicity is sufficient for many practical use cases and the program can handle failure cases. But in case we have very critical information say banking transaction where we need the database to ensure multiple document atomicity we can enable 2-phase commit in MongoDB.
• However, if the application involves complex transactions it may be better suited to stick with a transactional database like MySQL.
• In fact, there are many questions you should answer to decide which database to choose from the many available :
  • Flexible Schema?
  • Transactions?
  • Consistent or Available?
  • Nested-object Queries?
  • Aggregations?
  • Geo-querying?
  • Time-series querying?
  • Secondary Indexes?
  • Ease of operations & management?

More to explore

• We can store javascript functions in the database which can be used like stored procedures or for many other purposes, say data migration.
• Perform aggregations and map-reduce operations.
• We can store file handles directly in the database, no need to convert to blobs.

This was only to catch your attention, if you find this interesting continue reading on at https://docs.mongodb.com/manual

Other NoSQL databases.

• Cassandra A decentralized distributed column-oriented database designed originally at facebook.
• Redis popular key-value in-memory data store, can be used for caching.
• Neo4j graph database system, for linked/relational data.
• And many more…