在四月份的Percona Live MySQL會議上， TokuDB慶祝自己成為開源存儲引擎整一周年。我現在仍能記得一年前它剛創建時的官方聲明與對它的期望。當時的情況非常有意思，因為它擁有幫助MySQL管理大數據的潛力，而這是InnoDB無法做到的。TokuDB還有一些有意思的特性，比如”熱模式轉換（hot schema changes）”，可以使我們昂貴的閃存能夠持續更長時間。
盡管在過去這一年里，我一直在關注TokuDB的發展，但我一直認為我不會去嘗試使用它。直到最近，Percona Server發布了支持TokuDB插件的beta版本，我才覺得值得一試。
如果你還沒有嘗試過TokuDB，現在就是一個機會。首先我將介紹TokuDB是如何與MySQL協同工作的。
大家都知道，MySQL的核心在於存儲引擎。InnoDB已經完全改變了MySQL，不僅讓MySQL支持事務處理，並讓整個系統變得更加成熟和穩定。即使是那些並不是事務特性的應用使用InnoDB也自得其樂。但是你是否記得不久之前InnoDB也是第三方專有插件呢?首先你需要將它與MySQL進行編譯。然后將能夠很容易的將該插件安裝或者下載到已存在的服務器中。但是當InnoDB開源之后，一切就變得繁榮昌盛起來：人們越來越能接受它，而且慢慢地，它走上了正軌，得到了人們的推廣。任何一個人都能閱讀、修復、擴展它的編碼，很多公司提交自己的修改融入其中，讓InnoDB變得更好，直到它成為MySQL的首屈一指的存儲引擎。
平衡大數據與存儲成本
目前來看，與類似的MyISAM表相比，數據存（即使是壓縮存儲）到一個InnoDB表中需要的磁盤空間的確要更大，但是沒有人會認為在一項新技術發展過程中不會出現缺點和不足。同時，磁盤的存儲能力也在增強，這也有助於平衡每字節的價格，而且也能補償InnoDB的空間需求。
但是磁盤容量的增加也對“什么值得存儲”的界限進行了擴展。曾經的GB級磁盤既是近乎無限的存儲空間，到如今已經成為有限，而TB級的磁盤成為了標配和基本需求。同時，盡管有大量有意思的東西可以瀏覽和探索，人們的注意力開始渙散，之前能夠牢牢抓住現在卻常常難以吸引眼球。如今，如果一個網站需要數秒才能進入，那么有些人就可能會失去興趣。
SSD磁盤開始進行挽救這種情況，只需普通機械磁盤耗時的一小部分便能訪問到數據。然而SSD在容量的擴展性卻不太好：每字節成本的增加是跟與數據獲取速度成比例的，而且SSD的壽命（或稱持久性）不是很好，這是一筆昂貴的支出。需要明智地使用SSD。
基於這個原因，現在人們逐漸開始采用混合使用的方式，用快速、昂貴的SSD磁盤存儲“熱”的數據，將更慢一些、便宜一些的機械磁盤存儲其他所有的數據。當然，這只是一種短期內可使用的方案，因為這難以維護，並要求大量專業人才去決定每一種磁盤存儲哪種數據。長期來看作為一種較為便宜的存儲，可以預測基於SSD的方案將發展的更好。但是，在此之前，還是很有必要在大數據與硬件投資之間做出權衡，做合乎兩方的選擇。
TokuDB的前提
解決這個問題還有一個辦法，就是轉變邏輯。如果能夠在同樣大小的磁盤容量中儲存更多數據，而且能夠存儲、讀取的更快，那么我們就可能得到更好的結果（從性能方面來講）並獲得存儲投資帶來的更好回報。這就是在TokuDB存儲引擎發展過程中，Tokutek要達到的目標。它架構的核心基於一個不同的、現代的檢索方法，名為分形樹索引（FTI，Fractal Tree Indexes）。我所說的“不同”在於，大部分流行的存儲引擎，比如MyISAM 、 InnoDB，都是基於B樹索引。在過去至少30年內，該索引都保持着，作為某種無法挑戰的標准。我所說的“現代”，是因為FTI的設計考慮到了寫-密集型操作（這種操作在現在的數據系統中出現的越來越頻繁）以及最新存儲設備易損耗的特性。
兩種數據結構都是基於樹的，類似地在葉節點中存數數據，並且利用索引Key值加速排序。但是它們通過樹來管理與存儲數據的方法是不同的。TokuDB以及它的分形樹索引與基於B樹的InnoDB相比，使用的塊大小更大（更大的葉子節點），進而數據能夠得到更好的壓縮（使用更小磁盤空間的關鍵技術），也提高了范圍查詢的性能。同樣重要的是，TokuDB稱能夠通過一個消息傳遞系統與“優化的”緩存機制來更好的利用I/O。
盡管在基於傳統B樹的系統中，對表的一個改變會觸發索引的相應更新，TokuDB最初會將每一個改變都當做一條消息。有意思的是，在消息到達相應的葉子節點並作出修改之前，它所帶來的改變就已經存在於數據庫中了。於是，數據庫的內容則是葉子節點中存儲的數據加上消息循環中的數據。這使存儲引擎更加敏捷，舉例來說，這會在熱模式轉換（Hot Schema Changes）中發揮重要的作用。
對於優化的I/O緩存系統的讀操作，與更大的葉子節點的使用有關。或者如果你願意的話，也有另外的方法：更有效的方法來使用緩存，使得更大的葉子節點的使用成為可能。這里提到的有效主要指的是帶寬使用程度。需謹記，從消耗的時間來看，對磁盤的I/O遠大於對內存的I/O;這就是使用緩存的原因——更頻繁的將數據儲存於緩沖中（低消耗），就可以減少將緩存“刷到”磁盤的頻率（高消耗）。刷到磁盤的緩沖區越滿，可以達到的帶寬利用率越高。TokuDB試圖最大限度的利用緩存，即“對單個I/O進行成千上萬次操作”。B樹的問題是因為設計的原因，它很難實現一個有效的緩存系統，而人們經常習慣將不太滿的緩存刷到磁盤。因此，對於B樹來說，更好的方法是在B樹中維持小一些的葉子節點，這樣產生的副作用是使壓縮變差。Tokutek的工程負責人Tim Callaghan 11月份時在Percona Live London解釋了對比的各種不同，比我解釋的要好得多，
優化使用I/O，使得寫操作密集型應用受益良多。目前在我們的Percona Cloud Tools （PCT）中使用TokuDB，用來存儲和分析來自MySQL服務器的查詢日志。選擇TokuDB作為PCT存儲設備的另一個好處是壓縮性能更好，如果沒有這個的話，在PCT服務beta階段，我們會在支持的用戶數上受到很多限制。壓縮的影響究竟有多大?就像MySQL中的其他事情一樣，這取決於你的模式。據Shlomi Noach報導，他能夠把未壓縮的InnoDB引擎的4TB數據（或者是使用KEY_BLOCK_SIZE=8壓縮的InnoDB引擎的2TB數據）壓縮到200GB。這樣能夠給大家一個感性的認識。
壓縮本身就是TokuDB一個很吸引人的特性，但是對於存儲空間的大小不是問題的應用場景，這個存儲引擎也做的不錯。對於寫（INSERT）性能而並非網絡是性能瓶頸的場景來說，對I/O的優化能夠延遲副本操作。如果你需要對一個大表添加一列或者添加第二索引，“熱模式轉換”功能將助力不少。對於閃存磁盤的持久性也有不少重要影響。Mark Callaghan對於之前的文章做過以下評論：“與InnoDB相比，全磁盤服務器使用TokuDB支持更大的負載壓力，全閃存的服務器使用TokuDB是通用的——2倍以上的壓縮率（與InnoDB的壓縮相比）以及批量的寫操作（更多是順序寫）意味着你你可以買更少的閃存、這些閃存可以用更久、買更為廉價的緩存也能夠用”。另外，不要忘了TokuDB中讓Vadim最賞心悅目的一個特性：支持使用SHOW PROCESSLIST跟蹤查詢的實時進展。
展望
Tokutek擅長打破傳統，並從其他角度出發找到了TokuDB發展中的問題。它受益於MySQL的開放性，使用它的引擎API實現了一個完全不同的方案，該方案脫胎於對現實的深思熟慮——更快的多核CPU、現代卻又“脆弱”的存儲設備以及對“大數據”的渴望。當然，它也受益於對基於B樹的存儲引擎的觀察，該引擎在過去數十年內處理了不斷進化的數據，伴隨着新方法和新算法到來，一直讓事情變得更加簡單。與InnoDB相比，TokuDB更容易進行調優：我統計過共有40個“tokudb_”變量，而“innodb_”有超過100個。但是這還需要時間的考驗。盡管我們並不是在討論一個嶄新的引擎（Vadim在5年前就記錄過他對該引擎的使用經歷），但該引擎最近變成了開源的、公共的，並處於初始階段。盡管在穩步發展，我們也還是能看到很多未解決的bug。
令人擔憂的是目前並沒有支持TokuDB的開源熱備份軟件。盡管有一個“可插拔備份工具標准”在GitHub上提供有HotBackup的API，而目前唯一一個可能存在的熱備份方案存在於TokuDB的企業版本中。TokuDB的設計並不適用於“拷貝數據庫文件、然后在把存有數據庫變化的日志應用到文件上”這樣的備份方案，而這正是MySQL Enterprise Backup及Xtrabackup的工作方式，所以現在仍然沒有希望，簡單擴展一個已存在的開源軟件來就可以支持TokuDB，如Percona XtraBackup 之類的軟件。
我們將充滿希望的看到一個新的開源備份軟件到來，它將在不久的未來使用對外的API來實現，但是現在看來多數軟件還是基於快照的工具，停留在文件系統水平，如mylvmbackup和 xfs_freeze，它們可以暫時作為未來新方法的替代方案。