RDBMS vs NOSQL

 RDBMS : 
        RDBMS stands for Relational Database Management System, example of this RDBMS is mysql, postgresql etc., this database systems is build primarily on relations between tables as of primary key and foreign key. The tables  in this databases are with fixed schema as per we cannot change the no of columns when our application scales up. when you want to use the application for the Transaction involved then RDBMS is the way to go. The primary selling point of the RDBMS is the Transaction. 



    when we try to scale our application, we can use 2 methods namely 

Vertical Scaling
Horizontal Scaling 

Limitations of Scaling with RDBMS : 

    When the data is present in only one server, then the scaling in RDBMS is also good but when the application grows we need multiple servers to  store the data, while calling that because of the network I/O and the join statements is  usually a costly query to run. While combining with the other servers it makes the query very slow. That is when we need to have distributed systems in place. 
With vertical scaling, single point of failure happens if anything goes wrong and the cost overhead is also too high. In the long run, the return we get from the cost we spend is too low. So it is not an optimal solution.
When We use horizontal scaling, it have connections with other servers in circular fashion rather than  in vertical fashion. The main limitations in horizontal scaling is that it cannot handle partition handling well. We will lose data when the partition handling happens in the system.




Distributed Systems : 

        The above 2 problems is solved by having distributed system in place with more than 2 copies of the data is present with the  system. This is like the shield against partition handling.  When we talk about the distributed systems we need to talk about the 

CAP THEORM:

1. consistency
2. Availability
3. partition Handling





    As per CAP theorem we can only have any 2 of the above with partition handling is the primary thing, because we cannot afford to lose the data while improving the  performance. Within consistency and Availability we need to choose between these 2 based on the requirements of our application.
for ex., for a application like SWIGGY or ZOMOTO  we should choose availability over consistency, because in that competitive market user can easily jump to other services in the time it becomes available. for BOOKING applications involved we must need consistency over availability we don't need the same ticket to book twice.

     usually it takes t time, to see the changes to reflect in every server it have been redundancy for that t time the system is not consistent. Because the change is not reflected everywhere it gets changed. At this time, we can remove the servers  not yet updated from the  application for the time t, so that it makes the system more consistency.
    For some use cases, we can take a fake data for the time  t, in order to make the application more available. Even with the wrong data, we still want our system to be available to keep the customers in place.
 

NO-SQL : 

    NoSql makes use of the dynamic schema and also the distributed systems. Dynamic schema refers to constantly changing columns. It doesn't needs to be constant or fixed. we can have any number of fields in each document present in Nosql. Nosql still supports Transaction upto certain limit. NOSQL is the way to go if you don't have the static schema, and want to scale your systems in the future for the application.



    

Comments

Popular posts from this blog

Converting ids into order id in join statement.

Launching AWS hosting services.