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