Ultimate Flexibility: Plug & Play with Altibase

Introduction

IT organizations around the world today are scrambling to embrace the latest and greatest in new technology trends.  Whether that consists of cloud deployments, XaaS, container technology, etc., IT organizations are learning that failing to embrace new technologies inevitably leads to being overtaken by their competitors.

It goes without saying that databases are a key element of any organization’s IT infrastructure.  With the advent of NoSQL and NewSQL databases, organizations are now trying to see how to integrate these new technologies into their existing infrastructures.  In many situations, these new database technologies are enabling applications that would have been extremely difficult, if not impossible, to implement just a few years prior.  But troublingly, many organizations are embracing these new technologies without fully understanding their advantages, disadvantages, and the ramifications thereof.

A recurring theme in the database industry today is the notion that “the relational database’s days are numbered.”  What people often forget is that this sentiment has been around long before the advent of NoSQL or NewSQL.

And yet, relational databases are still here.  Not only are they here, but they are still by far the most dominant database model in the industry.

What is a Relational Database?

Before going further, it is important to define what a relational database actually is.  Some may point to Codd’s 12 rules as the quintessential definition of the relational database.  But as virtually no commercial relational database adheres to all of Codd’s rules, in practice it is not relevant.

While relational databases have many characteristics, an IT professional who was asked to define a relational database would generally state something along the lines of:

  • Presents data to the user as relations, in the form of tables that consist of rows and columns
  • Supports integrity rules including primary keys, foreign and unique constraints, NULL values, etc.
  • Supports SQL syntax
  • Supports transactions
  • Is ACID compliant

It is interesting to note that many databases who claim to be “relational” do not seem to adhere to some of these principles.  For example, VoltDB is a relational database that as of the publishing date of this whitepaper, does not provide support for foreign or unique constraints.

Therefore, it is important for prospective customers to determine whether the vendor’s definition of relational and their own are equivalent.

The “Decline” of the Relational Database

In refuting the argument that relational databases are outdated, it is interesting to evaluate the evolution of database technology in the past decade.

When NoSQL first exploded onto the database scene, its advocates began to predict that non-relational databases would begin to rapidly overtake relational databases as the dominant database paradigm.  Some of the justifications for this belief included:

  • “Relational databases aren’t scalable.”
  • “Relational databases are all based on ancient technology.”
  • “Modern applications aren’t using relational databases.”

But despite all these “failures” of the traditional relational model, it’s interesting to note the fairly recent evolution of NewSQL databases.  Whereas NoSQL sought to break away from the relational paradigm and its limitations, NewSQL’s primary characteristic is that it attempts to maintain NoSQL principles while adhering to the relational data model.  In other words, some of the newest database technologies are attempting to re-integrate the same characteristics that were used to malign the RDBMS.  Why?

Because the relational data model works.

Relational databases still have a stranglehold on the database market.  DB-Engines is a website that utilizes an algorithm to assess a database’s “popularity score” by looking through the prevalence of search results, job offers, professional profiles mentioning the database, etc.  While this is hardly scientific in terms of actual utilization, it provides a rough approximation of database usage patterns.

Out of the top 10 most “popular” databases, 7 of them follow the relational data model.  More importantly, the combined “score” of the top 7 relational databases was 4586.82, while the non-relational databases’ combined score was a mere 507.45.  In fact, Oracle alone has a higher “popularity score” than the next ten highest rated non-relational databases combined.

While the growing adoption of non-relational database technologies is a well-established fact, the evidence would suggest that reports of the “demise of relational databases” have been greatly exaggerated.

Choosing the Right Database

It is important to note that this whitepaper is not meant to discredit the importance of NoSQL databases and/or other non-relational database models.  In fact, we believe that non-relational database models will play a critical role in modern IT infrastructures and that they can accomplish things that are currently impractical and/or impossible with relational databases.

However, the world of databases and software in general is rife with superlatives.

  • “What’s the fastest database?”
  • “What’s the cheapest database?”
  • “Which database can handle the most concurrent users?”
  • “Which database can scale horizontally to the most nodes?”

As veterans of the database industry, we cannot count the number of times we’ve been asked, “So what makes you the best database?” The question is fundamentally flawed. 

There is no such thing as the best database.  What IT leaders and solutions architects should be looking for is the right database.

What is the right database?  The right database is the database that best meets the requirements of the application it’s enabling.  A column-store analytical database is probably not the best fit for a transactional OLTP application.  A traditional relational database is likely not the best fit for an application where linear horizontal scalability on commodity hardware is an absolute requirement.

The database selection process should never begin until after the application requirements are clearly defined. 

Once the requirements of the application are well understood, the task of selecting an appropriate database is typically rather trivial for a competent solutions architect.

Databases are about Sacrifices

Another reality of the database industry that is rarely talked about is the fact that databases are inherently about sacrifices.

For every “amazing” feature that a database touts, something had to be sacrificed to accommodate it.  Here, we’ll use horizontal scalability, one of the most widely touted features of newcomers in the database industry, as an example.

Horizontal scalability is referred to as the ultimate panacea for all database problems.  Having a performance issue?  Just add another node.  But is it really that simple?

What must be sacrificed to accommodate horizontal scalability?  How does a horizontally scalable database handle distributed queries?  Does it support constraints?  What consistency model does it follow?

One of the more amusing consequences of this is that database vendors often tout complete opposites as advantages.  For example, one database may advertise that their single-threaded architecture allows for tremendous performance improvements by avoiding locks while another database may advertise that their multi-threaded architecture allows for tremendous performance improvements by improving concurrency.

So while customers obviously always want the “best of both worlds,” experienced solutions architects recognize that making the right choice is often about making the appropriate sacrifices.

What Makes Altibase Different?

Interestingly enough, what makes Altibase different is that we are actually not that different. While other database vendors endeavor to reinvent the wheel, we’ve endeavored to improve the wheel.  As it so happens, wheels work pretty well! In the previous sections, we established that while relational databases are not ideal for all use cases, they are certainly well suited for many, if not most, use cases. But it’s become clear that in the world of cloud, big data, and increasing customer volumes, legacy disk databases were starting to fall behind.  IT environments are getting increasingly more complex as architects scramble to put “band-aids” on various issues that arise.

So what’s the solution?

Altibase’s main goal is to enable developers by providing flexibility.  Going back to the topic of sacrifices, Altibase provides the most flexible general purpose DBMS available through the use of its unique hybrid architecture.  This allows customers to:

  • Use in-memory performance to provide real-time data access and enable high-speed applications
  • Use on-disk storage for cost-effective data storage for large data sets
  • Simplify adaptability by allowing easy data migration and joins between the two storage mediums

In other words, Altibase is capable of providing the order of magnitude performance boost required by modern applications while simultaneously adhering to the tried and true model that has been powering applications for the past few decades.

Gartner previously cited one of Altibase’s advantages as having “wide use-case applicability.”  This advantage should not be understated.

Currently, many IT organizations tend to utilize a single database if possible.  This has spawned terms like “Oracle shops” and “SQL Server shops,” that the IT industry uses to describe an organization’s database of choice.  This trend is not simply the meaningless result of favoritism, but a logical conclusion of the question:

How much more value must a new database provide in order to justify the extra administrative expenses of maintaining multiple disparate database systems?”

In Altibase’s case, the latter half of that question becomes trivial.  Former Oracle and SQL Server DBAs routinely give Altibase high marks for ease of use and its low learning curve.  Also, Altibase’s wide use case applicability and high performance means that IT organizations can greatly expand the scope of their applications without having to introduce an excess of disparate database technologies into their solutions stack.

Why are Customers embracing Altibase

As a database vendor, we see on a daily basis what IT leaders are looking for in their database solutions:

  • Performance
  • Cost Savings
  • Scalability
  • Ease of migration
  • Ease of management
  • Interoperability with their existing systems

To keep things simple, our customers are turning to change to us because of our ability to execute while keeping costs low.  Whereas migrating an Oracle application to a fundamentally different database like NoSQL may be prohibitively difficult and risky, migrating from most RDBMS systems to Altibase is often quite trivial.  For very simple applications, sometimes a quick swap of the JDBC connection string is sufficient!

In addition, customers can simultaneously enjoy improved performance and lower TCO, while retaining the 24/7 enterprise quality support that IT organizations supporting high criticality applications pay a premium for.

Citing Gartner, Altibase has among the highest customer satisfaction rates in the industry for operational DBMSs.  That is a testament to our dedication to our customers and the quality of our product.  Another commonly overlooked reason is our willingness to tell prospects when we aren’t the best fit for their use case.

Clients are often shocked when we end up recommending a competitor’s product over our own after discussing their requirements.  Often, this creates an amusing role reversal where potential clients try to convince us why they think Altibase will work for them!

Ultimately, we aren’t in the business of selling databases.  We are in the business of solving problems.  We believe that this attitude and business model has been the greatest contributor to our rapid growth and success.

 

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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