1. 程式人生 > >【轉載】這才是真正的表擴展方案

【轉載】這才是真正的表擴展方案

過程 round pass 配置 一致性 結束 ech 好的 原理

事情變得有意思了,上一篇花1小時撰寫的“一分鐘”文章,又引起了廣泛的討論,說明相關的技術大家感興趣,挺好。第一次一篇技術文章的評論量過100,才知道原來“評論精選”還有100上限,甚為欣慰(雖然是以一種自己不願看到的方式)。

《啥,又要為表增加一列屬性?》的方案頗有爭議:

(1)版本號version + 擴展字段ext

(2)用增加列的key+value方式擴充屬性

有些評論,只能說“所謂夏蟲,何以語冰”(作者要謙和,請刪除)。因自己時間倉促,有些地方沒有交代清楚,對不起大夥,實在抱歉。大部分評論還是在進行技術討論,故今天再熬夜補充說明一下。

零、緣起

討論問題域:

(1)數據量大、並發量高場景,在線數據庫屬性擴展

(2)數據庫表結構擴展性設計

一、哪些方案一定是不行

(1)alter table add column

要堅持這個方案的,也不多解釋了,大數據高並發情況下,一定不可行

(2)通過增加表的方式擴展,通過外鍵join來查詢

大數據高並發情況下,join性能較差,一定不可行

(3)通過增加表的方式擴展,通過視圖來對外

一定不可行。大數據高並發情況下,互聯網不怎麽使用視圖,至少58禁止使用視圖

(4)必須遵循“第x範式”的方案

一定不可行。互聯網的主要矛盾之一是吞吐量,為了保證吞吐量甚至可能犧牲一些事務性和一致性,通過反範式的方式來確保吞吐量的設計是很常見的,例如:冗余數據。互聯網的主要矛盾之二是可用性

,為了保證可用性,常見的技術方案也是數據冗余。在互聯網數據庫架構設計中,第x範式真的沒有這麽重要

(5)打產品經理

朋友,這是段子麽,這一定不可行

二、哪些方案可行,但文章未提及

(1)提前預留一些reserved字段

這個是可以的。但如果預留過多,會造成空間浪費,預留過少,不一定達得到擴展效果。

(2)通過增加表的方式擴展列,上遊通過service來屏蔽底層的細節

這個也是可以的。Jeff同學提到的UserExt(uid, newCol1, newCol2)就是這樣的方案(但join連表和視圖是不行的)

三、哪些讀者沒有仔細看文章

(1)version+ext太弱了,ext不支持索引

回復:屬於沒有仔細看文章,文章也提了如果有強需求索引可以使用MongoDB,它就是使用的json存儲(評論中有不少朋友提到,還有其他數據庫支持json檢索)

(2)第二種key+value方案不支持索引

回復:uid可以索引

四、key+value方式使用場景

服務端,wordpress,EAV,配置,統計項等都經常使用這個方案。

客戶端(APP或者PC),保存個人信息也經常使用這個方案。

今天的重點

以樓主性格,本不會進行“解釋”,上文解釋這般,說明這一次,樓主真的認真了。對於技術,認真是好事,認真的男人最可愛(打住,我要吐了)。好了,下面的內容才是今天的重點。

五、在線表結構變更

在《啥,又要為表增加一列屬性?》文章的開頭,已經說明常見“新表+觸發器+遷移數據+rename”方案(pt-online-schema-change),這是業內非常成熟的擴展列的方案(以為大夥都熟悉,沒有展開講,只重點講了兩種新方案,這可能是導致被噴得厲害的源頭),今天補充說一下。

user(uid, name, passwd)

擴展到user(uid, name, passwd, age, sex)為例

基本原理是:

(1)先創建一個擴充字段後的新表user_new(uid, name, passwd, age, sex)

(2)在原表user上創建三個觸發器,對原表user進行的所有insert/delete/update操作,都會對新表user_new進行相同的操作

(3)分批將原表user中的數據insert到新表user_new,直至數據遷移完成

(4)刪掉觸發器,把原表移走(默認是drop掉)

(5)把新表user_new重命名(rename)成原表user

擴充字段完成。

優點:整個過程不需要鎖表,可以持續對外提供服務

操作過程中需要註意

(1)變更過程中,最重要的是沖突的處理,一條原則,以觸發器的新數據為準,這就要求被遷移的表必須有主鍵(這個要求基本都滿足)

(2)變更過程中,寫操作需要建立觸發器,所以如果原表已經有很多觸發器,方案就不行(互聯網大數據高並發的在線業務,一般都禁止使用觸發器)

(3)觸發器的建立,會影響原表的性能,所以這個操作建議在流量低峰期進行

pt-online-schema-change是DBA必備的利器,比較成熟,在互聯網公司使用廣泛。

樓主非專業的dba,上面的過程有說的不對的地方,歡迎指出。要了解更詳細的細節,可以百度一下。有更好的方法,也歡迎討論,後續會梳理匯總share給更多的朋友。

六、結束

歡迎用批判的眼光看問題,歡迎任何友善的技術討論,不太歡迎“純屬誤導”“非常蠢的方案”這樣的評論(但我還是會加精選,任何人都有發聲的權利)。

借評論中@張九雲 朋友的一句話“不要以為自己見過的就是全世界,任何方案都有使用場景,一切都是tradeoff”作為今天的結尾,謝謝大家的支持,感謝大家。

==【完】==

【轉載】這才是真正的表擴展方案