DEVTOME.COM HOSTING COSTS HAVE BEGUN TO EXCEED 115$ MONTHLY. THE ADMINISTRATION IS NO LONGER ABLE TO HANDLE THE COST WITHOUT ASSISTANCE DUE TO THE RISING COST. THIS HAS BEEN OCCURRING FOR ALMOST A YEAR, BUT WE HAVE BEEN HANDLING IT FROM OUR OWN POCKETS. HOWEVER, WITH LITERALLY NO DONATIONS FOR THE PAST 2+ YEARS IT HAS DEPLETED THE BUDGET IN SHORT ORDER WITH THE INCREASE IN ACTIVITY ON THE SITE IN THE PAST 6 MONTHS. OUR CPU USAGE HAS BECOME TOO HIGH TO REMAIN ON A REASONABLE COSTING PLAN THAT WE COULD MAINTAIN. IF YOU WOULD LIKE TO SUPPORT THE DEVTOME PROJECT AND KEEP THE SITE UP/ALIVE PLEASE DONATE (EVEN IF ITS A SATOSHI) TO OUR DEVCOIN 1M4PCuMXvpWX6LHPkBEf3LJ2z1boZv4EQa OR OUR BTC WALLET 16eqEcqfw4zHUh2znvMcmRzGVwCn7CJLxR TO ALLOW US TO AFFORD THE HOSTING.

THE DEVCOIN AND DEVTOME PROJECTS ARE BOTH VERY IMPORTANT TO THE COMMUNITY. PLEASE CONTRIBUTE TO ITS FURTHER SUCCESS FOR ANOTHER 5 OR MORE YEARS!

An Analysis of Relational Vs Key/Value Databases

The Relational Model

“A Relational Model of Data for Large Shared Data Banks” was first introduced by Edgar (Ted) Codd in June of 1970. It specifies the usage of Tables (relations), with rows (tuples) and columns (attributes). Each Table is perceived as a 2 dimensional structure. It contains data types that should (if developed correctly) contain values for Attributes that are related in some way with eachother. The columns are the unique Attributes, where the rows are the data values stored within the Attributes, that are themselves stored within the Table.

For example, a Table named “CAR” could contain data items named “Make”, “Model” and “Registration_Number” among other things related to a car.

TABLE: CAR
Make	   Model	Registration_Number
Nissan	   350z	        abc123
Bugatti	   Veyron	def456
Nissan	   Cefiro	ghi789

For each Table that is created, it must be headed with a special type of Attribute called a “Primary Key”; a Primary Key is a not null value that contains a relation with each other Attribute in the same row. With this Primary Key, a Table is able to identify all other values linked to it. In the example above, the Primary Key of choice would be the Registration_Number Attribute. As it is the only Attribute contained within the Table that is able to uniquely identify the other values in the Table. The Make and Model Attributes would not suffice as they could be referenced to multiple times within the Table. Foreign Keys are Primary Keys from other Tables that are able to be used as Attributes. These Foreign Keys link up other tables with one another to provide the correct information stored within the database. This is the base of the Relational Model These Tables form together in a database to provide the necessary ability to correctly store and manipulate data easily through the usage of SQL.

Good features of Relational Databases

The relational database has been in widespread use since the late 70’s. Due to this, it has become very well established in its field. Developers and IT professionals have created with it, a very firm and robust system of ensuring that the logic of a relational database is fully documented and covered to the greatest extent. This is mainly covered through the usage of Normalisation and the separation of Tables to their correct relations, as well as ensuring that the data kept is within integral rules, keeping redundant data and orphaned values minimal.

An added benefit of the relational database is the well documented and well defined query language; SQL (pronounced as Sequel). This language is used in conjunction with a relational database to provide necessary inputs to query the data within the database. It is well defined and cannot be used as an ad hoc approach to querying the database. Each statement has a complex backend that does not require the developer to know.

With these logic rules and definitions, a relational database is able to be very flexible and able to provide the necessary benefits from scalability, entity and referential integrity, and performance as well as an easy logical view of the entire database through the Table’s.

Bad features of Relational Databases

The main problem that is encountered with the relational database is scalability. Today’s 24/7 world features a greater demand for applications and workloads than when the relational model was first conceived in 1970, and as such, the size and pressure that is put on a database can change dramatically within the space of a few days (even hours). The scalability of a relational database can therefore become obsolete, quickly becoming overwhelmed by disk space issues and the costs of implementing new relational databases to help deal with the overflow of queries on the data. Once a relational database has spread from a single server, it can become more complex than necessary, putting more stress on the developers to ensure that all the entity and referential integrities are kept up to par.

By default, the relational database is unable to store complex data types such as pictures, video and audio. To overcome this issue, a Database administrator must install an extension that allows the usage of a Binary Large Objects. This will then allow the usage of some functionality from these additional types.

While the SQL query language is a good language to use as it allows the developers to specify easily what they are wanting when they call the query, if a developer wants to create an ad hoc query, they must have knowledge of the database structure. This can prove to be a complex and time expensive endeavour to complete, with the usage of OO methods and languages (explained later); it may be possible for a developer to easily create customised queries that are able to return the correct data through complex algorithms. As you can see from above, it may be easy to justify the usage of a relational database over a Key-Value database. It may also be easy to justify the usage of a Key-Value database over a relational database. The pros and the cons of the relational database are evenly distributed over a great scale. Generally as a rule of thumb, it is best to analyse the environment that the application will be running in before deciding on the type of database.

The Key-Value (Object) Database

The Key-Value database, is also known by many names, such as an Object database, a document based, or document oriented database, a distributed hash table and so on, there currently is no official name for this new paradigm and as such, it can be referred to by its traits rather than a name. Within this discussion I will refer to it as a Key-Value database or an Object database, as they both share many similarities.

The Key-Value database is an Object Oriented (OO) database that is comparable to many different OO languages that are around the world today, they work by having a base class that is created that acts as a ‘blueprint’ for objects that are able to be created. These classes contain data types and methods that can be as straightforward or as complex as the developer desires. A method is a function; it takes data as an input, performs a pre defined algorithm on the input, and then generates an output. This type of database is referred to as a Key-Value database as this is the method it uses to store the data. The Key-Value is comparable to a Hash Set or a Collection in an OO language. It stores the values within this collection with a key that the value may be called from.

For example:

TABLE: CAR
Key	Attributes
1	Make: Nissan
        Model: 350z
        Registration_Number: abc123
2	Make: Bugatti
        Model: Veyron
        Registration_Number: def456
3	Make: Nissan
        Model: Cefiro
        Registration_Number: ghi789

In this table each object is referenced by a Key, from this key all the attributes are linked in the value section, a developer would typically be able to retrieve the key, and then have access to all information that is linked with this object.

Good features of Key-Value databases

Easy to link information as primary keys are not required, each object that is created has knowledge of its own attributes and therefore does not need to explicitly be linked to other objects, although this may sometimes be the case if other objects contain referential information.

There is no such thing as an entity join within the Key-Value database, as each Key-Value store is considered to be “item oriented” each object within the collection is created to contain all the information it needs, as a result; this increases the ability to scale the database easily, although at the cost of disk space (see below).

Because of the easily implementable scalability features of the Key-Value database, it is quickly becoming more popular for use by cloud based services, as they can easily be spread out over multiple nodes, requiring little effort in comparison to the relational database.

Bad features of Key-Value databases

The most common problem with the Key-Value database is its double edged sword; scalability. Because data is commonly replicated within the database, it leads to far greater disk space issues, bigger disk space is needed, but disk space is generally cheap nowadays. The Key-Value database prides itself solely on scalability, whereas the relational database prided itself on lightly covering integrity, robustness, scalability, security and performance. To achieve the data integrity, security and performance issues a Key-Value database must rely on the application it was built around to ensure that these benefits are implemented. For example the application itself must be able to check to see if the data integrity constraints are met before the data is able to be saved into the domain.

In comparison to the robustness of the relational model, the Key-Value database has little to no structure in which it must be implemented, as such, the Key-Value database can be considered to be very ad-hoc, that is, a developer will create the Key-Value database with their own methods and abilities, and there is no grand scheme that the developer must follow. It can be built however they want it to be. This may cause some confusion between developers if they are constantly moving between different companies that use the Key-Value database, as each one could be significantly different.

Conclusion

As you can see from this analysis, both types of database have their benefits, and their flaws. While the relational model may be subject to greater and more rigorous pressure from companies that support the modelling of the relational model, this could ultimately become a burden, even if it does bring greater benefits in the way of greater security and robustness. Whereas the Key-Value database is more free flow, allowing the developers to develop the system the way they believe it should behave, this, once again could cause some trouble, as it is ad hoc there may be bugs that could cause data integrity issues in later development.


QR Code
QR Code analysis_of_relational_vs_keyvalue_databases (generated for current page)
 

Advertise with Anonymous Ads