Falcon Transactional Characteristics

It’s time to continue our series on the transactional storage engines for MySQL. Some might question why I even include Falcon because it is very much beta at this time. MySQL, however, has made quite an investment into Falcon, and while it is currently beta, the code is improving and it looks like that it will be production-worthy when MySQL server 6.0 hits GA.

If this is the case, it is important to begin to understand what Falcon was designed for and how it differs from other transactional engines such as InnoDB. I am going to concentrate quite a bit on the Falcon/InnoDB comparison as that is what everyone wants to talk about. This is despite my having heard MySQL employees repeatedly make statements to the effect of, “Falcon is not going to replace InnoDB,” or “Falcon is not competing with InnoDB.” Well, take that with a grain of salt. It certainly seems to me that they are competing for the same spot.

Warning

As I said, Falcon is beta. First off, don’t even try to use it in production. Using it in production means you will also be using MySQL Server 6.0, which itself is considered alpha. Your data will explode, be corrupted, or eaten by jackals. It won’t be pretty. It will cause great pain.

In addition, the features of Falcon are still changing. What I say here might or might not be accurate in the future.
End of Warning

So, why was Falcon even created?

Falcon has been specially developed for systems that are able to support large memory architectures and multi-threaded or multi-core CPU environments. While it performs optimally on 64-bit architectures it can also be deployed on 32-bit platforms. A CPU count of up to eight cores and eight gigs is the current “sweet spot”.

Whenever I hear MySQL engineers talk about Falcon, they emphasize this idea that Falcon was created from the ground up for multiple core CPUs and large amounts of RAM. This is in contrast to InnoDB, which was created at a time when servers had very small amounts of RAM and CPU power compared to modern servers.

And there are definitely some benefits to a “new start” as opposed to building on old technology. As an example, consider what Apple did with the Macintosh operating system when they moved to a completely new technology platform — they created OS X. This allowed Apple to create an operating system which performs better on today’s modern hardware.

In InnoDB’s defense (if it needs any), it has aged fairly gracefully, in my opinion. Scaling beyond four cores, however, has been a sore point for some time. Recent work by a Google engineer group (headed by Mark Callaghan) has led to patches being accepted into the InnoDB codebase that allow for almost linear scaling of InnoDB on up to eight cores. In addition, there is work being done on the memory issues to allow InnoDB to use up to 128 GB of RAM.

If you are looking at Falcon and InnoDB from a CPU and memory usage/optimization point of view, they are currently fairly even in comparison. I think competition brings out the best, so this is a good thing all around.

Here are the key features of Falcon (from MySQL.com’s Falcon documentation):

True Multi-Version Concurrency Control (MVCC) enables records and tables to be updated without the overhead associated with row-level locking mechanisms. The MVCC implementation virtually eliminates the need to lock tables or rows during the update process.

Data and index caching provides quick access to data without the requirement to load index data from disk.

Implicit savepoints ensure data integrity during transactions

Some of above features are similar to InnoDB’s features. For example, InnoDB is fully transaction-safe and can handle multiple concurrent transactions. And I think it could be easily argued that InnoDB, like Falcon,Â is now optimized for modern CPUs and supports multiple threading. As I noted earlier, however, this is something that has changed rather recently.

There are some definite differences in features also.Â For example, while InnoDB and Falcon both use B-tree indexes the InnoDB implementation always reads in physical disk order when using the B-tree index.Â This minimizes I/O response time. Falcon does not do this. Another difference is that Falcon does not support Read Uncommitted isolation level. Read Uncommitted (sometimes referred to as “dirty” reads) is not needed for most situations. To me, this is a definite plus for Falcon. I don’t think dirty reads should even be an option for a database.

One of the big center points of Falcon is that it implements MVCC differently than InnoDB. InnoDB uses row-level locking for transactions while Falcon “almost never” locks either tables or rows. The idea is that this should generate less overhead (row-level locking takes memory and CPU resources).

Falcon is multi-version in memory and single-version on disk, True Multi Version Concurrency Control (MVCC) enables records and tables to be updated without the overhead associated with row-level locking mechanisms. The MVCC implementation virtually eliminates the need to lock tables or rows during the update process, also data and index caching provides quick access to data without the requirement to load index data from disk.

You can see how the larger server RAM amounts would be good for this setup. The amount of RAM and the CPU core count will only continue to rise so in my opinion this is a good path for Falcon to be going “down”.

Currently (although I understand this will change) Falcon does not support statement-based replication. Starting in version MySQL 5.1, both statement-based and row-based replication are supported for binary logging.

Statement-based replication is based on sending all the queries run on a maser server to the slave server and re-executing them on the slave. For row-based replication, only the results of the queries are going to be sent from master to slave.

Falcon supports only row-based replication. This is to guarantee consistent results between binary log and data files. It’s going to be a major point of contention for many administrators. We love our statement-based replication. However, there are real benefits for row-based replication. Ever watch your slave get 1,000 seconds behind the master while it is working on a single query that ends up returning 20 updated rows? With row-based replication, that same result would happen in less than a second as it essentially sends the changed rows and not the query itself.

A unique feature of Falcon is the on-the-fly data compression/decompression when reading and writing to the database. Â Essentially, when you update your table, it compresses the data as it stores it, with no intervention from you. As you read from the table, an automatic decompression takes place. Similarly to a compressed MyISAM table, but you can both read and write to the table. The storage space savings for large databases will be nice. From what I understand there are performance benefits to this also.

I hope this has been a useful overview for what is coming from the Falcon storage engine. I didn’t go into the online backup capabilities of Falcon as those are really more of a MySQL Server 6.0 feature than a Falcon one. Even so, there is work being done to integrate Falcon with online backup so that these backups will work optimally.

The architecture of InnoDB is incredibly sound, and has been proven through years of experience at 1000s and 1000s of customer sites. It will naturally take years for Falcon to prove itself in this way. No doubt we will see more comparisons like this as Falcon (and MySQL 6.0) approach GA. But it is important that such comparisons be complete.

So, here I’ll just briefly mention a few important things you didn’t mention (in addition to the fact that InnoDB supports both statement-based and row-based replication, both of which have their place).

InnoDB supports Referential Integrity; Falcon won’t do so until such support is implemented “above” the storage engine in a future release of MySQL.

InnoDB uses “clustered indexes”, where the data is stored in the leaves of the (primary key or clustered) B-Tree index. (This may be what you are alluding to when you say that the data is stored on disk in sorted order, though this is not quite correct, as the index pages themselves may be stored “randomly” on disk.) This data structure supports an important optimization called a “covering index”. InnoDB can often retrieve all of the required data in a single i/o request (if it is not already in memory), since the non-key column values follow the value of the primary key in the clustered index. The novel Falcon “row cache” may or may not hold the required data in memory, thus potentially requiring an extra i/o after the index lookup is performed.

The InnoDB architecture is very closely modeled on the foundational work of Jim Gray and Andreas Reuters, as described in “Transaction Processing: Concepts and Techniques”. Heikki Tuuri added some ideas taken from systems like Oracle (“undo or rollback segments” stored in the database) and created some additional very clever optimizations like the adaptive hash index and the insert buffer, which (as far as I understand) have no analogs in Falcon.

Regarding compression, the recently released InnoDB Plugin (see the website: http://www.innodb.com/innodb_plugin/) supports very effective data compression (2:1 or better), and it uniquely compresses both data and indexes. Some early users of compression in the InnoDB Plugin have reported outstanding results: significantly smaller databases and reduced i/o. The InnoDB Plugin introduces several other significant new features, and it works in the context of MySQL 5.1.

As you mention, the multi-core scalability issue may be (close to) being fixed. In general, scalability limitations in well-designed software are often comparable to peeling an onion. Remove one limitation, and another surfaces just below. It’s really not an exaggeration to say that (many of) the limitations of InnoDB’s multi-core scalability are “bugs” or quite simple changes in a few low-level primitives for synchronization, as Mark Callaghan has demonstrated. This is not to say that removing these limitations is simple or easy. Achieving superior scalability is the trickiest part of any system and it is easy to introduce subtle bugs when you are working at that layer of the code.

1) start transaction
2) do a bunch of updates, but don’t lock anything, because that wouldn’t be True MVCC
3) commit — whoops, someone else updated some of that data and committed before I did. Roll back.

I think a lot of the bullet points and phrases you copied from the documentation are only design goals at this point, and have never been substantiated. What would be interesting is to examine Falcon’s true behavior and see if they can be substantiated and really explained. Right now they just sound like “Falcon will magically do everything right.” But even if they’re true, I don’t see the technical explanations of how this is supposed to happen and what the consequences are. The “True MVCC” is just one example of that.

And do these things really work in the real world? That’s another issue. For example — the row cache. It’s supposed to increase cache efficiency, but the people I know who have benchmarked have had to tune it to the point of essentially disabling it to get better performance. In other words, making it behave more like InnoDB.

I always know I am on the right trail when people respond to my posts :).

A couple of points. Not pointing out compression available in the new InnoDB plug-in was a serious oversight on my part. I am going to say I was having a senior moment. Shame on me!!

In retrospect, the idea of comparing Falcon and InnoDB was probably a mistake. My original idea was to have a post about each of the more well known transactional engines pointing out their features/benefits and disadvantages. I am not sure at what point this post turned into Falcon vs InnoDB.

Thanks everyone for the able defense(s) of InnoDB. InnoDB does have a long track record. And there is something to be said for that. I don’t think people will be rushing out to “ALTER TABLE” all their databases after they do get around to upgrading to 6.0. As a database administrator I would not recommend that anyone do that.

I might be optimistic, but I do think that Falcon is going to have a great run and InnoDB is going to be around as a very viable option for a long long time. As I said, competition brings out the best. So, here’s to competition!!