My comments on this post.

1) PBXT: “Never update the row” as far as I understand really applies to “Variable length” row portion - the fixed length portion still needs to be updated to link to link to previous row version. I think the assumption in PBXT is to have fixed row portion small and so this file fits in memory. In general PBXT seems to be very optimized for Blobs handling and handling long rows in general. Also worth to note currently PBXT really treats different databases as different instances which can cause many gotchas if you have transactions spawning multiple databases both for Commit and for sake of Repeatable Reads isolation mode.

2) Falcon. It is worth to note MySQL official marketing never position MySQL as such per say (for obvious reasons) but it is indeed set as replacement for Innodb in many users mind. Visiting customers I often hear the question of when they should migrate to Falcon and which benefits they will get. I surely tell them it is too early to migrate and too early to say because Falcon is in aggressive development. Due to very different concepts both in terms of performance properties and transaction implementation details Falcon is unlikely to be easy drop-in replacement for Innodb but for certain applications especially newly designed ones it offers some attractive features. I however agree the lack of clustering by primary key support and not being able to use covering indexes means there is no way to get predictable data locality which is extremely important for large databases.

3) Solid - this one is actually better positioned as “Innodb Replacement” as it has much more close architecture and applications may be easy to port if performance will be adequate. Solid also has clustering by primary key and unlike Innodb has key compression (one of major Innodb problems in my opinion). The problems with Solid based on listening their talk may be handling of long transactions (spilling bonsai tree to the disk may not be that efficient) and writing new pages to new locations which is likely to cause significant problems.

Comparing Transactional storage engines though one need to take into account a lot of variables - how stable is engine and integration (the last thing you want is loosing your data - it is worse than crashes or wrong query results). Crash recovery reliability and speed, including rare cases such as partial page writes etc. This is where knowledge just will need to be accumulated.

It is worth noticing different storage engines and features have various levels of readiness, if as I understand ScaleDB is not publicly available yet. It is also worth noticing MySQL world is not free (as in beer) any more. Solids synchronous replication offering may be commercial only (It does not say on web site exactly yet) - NitroDB and Infobright are very special storage engines and not surprisingly commercial. Plus Infobright one is currently Windows only and ReadOnly (special loader-compressor must be used) as I understand.

P.S For Planet MySQL users who may think why Peter is Commenting Peter - original post was made by Vadim - number of people write to MySQLPerformanceBlog these days but it is all showing up under Peter Zaitsev in planet MySQL.

Yes thank your for your comment. I well understand implications and design choices you made.

This however lives Falcon in very interesting position. For small data sets when data mostly fits in memory fact Falcon does not have clustering by primary key and covering indexes is not critical because it does not require a lot of random IO. But in the same case the fact indexes are a bit longer does not give much problems, also the fact Innodb has to cache full pages not individual rows does not bother you too much. Also optimized index retrieval does not really matter if data is in memory.

So this leaves rather narrow range for working set to memory ratio when Falcon optimizations will allow it to excel. Ie Assume we have 16GB of memory and 10GB Innodb database which will be 7GB in Falcon (for example) and we assume working set matches database size for sake of argument.

In case you get ie 20GB in Innodb and 14GB in falcon or 30GB in Innodb and 21GB in Falcon we can see the difference but when we get to 100GB Innodb vs 70GB of Falcon the lack of clustered key and covering index may show serious problems.

Again these are my assumptions so far - the live will show us how it really is.

I think you widely underestimate amount if cases when covering index is a life saver.

So, queries like:

select name from people where name = ‘Ann’

require actually reading the records in people that are indexed
under ‘Ann’ to see if I might have changed my name to ‘Her Most
Exalted Majesty’. There are real cases where resolving from the
index is a good thing - joins with junction tables for one - e.g.
students / registrations / courses where the registration record
consists only of the student_id and the course_id. Not reading
those records is a good thing.

However, the choice that Falcon made was to have smaller, faster,
lower-maintenance indexes. That’s also the choice that InterBase,
Firebird, and Postgres made. I’ve seen benchmarks where they do
well, and others where they don’t. Personally, I prefer that
indexes work better in the general case, even if it costs in this
case, but YMMV.