As I have noted before, today there more great choices than ever when it comes to DBMS engines. In fact, many new engines are released each year. This is an incredible contrast to the days when the world was limited to a few major traditional RDBMS vendors – who would have ever imagined (let alone predicted) the shape and scope of the current DBMS market.
This article is a brief tour of a few of the types of DBMS engines available, and why it’s such a bonus to have this wide variety of choices – if you can make the right choice for your application’s needs.
This type of database is still the mainstay of the majority of applications. RDMBS engines provide the following benefits for application developers:
- Dependable and proven through over 20 years of development, testing and production use.
- They are ACID compliant, meaning you can count on your data and transactions succeeding (or failing) in a reliable fashion.
- Full support for the relational model, including referential data integrity and structure.
- Virtually every developer knows how to use an RDBMS and understand the SQL language.
- This type of engine is ideally suited for transactional applications, such as banking or e-Commerce applications – those that depend on the proven transactional integrity.
Of course there are drawbacks to using an RDBMS as well:
- Performance is limited, with vertical scaling (aka bigger iron) providing the only standard option for improving database performance. No matter what type of hardware environment you provide, vertical scaling is limited with this type of engine.
- These engines are perceived as complex, primarily due to the rich feature set developed over the years. It should be mentioned that those very features were done at the request of the developer community, but nonetheless there is a lot to learn to be fully proficient with an RDBMS.
- An RDBMS is also perceived as inflexible, as relational structure is dictated and enforce by the engine itself.
In summary, the RDBMS is a proven workhorse, but the lack of scalability and flexibility opened the door to a new and innovative breed of engines.
The next type of DBMS engine is the Key/Value Store, which stores objects in key-value pairs. The concept is incredibly simple, with two primary methods for writing and reading data: put and get. Key/Value Stores are nothing new, in fact caching vendors have been providing Key/Value semantics for many years.
The main advantages of the Key/Value Store are that it is:
- Simple and easy to use, often developers can start work with this type of engine in minutes.
- Flexible, you can store any type of object you wish.
- Easy to scale across multiple servers, as all that is required is the distribution of the keys using some sort of consistent hashing algorithm.
There are of course some disadvantages too:
- Since a Key/Value Store can store virtually any type of value object, it’s up to the developer(s) to rationalize the data structure. In fact, this type of DBMS is often referred to as supporting unstructured data, something that can result in trouble with a team of developers building a complex application.
- Given that all data is relational (see my many earlier articles on that topic), the way data elements relate to one another using a Key/Value Store must be completely maintained by the application code itself. In other words, it’s very easy to run into data inconsistencies, and referential integrity.
- Key/Value Stores often result in a large amount of de-normalized data (see other articles in this column on that subject). Application developers often end up having to maintain multiple lists of records embedded in a single value object, to support the various requirements of an application. This isn’t a bad thing overall, but it can be overdone.
In summary, a Key/Value Store is simple, quick to get up and running with, and is easy to scale. The drawbacks are that very flexibility – everything is in the hands of the developer and application code, opening the door to data integrity problems in a complex application.
The last category I will cover in this article is the Document Database. This type of database is very similar to a Key/Value Store, with one very important difference – a specific, consistent document format is used for the value objects. The most common format is JSON or a JSON variant, but other options exist (such as Google Protocol Buffers). A Document Database has the following advantages:
- Like a Key/Value Store, this type of DBMS engine makes it quick to get up and running.
- A Document Database can be easy to scale – also like a Key/Value Store.
- Due to the document structure, it is easier to add features to this type of DBMS, such as indexes on non-key values contained in a document. This makes the Document Database a closer cousin to the traditional RDBMS engine.
The drawbacks are pretty much the same as a Key/Value Store, in that it’s strictly up to the developer to control the data structure.
Wrapping it up
In this article, I covered just some of the types of DBMS engines available, and there will be more categories to come in future articles. I will also be covering how to choose the right DBMS engine (or engines) for the job in your own applications. Making the best choices can save incredible amounts of work, and offer great performance and scalability if appropriate selections are made.
Cory Isaacson is CEO/CTO of CodeFutures Corporation. Cory has authored numerous articles in a variety of publications including SOA Magazine, Database Trends and Applications, and recently authored the book Software Pipelines and SOA. Cory has more than twenty years experience with advanced software architectures, and has worked with many of the world’s brightest innovators in the field of high-performance computing. Cory has spoken at hundreds of public events and seminars, and assisting numerous organizations address the real-world challenges of application performance and scalability. In his prior position as president of Rogue Wave Software, he actively led the company back to a position of profitable growth, culminating in a successful acquisition by a leading private equity firm. Cory can be reached at firstname.lastname@example.org