建站
咨詢
售后
建站咨詢
新聞中心
事情變得有意思了，上一篇花1小時撰寫的“一分鐘”文章，又引起了廣泛的討論，說明相關的技術大家感興趣，挺好。第一次一篇技術文章的評論量過100，才知道原來“評論精選”還有100上限，甚為欣慰(雖然是以一種自己不愿看到的方式)。
創(chuàng)新互聯(lián)專注于奇臺企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設,商城開發(fā)。奇臺網(wǎng)站建設公司,為奇臺等地區(qū)提供建站服務。全流程定制開發(fā)，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務
《啥，又要為表增加一列屬性?》的方案頗有爭議：
(1)版本號version + 擴展字段ext
(2)用增加列的key+value方式擴充屬性
因自己時間倉促，有些地方?jīng)]有交代清楚，對不起大伙，實在抱歉。大部分評論還是在進行技術討論，故今天再熬夜補充說明一下。
零、緣起
討論問題域：
(1)數(shù)據(jù)量大、并發(fā)量高場景，在線數(shù)據(jù)庫屬性擴展
(2)數(shù)據(jù)庫表結構擴展性設計
一、哪些方案一定是不行的
(1)alter table add column
要堅持這個方案的，也不多解釋了，大數(shù)據(jù)高并發(fā)情況下，一定不可行
(2)通過增加表的方式擴展，通過外鍵join來查詢
大數(shù)據(jù)高并發(fā)情況下，join性能較差，一定不可行
(3)通過增加表的方式擴展，通過視圖來對外
一定不可行。大數(shù)據(jù)高并發(fā)情況下，互聯(lián)網(wǎng)不怎么使用視圖，至少58禁止使用視圖
(4)必須遵循“第x范式”的方案
一定不可行?；ヂ?lián)網(wǎng)的主要矛盾之一是吞吐量，為了保證吞吐量甚至可能犧牲一些事務性和一致性，通過反范式的方式來確保吞吐量的設計是很常見的，例如：冗余數(shù)據(jù)?；ヂ?lián)網(wǎng)的主要矛盾之二是可用性，為了保證可用性，常見的技術方案也是數(shù)據(jù)冗余。在互聯(lián)網(wǎng)數(shù)據(jù)庫架構設計中，第x范式真的沒有這么重要
(5)打產(chǎn)品經(jīng)理
朋友，這是段子么，這一定不可行
二、哪些方案可行，但文章未提及
(1)提前預留一些reserved字段
這個是可以的。但如果預留過多，會造成空間浪費，預留過少，不一定達得到擴展效果。
(2)通過增加表的方式擴展列，上游通過service來屏蔽底層的細節(jié)
這個也是可以的。Jeff同學提到的UserExt(uid, newCol1, newCol2)就是這樣的方案(但join連表和視圖是不行的)
三、哪些讀者沒有仔細看文章
(1)version+ext太弱了，ext不支持索引
回復：屬于沒有仔細看文章，文章也提了如果有強需求索引可以使用MongoDB，它就是使用的json存儲(評論中有不少朋友提到，還有其他數(shù)據(jù)庫支持json檢索)
(2)第二種key+value方案不支持索引
回復：uid可以索引
四、key+value方式使用場景
服務端，wordpress，EAV，配置，統(tǒng)計項等都經(jīng)常使用這個方案。
客戶端(APP或者PC)，保存?zhèn)€人信息也經(jīng)常使用這個方案。
今天的重點
以樓主性格，本不會進行“解釋”，上文解釋這般，說明這一次，樓主真的認真了。對于技術，認真是好事，認真的男人最可愛(打住，我要吐了)。好了，下面的內容才是今天的重點。
五、在線表結構變更
在《啥，又要為表增加一列屬性?》文章的開頭，已經(jīng)說明常見“新表+觸發(fā)器+遷移數(shù)據(jù)+rename”方案(pt-online-schema-change)，這是業(yè)內非常成熟的擴展列的方案(以為大伙都熟悉，沒有展開講，只重點講了兩種新方案，這可能是導致被噴得厲害的源頭)，今天補充說一下。
以user(uid, name, passwd)
擴展到user(uid, name, passwd, age, sex)為例
基本原理是：
(1)先創(chuàng)建一個擴充字段后的新表user_new(uid, name, passwd, age, sex)
(2)在原表user上創(chuàng)建三個觸發(fā)器，對原表user進行的所有insert/delete/update操作，都會對新表user_new進行相同的操作
(3)分批將原表user中的數(shù)據(jù)insert到新表user_new，直至數(shù)據(jù)遷移完成
(4)刪掉觸發(fā)器，把原表移走(默認是drop掉)
(5)把新表user_new重命名(rename)成原表user
擴充字段完成。
優(yōu)點：整個過程不需要鎖表，可以持續(xù)對外提供服務
操作過程中需要注意：
(1)變更過程中，最重要的是沖突的處理，一條原則，以觸發(fā)器的新數(shù)據(jù)為準，這就要求被遷移的表必須有主鍵(這個要求基本都滿足)
(2)變更過程中，寫操作需要建立觸發(fā)器，所以如果原表已經(jīng)有很多觸發(fā)器，方案就不行(互聯(lián)網(wǎng)大數(shù)據(jù)高并發(fā)的在線業(yè)務，一般都禁止使用觸發(fā)器)
(3)觸發(fā)器的建立，會影響原表的性能，所以這個操作建議在流量低峰期進行
pt-online-schema-change是DBA必備的利器，比較成熟，在互聯(lián)網(wǎng)公司使用廣泛。
樓主非專業(yè)的dba，上面的過程有說的不對的地方，歡迎指出。要了解更詳細的細節(jié)，可以百度一下。有更好的方法，也歡迎討論，后續(xù)會梳理匯總share給更多的朋友。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】
網(wǎng)頁名稱：這才是真正的表擴展方案
當前URL：http://www.5511xx.com/article/dhiigio.html
