簡介

眾所周知，對于海量數(shù)據(jù)的schema修改是一個極其昂貴的代價，MySQL分表的很大原因其實就有500w數(shù)據(jù)一個表，DDL會比較快。

一般來說，動態(tài)schema是指的非固定表結構，schema字段（有時也指索引）的增刪對于正常的讀寫沒有任何影響。一般有兩個方向的表現(xiàn)形式：

• Online Schema Change
• Schema-Free

NoSQL中一般采用后者，而關系型數(shù)據(jù)庫可能會采用前者，兩者的區(qū)別是，前者雖然是固定表結構，但是可以通過一定的方式進行在線修改，同時盡可能不影響服務，而后者是原生支持動態(tài)schema，是很多NoSQL產(chǎn)品所支持的feature之一，也是它們之于開源關系型數(shù)據(jù)庫的優(yōu)勢所在。下面我將就目前比較通用的動態(tài)schema解決方案就一一介紹。

OSC

OSC即Online Schema Change，是Facebook出的一個在線修改Schema的PHP腳本，它解決了MySQL長期以來無法在線進行Schema變更的一大難題，也成功將Facebook曾經(jīng)添加一個索引需要幾個月的滾動升級，變成了現(xiàn)在的幾天。

OSC目前包含以下幾個步驟：

• copy:制造一個表的副本
• build:在副本上進行修改，直到它滿足新的schema
• replay:將原始表的變更傳播到副本上
• cut-over:切換原始表和副本，這需要極短時間的downtime，同時還需要一次replay操作

看到這個步驟，或許很多人都覺得簡單，其實實踐過程還是比較復雜的，有興趣的人可以去看看，這里不做過多介紹。

http://www./notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932

總之，對于關系型數(shù)據(jù)庫來說一般都是采用的Online Schema Change這種解決方案，商業(yè)數(shù)據(jù)庫Oracle和DB2都有比較和諧的Online Schema Change解決方案，但是考慮到其成本，這里不做過多介紹了。

優(yōu)點：在線變更，無額外空間消耗

Schema-free

一般來說，文檔數(shù)據(jù)庫(Document-orient Database)支持Schema-Free，就mongodb來說，它的一行記錄可能是以下格式：

Xml代碼  

1. {name:"mongo",type:"db","x" : 4, "j" : 1}  

嚴格來說其實就是JSON，不過mongo采用的是BSON二進制編碼，因此空間上來說應該會比JSON省一些的。

因此，對于這種類型的動態(tài)schema方式來說，實際是使用key/value存儲的，一條記錄的多個字段實際是用json方式合并存在value中。解析的時候按照JSON解析即可，不好的地方是有額外的空間消耗，也許有點人覺得把字段名取為一個字母，但是這樣可讀性就太差了。

優(yōu)點：完全的schema-free，無需任何改變，適用于及其復雜多變的業(yè)務。

Any More?

這里補充一點，看到有朋友對于此實現(xiàn)有疑問，這里所說的schema-less是針對的key-value存儲，不針對mysql數(shù)據(jù)庫，

MySQL還是建議使用OSC。

看完前面的兩種解決方案，很多人或許就會覺得，是不是NoSQL鼓吹的動態(tài)Schema就是一個笑話呢？把字段存到數(shù)據(jù)庫里面，誰都可以做啊，其實不然，讓我們看看另外一個解決方案。這個方案好不好，大家看完后評價。

舉例說明，對于下面一個Schema:

我們對于這樣一個Schema，其元數(shù)據(jù)信息應該是什么樣的呢？

首先對于我們的元數(shù)據(jù)做如下定義：

這里的這個元數(shù)據(jù)信息是對于某一個schema來說的，依次是一個SchemaId，然后是Name（可以理解為表名），然后是當前schema的代數(shù)，其實就是一個類似于版本的東西，初始為0，最后一個是創(chuàng)建或修改時間，還有一些其它信息，這里省略掉。

下面是對于字段的一些元數(shù)據(jù)，兩者通過SchemaId關聯(lián)，包含了所對應的Schema，在schema中的順序(解析的時候用)，類型，是否為空，是否為主鍵啊之類的。

我們有了這些元數(shù)據(jù)信息以后可以做什么呢？

對于我們的一行記錄，我們理解為一串二進制字節(jié)碼，如何從這串字節(jié)碼中解析我們的字段呢，依靠的就是這些元數(shù)據(jù)，下面我將物理上存儲的格式貼出來，大家就明白了：

大家注意看，物理上我們存儲了一個Generation字段來標識當前的Schema是屬于該schema的哪個特點的版本。那么根據(jù)這個Generation以及這個表名(即StoreName)我們就可以得出一個SchemaId，根據(jù)這個SchemaId我們可以得到有序的該Schema的所有字段，那么剩下的就很easy了，如果對于二進制編碼不太熟悉的，請看看Protocol Buffer

好了，那么我們?nèi)绻朐黾右粋€字段呢？需要做的僅僅是修改元信息，將新的Schema信息存入上面兩個元數(shù)據(jù)，如果想讀取原有的老數(shù)據(jù)，那么根據(jù)generation進行相關解析即可，如果插入新的Schema的數(shù)據(jù)，使用最新的generation就可以了，一切都非常完美。這個generation字段還可以使用壓縮編碼的方式，在generation小于128的時候，我們只需要1個字節(jié)的額外空間消耗

優(yōu)點：無需額外空間消耗，無需在線修改，透明的使用，幾乎無downtime

缺點：如果增加字段，原有老數(shù)據(jù)的格式仍然是默認值，但我想這一點大部分人都可以將其忽略

總結

上面基本上是目前動態(tài)schema的主要實現(xiàn)方法，如果大家有新的解決方案，請告訴我。

歡迎大家交流討論。