Falcon from the

Beginning

Presented by,
MySQL & O’Reilly Media, Inc.

Jim Starkey
jstarkey@mysql.com
Why Falcon?
Because the World is Changing!

 Hardware is evolving rapidly

 Customers need ACID transactions
Atomic – the books should balance
Consistent – the alternative is chaos
Isolated – preserve programmer’s sanity(sic)
Durable – who wants to lose data?
Where Hardware is going
 CPUs breed like rabbits – more sockets, more
cores per socket, more threads per core
 Memory is bigger, faster, and cheaper
 Disks are bigger and cheaper but not much
faster
 (Boxes are cheaper and more plentiful, but
that’s a different story)
Where Applications are going

 Batch – dead!
 Timesharing – dead!
 Departmental computing – dead!
 Client server – fading fast
 Application servers for most of us
 Web services for the really big guys
The Database challenge

 Traditional challenge:
Exhaust CPU, memory, and disk simultaneously

 Today’s challenge:
Exhaust CPU and memory and avoid the disk
Falcon tradeoffs
 Use memory (page cache) to avoid disk reads
 Use memory (record cache) to avoid the page
cache manipulation.
 Use CPU to find the fastest path to a record
 Use CPU to minimize record size
 Synchronize most data structures with user
mode read/write locks
 Synchronize high contention data structures
with interlocked instructions.
The Falcon architecture

 Incomplete in-memory database with disk

backfill
 Multi-version concurrency control in memory
 Updates in memory until commit
 Group commits to a single serial log write
 Post-commit multi-threaded pipe line to move
updates to disk
Incomplete in-memory database

 Selected records cached in memory

 Separate cache for disk pages
 Record cache hit is 15% the cost of a page
cache hit
 Record cache is more memory efficient than
page cache
Record Encoding - Cache Efficiency

 Records encoded by value, not declaration

 String “abc” occupies the same space in
varchar(3) or varchar(4096)
 The number 7 is the same where small,
medium, int, bigint, decimal, or numeric
Multi-Version Concurrency Control
 Update operations create new record versions
 New version is tagged with transaction id, points
to old version
 System tracks which transactions should see
which versions
 Readers don’t block writers
 Everyone sees a consistent view of the data
Updates Are in Memory Until
Commit

 Updates held in memory pending commit (well,

usually)
 Index changes held in memory pending commit
(same caveat)
 Verb rollback is dirt cheap
 Transaction rollback is dirt cheap
At Commit…

 Pending record updates flushed to serial log

 Pending index updates flushed to serial log
 Commit record written to serial log
 Serial log flushed to the oxide
 And the transaction is committed!
Alas, Memory isn’t infinite, so
 Large transaction chills uncommitted data
(flushes it to the log early)
 Chilled records can be thawed (fetched from the
log)
 Scavenger garbage collects unloved records
periodically
 When things get really bad, entire record chains
flushed to backlog
 (Note: This is hard and we aren’t done.)
Falcon Weaknesses

 Transactions are ACID but not serializable

 Latency advantage disappears at saturation
 Very large transactions degrade performance
 Optimized for Web, not batch
Falcon Strengths

 Runs like a memory database when data fits in

cache
 Scales like disk-based database when data
doesn’t fit in cache
 Lowest possible latency for Web applications
 Absorbs huge spiky loads
Performance Measurement
 Generally benchmark against InnoDB
(transactional engines)
 We use the DBT2 benchmark:
High contention
Write intensive – 40% records touched are
updated
Measures only performance at saturation
 DBT2 (we believe) is InnoDB’s best spot and
Falcon’s worst
Benchmarking Results
 16 & 8 cpu system: Falcon exceeds InnoDB
performance
 4 cpu systems: Falcon exceeds InnoDB performance for
moderate to large number of threads
 2 cpu systems: Rough parity, advantage to InnoDB
 1 cpu systems: InnoDB wins
 Caveat: Results subject to change! Both systems are
moving targets!!!
When should you use what?
 If you don’t need ACID, MyISAM is probably
fastest
 For Uniprocessors and small memory systems,
InnoDB is a good choice
 For large transaction batch, InnoDB may be
best match
 For multi-cores and large number of threads,
Falcon is probably best
 For the Web, Falcon is hard to beat.
 Questions?