MENU

5 Things You Need to Consider Before Choosing a Database Technology

January 28, 2015 • Databases

FoundationDB is a multi-model database that combines scalability, fault-tolerance, and high performance with multi-key ACID transactions. If you’re trying to choose a database technology for your application it can be really tough. The database market is evolving rapidly. From NoSQL, to NewSQL, to the mature relational systems, there’s no shortage of solutions to sort through.

Moreover, database technologies differ along multiple dimensions, so comparisons can get tricky. What technology is best for you can depends on exactly what your application needs.

Below, we’ve laid out the key technical factors you should consider when choosing a database technology. Consider them guideposts to help you navigate through the thicket of options.

1. Data model

One of the most fundamental issues has to do with the “shape” of your data. Some data is naturally expressed in normalized tables. Some data centers on structured objects that translate easily into embedded JSON documents. Some data has a natural graph structure consisting of nodes and links. In the simplest case, your data is like a dictionary with keys and values.

Application data can fall into any of these categories or into more than one. This can make it tough to choose a database solution because most of them support only a single data model (relational, document, graph, or key-value). A poorly matching data model can complicate queries and harm overall performance.

2. Query language

Not every application requires a separate query language (e.g., SQL). Some applications are well-suited to accessing data through a programmatic API. In this case, a query language may not be a concern.

However, you may have legacy code you don’t want to rewrite that uses SQL. You may have DBAs or analysts who need to access the data directly. In these cases, you’ll want a solution that supports SQL. But be careful: there’s been a trend recently for NoSQL systems to add query languages with a “SQL-like” syntax, but most of these add-ons lack features of standard SQL, such as transactions and joins.

3. Scalability

Applications grow over time. The old solution to this problem was to replace your server with larger and larger ones, which quickly becomes very expensive. This approach is sometimes called “vertical” scaling. The newer alternative, “horizontal” scaling, allows you to add commodity hardware to a distributed cluster, which is usually much cheaper.

At the same time, mutli-client applications often rely on transactional guarantees for their database operations, and it’s challenging to provide transactions over a distributed cluster. Most of the NoSQL systems have jettisoned support for transactions for the sake of simpler distributed designs, i.e., simpler for the database designers, not for you!

4. Consistency model

Operational databases usually have multiple clients performing updates concurrently. As a result, they need mechanisms to hande potentially conflicting updates. The mechanisms these systems use vary widely.

Some systems offer only weak consistency guarantees. For example, eventually consistent systems guarentee that reading a key will return its most recently updated value only after a sufficient period of quiescence. Application clients are then responsible for managing conflicting values. In contrast, systems with strong consistency guarantee that any write acknowledged to a client will be readable by all clients.

5. Concurrency control

Of course, applications don’t just perform single writes. They often need to perform a whole set of reads and writes as determined by their business logic.

Some systems support only atomic operations within a restricted scope, such as a single row or a single document. The strongest form on concurrency control is to support transactions with full ACID properties over multiple keys on any node in the cluster. However, even systems claiming to offer transactions vary significantly in their performance and support for ACID properties.

Design choices

Every database system makes design choices across each of these dimensions. We’ll use FoundationDB as an example, since it’s the system we’re most familiar with. FoundationDB supports:

  • an ordered key-value store and implements other data models, such as relational or document-oriented, as layers;
  • full ANSI SQL via its SQL Layer;
  • a distributed, shared-nothing architecture with linear scaling of performance and cost;
  • a strong consistency model;
  • full ACID transactions over multiple keys stored anywhere on the cluster.

Good luck with your database technology search, and have fun!

JOIN OUR NEWSLETTER
Join the numerous visitors who have subscribed to our newsletter on ICT News Africa from Tebudele.Com!
We hate spam. Your email address will not be sold or shared with anyone else.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

« »