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