For the past several decades, database professionals use a single standard supported by all databases: which is the Structured Query Language (SQL). We've relied upon the table-oriented relational database for all of our data storage and retrieval needs, without thinking about other alternatives. But now time is changing. The NoSQL database model tosses the relational model on its head by abandoning many deeply held beliefs about the "proper" structure for a database. In exchange for removing some of the design constraints, NoSQL databases can achieve enhanced performance flexibility.
Changing the Model
Relational databases have always relied upon some very hard-and-fast, structured rules that govern the conduct of database transactions. These are encoded in the ACID model and require that the database always preserve the some rules which are atomicity, consistency, isolation and durability of database transactions. Any action that might violate the ACID model is expressly prohibited and there is no way to handle some fuzzy situations.
NoSQL uses the BASE model and turns the ACID model upside down and allows a much more laissez-faire approach to database management. Instead of requiring strict adherence to the ACID principles, BASE offers three loose rules which are basic availability, soft state and eventual consistency. It's fair to say that NoSQL's BASE approach is the laid-back alternative to the straight-laced ACID model used by relational databases.
If Not Tables, Then What?
Instead of using structured tables to store multiple related attributes in a row, NoSQL databases use the concept of a key/value store. Quite simply, there is no schema for the database. It simply stores values for each provided key, distributes them across the database and then allows their well-organized retrieval. The lack of a schema prevents complex queries and essentially prevents the use of NoSQL as a transactional database environment.
There are four main types of NoSQL databases:
The core of the NoSQL database is the hash function – a mathematical algorithm that takes a variable length input and produces a consistent, fixed-length output. The key of each key/value pair being fed to a NoSQL database is hashed and this hash value is used to direct the pair to a particular NoSQL database server, where the record is stored for later retrieval.
When an application wishes to retrieve a key value pair, it provides the database with the key. This key is then hashed again to determine the appropriate server where the data would be stored (if the key exists in the database) and then the database engine retrieves the key/value pair from that server.
As you read the description of this process, you may find yourself wondering "How does the user or application perform more advanced queries, such as finding all of the keys that have a particular value or sorting data by a value?" And, there's the rub – NoSQL databases simply do not support this type of functionality. They are designed for the rapid, efficient storage of key/value pairs where the application only needs a place to stash data, later retrieving it by the key, and only by the key. If you need to perform other queries, NoSQL is not the appropriate platform for your use.
Redundancy and Scalability in NoSQL
The simplistic architecture of NoSQL databases is a major benefit when it comes to redundancy and scalability. To add redundancy to a database, administrators simply add duplicate nodes and configure replication between a primary node and its counterpart. Scalability is simply a matter of adding additional nodes. When those nodes are added, the NoSQL engine adjusts the hash function to assign records to the new node in a balanced fashion.
I guess you came to this post by searching similar kind of issues in any of the search engine and hope that this resolved your problem. If you find this tips useful, just drop a line below and share the link to others and who knows they might find it useful too.
Stay tuned to my blog, twitter or facebook to read more articles, tutorials, news, tips & tricks on various technology fields. Also Subscribe to our Newsletter with your Email ID to keep you updated on latest posts. We will send newsletter to your registered email address. We will not share your email address to anybody as we respect privacy.
Changing the Model
Relational databases have always relied upon some very hard-and-fast, structured rules that govern the conduct of database transactions. These are encoded in the ACID model and require that the database always preserve the some rules which are atomicity, consistency, isolation and durability of database transactions. Any action that might violate the ACID model is expressly prohibited and there is no way to handle some fuzzy situations.
NoSQL uses the BASE model and turns the ACID model upside down and allows a much more laissez-faire approach to database management. Instead of requiring strict adherence to the ACID principles, BASE offers three loose rules which are basic availability, soft state and eventual consistency. It's fair to say that NoSQL's BASE approach is the laid-back alternative to the straight-laced ACID model used by relational databases.
If Not Tables, Then What?
Instead of using structured tables to store multiple related attributes in a row, NoSQL databases use the concept of a key/value store. Quite simply, there is no schema for the database. It simply stores values for each provided key, distributes them across the database and then allows their well-organized retrieval. The lack of a schema prevents complex queries and essentially prevents the use of NoSQL as a transactional database environment.
There are four main types of NoSQL databases:
- The basic key/value store performs nothing other than the function described above – taking a binary data object, associating it with a key, and storing it in the database for later retrieval.
- Document stores go beyond this slightly by imposing a little more structure on the binary object. The objects must be documents, encoded in some recognizable format, such as XML or PDF, but there are no requirements about the structure or content of the document. Each document is stored as the value portion of a key/value store and may be accompanied by metadata embedded in the document itself.
- Columnar databases are a hybrid between NoSQL and relational databases. They provide some row-and-column structure, but do not have the strict rules of relational databases.
- Graph databases store information in multi-attribute tuples that reflect relationships in a different way. For example, a graph database might be used to store the "friend" relationships of a social network, with a record merely consisting of two friends who share a relationship.
The core of the NoSQL database is the hash function – a mathematical algorithm that takes a variable length input and produces a consistent, fixed-length output. The key of each key/value pair being fed to a NoSQL database is hashed and this hash value is used to direct the pair to a particular NoSQL database server, where the record is stored for later retrieval.
When an application wishes to retrieve a key value pair, it provides the database with the key. This key is then hashed again to determine the appropriate server where the data would be stored (if the key exists in the database) and then the database engine retrieves the key/value pair from that server.
As you read the description of this process, you may find yourself wondering "How does the user or application perform more advanced queries, such as finding all of the keys that have a particular value or sorting data by a value?" And, there's the rub – NoSQL databases simply do not support this type of functionality. They are designed for the rapid, efficient storage of key/value pairs where the application only needs a place to stash data, later retrieving it by the key, and only by the key. If you need to perform other queries, NoSQL is not the appropriate platform for your use.
Redundancy and Scalability in NoSQL
The simplistic architecture of NoSQL databases is a major benefit when it comes to redundancy and scalability. To add redundancy to a database, administrators simply add duplicate nodes and configure replication between a primary node and its counterpart. Scalability is simply a matter of adding additional nodes. When those nodes are added, the NoSQL engine adjusts the hash function to assign records to the new node in a balanced fashion.
I guess you came to this post by searching similar kind of issues in any of the search engine and hope that this resolved your problem. If you find this tips useful, just drop a line below and share the link to others and who knows they might find it useful too.
Stay tuned to my blog, twitter or facebook to read more articles, tutorials, news, tips & tricks on various technology fields. Also Subscribe to our Newsletter with your Email ID to keep you updated on latest posts. We will send newsletter to your registered email address. We will not share your email address to anybody as we respect privacy.
No comments:
Post a Comment