Choosing the Right Database The Case for OpenBase SQL

 

Choosing the Right Database: OpenBase SQL

 

 

 

 

 

 

 

 

 

 

 

Choosing the Right Database

 

The Case for OpenBase SQL

 

 

 

What are you looking for in a database? Reliability? Performance? Ease-of-use? A proven track record? An affordable price? Low cost-of-ownership?

 

 

This paper provides guidance on what features and “gotchas” to look for when choosing a database and database vendor.

 

It also describes the advantages offered by the OpenBase SQL relational database and how it compares to other database offerings.

 

 

 

The ACID Test

 

A.C.I.D. stands for Atomicity, Consistency, Isolation and Durability – four standards which every database should meet, but few actually do.

 

While A.C.I.D. compliance is not the only consideration in choosing a database, it‘s a good place to start in comparing your database choices.

 

Here is a quick definition of each term:

 

<!--[if !supportLists]-->§       <!--[endif]-->Atomicity – All database modifications must follow an “all or nothing” rule in which each transaction is “atomic.” That means that if one part of the transaction fails, the entire transaction fails. No splitting of atoms allowed! It is critical that the database management system maintain the atomic nature of transactions in spite of any DBMS, operating system or hardware failure.

 

<!--[if !supportLists]-->§       <!--[endif]-->Consistency – Only valid data is written to the database. If, for some reason, a transaction is executed that violates the database’s consistency rules, the entire transaction will be rolled back and the database will be restored to a state consistent with its rules. Transactions that successfully execute always take the database from one state that is consistent with the rules to another state that is also consistent with the rules.

 

<!--[if !supportLists]-->§       <!--[endif]-->Isolation – Multiple transactions occurring at the same time will not impact each other’s execution. For example, if Joe issues a transaction against a database at the same time that Mary issues a transaction, both transactions will operate on the database in an

Choosing the Right Database: OpenBase SQL

 

 

isolated manner. That is, the database either performs Joe’s entire transaction before executing Mary’s, or vice-versa. This prevents either transaction from reading intermediate data produced as a side -effect of part of the other’s transaction that will, in the end, not actually be committed to the database.

 

<!--[if !supportLists]-->§       <!--[endif]-->Durability – Transactions committed to the database are never lost. Durability is ensured through the use of database transaction logs that facilitate the restoration of committed transactions in spite of any subsequent software or hardware failures.

 

Databases with A.C.I.D. Compliance

 

Complete A.C.I.D. compliance is actually relatively rare among the database offerings on the market.

 

Sybase, Oracle, Postgres and OpenBase SQL have solid strategies for fully complying in all four A.C.I.D. areas; SQLite and MySQL do not. And, since Real SQL Server is based on SQLite, it also does not fully comply.

 

 

 

Fault Tolerance and Durability

 

Choosing a product with a built-in and automated capability for avoiding data -loss is critical, both in preventing the costs of data loss and in lowering the costs of running the database.

 

Most databases lack durability primarily because they have no effective strategy for dealing with random access files, in which corruption can sometimes be unavoidable.

 

In fact, file corruption happens more frequently than most operating system vendors would like you to know. The sophisticated caching in today’s modern operating systems and hardware enhances performance, but it also compounds the challenge of designing reliable databases.

 

The most common cause of file corruption is an unexpected shutdown or a system freeze-up. Database systems are more prone to failure under these circumstances, because they write to disk more frequently than most other applications. If a write is interrupted by a power outage or system crash, it can result in a corrupt write or even a truncated file. A partial write or a truncated file can be devastating to your company data.

 

Hard disk RAID alone cannot solve the problem. While RAID does guard against a complete hard drive failure, RAID often just duplicates corrupted data — giving database owners a false sense of security.

 

Good database durability starts with the assumption that random access files will be corrupted; and that, when they do, the database software needs to be able to detect problems and take action to guarantee that files can be accurately rebuilt.

 

OpenBase SQL does this automatically. Sybase and Oracle require a database administrator to monitor the database. Other databases, including MySQL and SQLite, are missing this level of fault-tolerance entirely.

 

OpenBase SQL Journaling   Keeping data safe

 

OpenBase SQL employs a multi-file journaling system that delivers reliability through a foolproof mechanism for addressing the common forms of file corruption.

 

Here’s how it works: OpenBase SQL simultaneously maintains both a master and working copy of database data, along with a realtime journal, which tracks all changes. Changes are

Choosing the Right Database: OpenBase SQL

 

 

flushed to the journal as transactions commit, followed soon thereafter by batched flushing of changes to the working random access files.

 

Since an incomplete write can corrupt random access files, OpenBase SQL uses the journal as a safeguard to ensure that, if file corruption occurs, the random access files can be completely rebuilt from scratch

 

In the case where a database needs to be rebuilt, OpenBase SQL combines the master copy with the transaction journal to bring the database back to its most recent state. In this way, OpenBase SQL provides a redundant and automatic system that keeps data safe.

 

In addition to maintaining data integrity, this journaling approach eliminates the need to perform many random access writes at commit time. Instead, changes to the work files can be safely batched, resulting in significantly faster database performance.

 

OpenBase SQL databases perform journaling tasks transparently and automatically.

 

How do other databases compare?

 

While there are a variety of approaches to the problem of avoiding data corruption, many are flawed or require intervention from a database administrator — both of which can be costly.

 

Sybase and Oracle use a journaling mechanism similar to OpenBase to ensure data integrity. However, they also require a database administrator (DBA) to periodically empty journal files and increase database partitions as needed. That’s because the journal files used by Oracle and Sybase are fixed in size and cannot grow without intervention. When the space fills up, the databases stop working until someone services it. While this may be acceptable for companies with their own in-house database administrator, it is not a realistic option for businesses with applications requiring turn-key and unattended database operation.

 

At the other end of the spectrum are open source databases. MySQL was originally designed without any mechanism to prevent or correct data corruption due to operating system failures. But as customers began to lose data as well as their confidence in MySQL file mirroring was added. While mirroring provides backup benefits similar to soft-RAID, it also significantly degrades performance. And while mirroring reduces the chance of file corruption, it does not eliminate it entirely, because random access files, which are prone to corruption, are still used for the mirrored copies. Database clustering, where databases are clustered between two servers, appears to be the only option for MySQL users requiring real durability. But with a price tag of $13,000 for MySQL clustering software, fixing the shortcomings of MySQL may not be an affordable option.

 

Postgres has added a write-ahead log to address reliability issues. It operates on the same principle as a journal, except that the log is written before SQL is evaluated, rather than as the transaction commits.

 

SQLite is a free, open-source database, which lacks most of the features of a relational database, including protections against data loss. Even so, it is widely used for applications that do not require reliability. If you choose this database product, keep frequent backups. There is no durability built into SQLite.

 

In an effort to add some durability to SQLite, Real SQL Server now offers an SQL log so that the database can be restored from a backup if the main files become corrupt.

 

FileMaker does not have any type of log or journaling and is prone to file corruption. Loss of data is a frequently heard complaint from FileMaker users.