MySQL Falcon Storage EngineとJimおじさん

スウェーデンのビール Falconをプロジェクタの周りに並べるJimおじさん

積まれたビールと写真を撮る人の手

最後のQAで質問した人に一本ずつあげるよ、ってことだったのですが、途中で怠慢なMySQLの人間が配布するのをやめてしまったので、余ったビールは適当に持って帰って良いことに。
一本ゲットしてきました。

詳細はこちらを参照のこと。
So-net blog:今度はどこ行く？:注目のMySQLの最新ストレージエンジン Falc..

そして、速記。MediaWiki用にMediaWiki文法のまま。
==falcon==

*second, what falcon is not
**an innodb clone
**firevird
**a firefird clone
**a standalone dbms
**netfrastructure

changes since the dawn of the rdmbs
uarly 1980s

*falcon
the engine design ofor the next 20 years

goal
exploin large memory for more than just a bigger cache
use threads and processors for data migration
design to eliminate tradeoffs, minimize tuning
scale gracefully to very heavy loads

*falcon archetecture overview
**Basic model
incomplete in-memory db with backfill from disk
**two caches
traditional LRU page chache for disk
larger row cache with age group scavenging
**serial log for single write group commits

**multi-version in memory, singl eversion on disk
**all transaction state in memory with automatic overflow to disk
**data and indexes are single file plus log files
**future: blog repositories
**future: multiple gape spaces

*falcon implementation: concurrency control

**basic model is multi gen concurrency control (MVCC)
**will be extended fo relaxed consisteyncy but we don't approve
**will be extended for a serizlizable mode

*:indexes

btree index with prefix frompression
no data (except key) in index
two-stage index retrievals

index scan generates row bitmap
records are fetched from disk in physical row order

no performance difference bw primary, secondary indexes

scan bitmaps can be combined for multi index retrieval

*:data flow

**uncommitted row data is staged in memory (may overflow to scratch file)
indexes are updated immediately

**on commit, row data is copied to the serial log and written
**post commit, dedicated thread copies row data from serial log to data pages
**page cache is periodically flushed to disk
**blob data is queued for write at blob creation, backed out on rollback

*:data reliability

**physical structure protected by careful write

database on disk is alwasy valid, always consistent
simple rule, a page is written before a pointer to it

**atomicity protected by serial log

a transaction is committed when the commit record hits the oxide

**serial log is;
a do log for post commit data migration
a redo log for post-crash recovery of data
an undo log for post crash resource recovery

*my secret agenda
**replace varchar with string(forget the length)
**replace tiny, small, medium, and big integers with number
**adopt a secutiry model useful for appliation servers
**introduce useable row level security(filter sets)
**teach the database world the merits of hree context search(everyone else already knows)