So the key characteristic of Relation is Tuple which shares the same type across multiple records. So if you look at below image, there are attributes and tuple. So same set of attributes are shared across multiple Tuples.<\/span><\/p>\n \u00a0 Let’s take one scenario where we are supposed to store the information related to employees of the company owned by you. So below would be the structure of Relation. This would be kind of table we will have considering we need to store Id, Name, Salary and DOJ.<\/p>\n As this company is run by developers like us, so we are playing as much as we earn and you can see we are kind organization who pays well. Just kidding. So we have these many employees. All the employees in this company share the same set of information(Id, Name, Salary and DOJ). So story is very happy till here and we are pretty much in control of solution. Now requirement has little bit of change as you decided to support some open source projects also. So you are asking programming community to support you in development of that open source. Since it is kind of open source and you are not expected to pay salary to some of you employees. So you don’t have salary attribute to some of these employees. Like\u00a0 this you have different set of attributes for every employee is different. So you need to store information like this.<\/p>\n So now we have to persist information. There are couple of ways to solve this problem using Relational Database. Either use a superset of all these tables and create table with all these attributes. So table structure would look like this.<\/span><\/p>\n Second option is to two table to store above information. One table with common set of fields and other with Property\/Value combination. So the second table would hold three fields. One EmployeeId foreign field which will map to first table. So after this redesign you table design is going to look like below.<\/span><\/p>\n You might argue that what would be problem with above approach to store different types of data using relational database. I would say it is perfectly fine and you can live with this as long as you are able solve your problem with Relational Database. But the point which I am trying to make here is different. It is not about having one extra field or creating a parent child relationship. It is about persisting data where every tuple has different set of attributes. So we have data which is non-relational in nature and trying to store in RDBMS(Relational Database Management System) but RDBMS are not inherently designed to store Non Relational data.<\/span><\/p>\n NoSQL term is used for broad set of technologies which are schema free, Non Relational, BASE(Not ACID), horizontally scalable and support “Web Scale”. Let us understand these features in detail.<\/p>\n Now your site becomes famous overnight and you started getting lot of hits. So scenario would be something like this.<\/p>\n Since it was a great site, the number of hits increased and one server was not able to handle the entire load. So you created a load balancing architecture where you have server farm to handle all this load.\u00a0 So the scenario would something like below.<\/p>\n Imagine a basic architecture where have entire app server connecting to one database. So although web server load is balanced but database server is single. So you also need to load balance at database server level. So eventual architecture would be something like below.<\/p>\n So now you have multiple copies of database to handle the load at database level. So either you would be using sharding, partitioning, denormalizing or distributed caching techniques. But after doing all these, you have to make sure the database is always in consistent state as per ACID. To make database consistent your availability would be compromised when there is new addition or update or delete of information. This model works fine till you need a web-scale level of application which I just explained above.<\/p>\n So the time you go for distributed system according to\u00a0Eric Brewer\u2019s CAP theorem<\/a>\u00a0if you want consistency, availability, and partition tolerance, you have to settle for two out of three. So in case of ACID, we settle for Consistency and Partition tolerant. But some cases Availability is more important than consistency. Imagine a scenario where it is okay to roll out new product(adding new merchandise in database) different database copies eventually and not in consistent way. So it would be added in one copy of database and then eventually propagated to other copies. This pattern is called BASE.<\/p>\n <\/p>\n <\/p>\n Below are some of the options available as part of NoSQL. Please refer http:\/\/nosql-database.org\/<\/a>.<\/p>\n![\"NoSQL_Image1\"](\"http:\/\/ajaykumar.co.in\/wp-content\/uploads\/2013\/04\/NoSQL_Image1.png\")
<\/a><\/span><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/span><\/p>\n\n