For most of my programming life, when I needed to store data I turned to an old friend the relational database. Over the years, I have used many different databases like MS Access, MS SQL Server, MySQL, SQLIite, Oracle SQL, and ProgreSQL. I have used some type of relational database for so long it is fairly easy to divide the data into groups, turn the groups into table, establish keys, create relationships, and throw in a few indexes for good measure. Using a relational database for a brand new project is usually fairly nice, I can make the database tables and models fairly close. As the project matures and requirements change, the database structure and the models drift apart in design. The traditional relational database has been good to me over the years. There have been time when a relational database has not been the right choice for the project. Relational databases can be very expensive to setup, maintain and to secure. The question now has become where do I turn when old reliable is not a good fit.
One option is to use a NoSQL database. My knowledge on this topic is fairly limited. Today is the day that I am going to expand that knowledge. Common characters of NoSQL include not using a relational model, runs well on clusters, open-source and schema-less.
When I look under the covers a relational database, I notice that the data is stored as three parts -key, value and a relationship. There is a limitation with this model. It does not allow for the storage of structures like a list or a nested records. As demand on a relational database increases to handle more traffic or more data, there are two common approaches for dealing with this. One is to increase the size of the machine by adding more hard drives, additional memory, and more CPU. This is commonly known as scaling up. The other option is to add servers together into a cluster. All the machines share the work of getting and storing data. This is known as scaling out. A group of machines like this known as a cluster. For a relational database to operate in a cluster it usually shares a common shared disk subsystem. The schema for a database is the metadata about all the parts of database. The metadata describes things like table structures, indexes, keys, views, stored procedures and the like. This allows the relational database engine to enforce structure. One can make a strong argument that the structure of the database and their relationships is a form of business rules.
NoSQL database a general rule don’t use T-SQL syntax to query there data store. Many of the databases allow for a RESTful interface and/or query API. NoSQL runs well in a cluster. There are few options on how to the database can be setup within a cluster. The simplest is to run the database on single server. Sharding is another option. Sharding is splitting the data into different parts and putting each part on its own server. The third option is Master-Slave Replication. Data is written to the Master database and then replicated to the Slaves. Data can be read either the Master or the Slave. This is great for read intensive applications. Another option is to use Peer-to-Peer. In this option a write to any of the node would be replicated to all the others databases in the cluster. This is a good configuration for applications that have a lot of writes or when the application needs to guard against a failure of any single node. The last option is to combine Sharding with Replication. This gives a lot of options for how to setup a database for you application. NoSQL are known for being schema-less. This means the each record does not have to be the same as any other record in the database.
NoSQL databases are categorized by the way they store data. Common categories are key-value, document, and graph. Key-value databases store just two pieces of data for a record. The key or Id and the value either a primitive data type or an object. Document databases are built around the concept of a document. The document is are self-describing hierarchical data structures. Graph Databases allow entities and the relationships between entities to be stored.
Examples of Key-Value databases
When to use Key-Value databases
- When needing to store Session
- When needing to storing User Profiles
- When needing to storing Preferences
- When needing to storing Shopping Cart Data
When not to use Key-Value databases
- When there is a relationship between data sets
- When multioperation transactions are required
- When there is a need to search by the value or data
- When there is a need to operate upon multiple keys at the same time
Examples of Document databases
When to use Document databases
- For event logging
- For Content Management Systems
- For Analytics
- For Blogging Platforms
- For E-Commerce Applications
When not to use Document databases
- When there is a need for complex transactions spanning different operations
- When needing to search against the content of the document
Examples of Graph databases
When to use Document databases
- When there is connected data
- When building routing services
- When building recommendation engines
When not to use Document databases
- When you want to update a subset of entities.