海量數據存儲之動態Schema的傳說
簡介
眾所周知，對于海量數據的schema修改是一個極其昂貴的代價，MySQL分表的很大原因其實就有500w數據一個表，DDL會比較快。
一般來說，動態schema是指的非固定表結構，schema字段(有時也指索引)的增刪對于正常的讀寫沒有任何影響。一般有兩個方向的表現形式：
Online Schema Change
Schema-Free
NoSQL中一般采用后者，而關系型數據庫可能會采用前者，兩者的區別是，前者雖然是固定表結構，但是可以通過一定的方式進行在線修改，同時盡可能不影響服務，而后者是原生支持動態schema，是很多NoSQL產品所支持的feature之一，也是它們之于開源關系型數據庫的優勢所在。下面我將就目前比較通用的動態schema解決方案就一一介紹。
OSC
OSC即Online Schema Change，是Facebook出的一個在線修改Schema的PHP腳本，它解決了MySQL長期以來無法在線進行Schema變更的一大難題，也成功將Facebook曾經添加一個索引需要幾個月的滾動升級，變成了現在的幾天。
OSC目前包含以下幾個步驟：
copy:制造一個表的副本
build:在副本上進行修改，直到它滿足新的schema
replay:將原始表的變更傳播到副本上
cut-over:切換原始表和副本，這需要極短時間的downtime，同時還需要一次replay操作
看到這個步驟，或許很多人都覺得簡單，其實實踐過程還是比較復雜的，有興趣的人可以去看看，這里不做過多介紹。
http://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932
總之，對于關系型數據庫來說一般都是采用的Online Schema Change這種解決方案，商業數據庫Oracle和DB2都有比較和諧的Online Schema Change解決方案，但是考慮到其成本，這里不做過多介紹了。
優點：在線變更，無額外空間消耗
Schema-free
一般來說，文檔數據庫(Document-orient Database)支持Schema-Free，就mongodb來說，它的一行記錄可能是以下格式：
Xml代碼
- {name:"mongo",type:"db","x" : 4, "j" : 1}
嚴格來說其實就是JSON，不過mongo采用的是BSON二進制編碼，因此空間上來說應該會比JSON省一些的。
因此，對于這種類型的動態schema方式來說，實際是使用key/value存儲的，一條記錄的多個字段實際是用json方式合并存在value中。解析的時候按照JSON解析即可，不好的地方是有額外的空間消耗，也許有點人覺得把字段名取為一個字母，但是這樣可讀性就太差了。
優點：完全的schema-free，無需任何改變，適用于及其復雜多變的業務。
Any More?
這里補充一點，看到有朋友對于此實現有疑問，這里所說的schema-less是針對的key-value存儲，不針對mysql數據庫，
MySQL還是建議使用OSC。
看完前面的兩種解決方案，很多人或許就會覺得，是不是NoSQL鼓吹的動態Schema就是一個笑話呢?把字段存到數據庫里面，誰都可以做啊，其實不然，讓我們看看另外一個解決方案。這個方案好不好，大家看完后評價。
舉例說明，對于下面一個Schema:
我們對于這樣一個Schema，其元數據信息應該是什么樣的呢?
首先對于我們的元數據做如下定義：
這里的這個元數據信息是對于某一個schema來說的，依次是一個SchemaId，然后是Name(可以理解為表名)，然后是當前schema的代數，其實就是一個類似于版本的東西，初始為0，最后一個是創建或修改時間，還有一些其它信息，這里省略掉。
下面是對于字段的一些元數據，兩者通過SchemaId關聯，包含了所對應的Schema，在schema中的順序(解析的時候用)，類型，是否為空，是否為主鍵啊之類的。
我們有了這些元數據信息以后可以做什么呢?
對于我們的一行記錄，我們理解為一串二進制字節碼，如何從這串字節碼中解析我們的字段呢，依靠的就是這些元數據，下面我將物理上存儲的格式貼出來，大家就明白了：
大家注意看，物理上我們存儲了一個Generation字段來標識當前的Schema是屬于該schema的哪個特點的版本。那么根據這個Generation以及這個表名(即StoreName)我們就可以得出一個SchemaId，根據這個SchemaId我們可以得到有序的該Schema的所有字段，那么剩下的就很easy了，如果對于二進制編碼不太熟悉的，請看看Protocol Buffer
好了，那么我們如果想增加一個字段呢?需要做的僅僅是修改元信息，將新的Schema信息存入上面兩個元數據，如果想讀取原有的老數據，那么根據generation進行相關解析即可，如果插入新的Schema的數據，使用最新的generation就可以了，一切都非常完美。這個generation字段還可以使用壓縮編碼的方式，在generation小于128的時候，我們只需要1個字節的額外空間消耗
優點：無需額外空間消耗，無需在線修改，透明的使用，幾乎無downtime
缺點：如果增加字段，原有老數據的格式仍然是默認值，但我想這一點大部分人都可以將其忽略
總結
上面基本上是目前動態schema的主要實現方法，如果大家有新的解決方案，請告訴我。
歡迎大家交流討論。
【編輯推薦】
