數(shù)據(jù)庫遷移之何去何從
原創(chuàng)隨著世界聯(lián)系越來越緊密，越來越智能，許多企業(yè)都希望其IT的使用也變得更加智慧。企業(yè)的數(shù)據(jù)量正在以***的速度增長，業(yè)務(wù)對數(shù)據(jù)的依賴強(qiáng)度越來越高。如何讓數(shù)據(jù)更高效幫助業(yè)務(wù)的發(fā)展，快速響應(yīng)業(yè)務(wù)需求，在大量數(shù)據(jù)中及時提供決策分析，提升企業(yè)管理者對IT的管理效率，在當(dāng)前的經(jīng)濟(jì)環(huán)境下讓IT為企業(yè)帶來更大經(jīng)濟(jì)效益，讓IT幫助企業(yè)未來5-10年的業(yè)務(wù)發(fā)展——所有這些都對企業(yè)的數(shù)據(jù)庫系統(tǒng)提出了更高的要求。此時，就出現(xiàn)了數(shù)據(jù)庫的遷移。
為何要對數(shù)據(jù)庫進(jìn)行遷移?
回顧年初：聯(lián)合可口可樂裝瓶公司將數(shù)據(jù)庫遷移到IBM DB2的事件。為什么可口可樂公司要進(jìn)行遷移?51CT0記者帶著這一問題對IBM軟件集團(tuán)大中華區(qū)數(shù)據(jù)庫和數(shù)據(jù)倉庫銷售總監(jiān)何怡靜女士進(jìn)行了專訪。何怡靜女士表示現(xiàn)在的客戶更多是考慮成本問題。確實(shí)，在數(shù)據(jù)庫功能越來越強(qiáng)大的今天，客戶對數(shù)據(jù)庫的選擇更多的考慮，如何用更小的成本獲得更大的效率，當(dāng)然如何降低成本，也是大家無論是客戶還是合作伙伴面臨的最巨大的挑戰(zhàn)。
數(shù)據(jù)庫間的遷移主要的一個原因是因?yàn)榭蛻艨紤]的成本問題，舉一個例子：維保問題。因?yàn)楦哳~的維保，所以選擇遷移到別家數(shù)據(jù)庫產(chǎn)品，以降低成本。
再看另一個遷移例子：Digg和Reddit宣布轉(zhuǎn)向Cassandra ，因?yàn)镸ySQL對他們來說伸縮性不夠了。一些人認(rèn)為MySQL+memchche不再是事實(shí)上的伸縮解決方案了。
遷移都要考慮什么因素呢?
其實(shí)作為客戶，對于他們使用的數(shù)據(jù)庫，無論是出于成本的考慮，還是慣性的原因，亦或是感情的原因，大都是選擇“不拋棄，不放棄”的原則。那么是什么原因使得這些忠實(shí)的“粉絲”選擇了拋棄，選擇了放棄呢?這里總結(jié)了以下幾點(diǎn)原因。
一、成本
就像上文中提到的那樣，成本是是否對數(shù)據(jù)庫做遷移的一個根本性因素，誰能為客戶帶去更大的利益，客戶可能就會忽略在遷移中產(chǎn)生的成本，而選擇“搬家”。我們還是以可口可樂公司為例，通過遷移，使用DB2，可口可樂公司的存儲需求減少了大約40%;同時批處理時間也大幅減少了65%以上，從而提高了供應(yīng)鏈的整體效率。
二、維保
維保的問題是連接著成本而來的，就像上文中何怡靜女士為我們舉的例子一樣，也許客戶從沒有想過遷移，但是卻因?yàn)楦哳~的維保費(fèi)用，從為公司減少不必要的開銷的角度出發(fā)，***決定從眾多產(chǎn)品中選擇出一個可以總體減少成本的數(shù)據(jù)庫，而放棄之前的產(chǎn)品。
三、使用的普遍性
有時候選擇使用某種數(shù)據(jù)庫，也要看一看這種數(shù)據(jù)庫的使用普遍性，如果拿到了一種數(shù)據(jù)庫，卻發(fā)現(xiàn)無從下手，那豈不是尷尬?
根據(jù)我們在卓越上輸入關(guān)鍵詞SQL Server，查找結(jié)果有共1,064條，MySQL，共198條，Oracle，共711條，DB2，共92條。在當(dāng)當(dāng)上輸入關(guān)鍵詞SQL Server，共搜到519個商品，MySQL，共搜到313個商品，Oracle，共搜到249個商品，DB2，共搜到82個商品，由此可見，從圖書上說，SQL Server的普遍性最廣泛。
為了遷移的方便，各家更是推出了適應(yīng)別家遷移到自家的遷移工具，微軟有MySQL向SQL Server遷移工具CTP，不過這個工具只支持到MySQL的4.1/5.0/5.1版本，不知對現(xiàn)在的5.6版本何時才能支持。
四、與時俱進(jìn)
現(xiàn)在的數(shù)據(jù)形勢是呈現(xiàn)海量的，非結(jié)構(gòu)化占據(jù)主要地位的，數(shù)據(jù)庫廠商是否能夠hold住這個形勢呢?這也是客戶是否會選擇放棄該種數(shù)據(jù)庫的一大原因。
DB2的動作：IBM表示已經(jīng)在現(xiàn)有DB2產(chǎn)品中增加了對hadoop的支持，在未來推出的第10版本中也會繼續(xù)加強(qiáng)對海量數(shù)據(jù)和非結(jié)構(gòu)化的支持。
SQL Server的動作：運(yùn)行SQL Server的微軟客戶將通過Hadoop的引入獲得真正的大數(shù)據(jù)處理能力。微軟已經(jīng)發(fā)布了早期代碼，讓客戶可以將這個Java架構(gòu)接入到SQL Server 2008 R2、SQL Server Parallel Data Warehouse以及下一代微軟數(shù)據(jù)庫。
如果hold不住這一形式，會怎么樣呢?
情景一：對不起，我們離婚吧，我愛上了別人。
情景二：親愛的，我們結(jié)婚吧，我們會是最幸福的
新娘：Redis，新郎：MySQL，結(jié)婚地點(diǎn)：新浪
新浪微博是Redis全球***的用戶，在新浪有200多臺物理機(jī)，400多個端口正在運(yùn)行著Redis, 有+4G的數(shù)據(jù)跑在Redis上來為微博用戶提供服務(wù)。
在新浪NoSQL和MySQL在大多數(shù)情況下是結(jié)合使用的，根據(jù)應(yīng)用的特點(diǎn)選擇合適存儲方式。譬如：關(guān)系型數(shù)據(jù)，例如：索引使用MySQL存儲，非關(guān)系數(shù)據(jù)庫，例如：一些K/V需求的，對并發(fā)要求比較高的放入Redis存儲。
總結(jié)
究竟一個客戶會在哪種情況，選擇將一個數(shù)據(jù)庫從一個服務(wù)器移到另一個服務(wù)器上。這種遷移分兩種情況，一種是整個數(shù)據(jù)服務(wù)器全部遷移，一種是只移其中的個別數(shù)據(jù)庫。無論是哪種遷移，是否都說明原有的數(shù)據(jù)庫hold不住客戶的需求呢?總之，現(xiàn)在看來遷移的何去何從是客戶說的算。
【備注】所謂維保，主要包含兩個內(nèi)容，一個是 小版本的更新，一個是平常發(fā)生問題時的7×24小時電話服務(wù)。當(dāng)客戶只需要7×24小時的電話服務(wù)，而不需要更新的時候，實(shí)際上只用到所謂維保的不到 20%的服務(wù)，如果這個時候廠商開出全額的維保費(fèi)用，對于客戶來說，就是很難接受的。但是如果不買滿維保，客戶又得不到電話服務(wù)，這對于很多客戶，可謂是 騎虎難下的局面。于是，他們就會做出另一種選擇——引進(jìn)第二種數(shù)據(jù)庫。如果說以前為了避免風(fēng)險，才不愿意用第二種數(shù)據(jù) 庫，在這個痛定之痛之后一定會引進(jìn)第二種。市場就是這樣，有了競爭公司自動會調(diào)整策略，這樣廠商策略也會作相應(yīng)調(diào)整。當(dāng)引進(jìn)另一種數(shù)據(jù)庫以后，之前數(shù)據(jù)庫 的廠商也就會無形的改變他們的策略，而這也就是無形的降低了客戶的成本。
【編輯推薦】
- NoSQL數(shù)據(jù)庫漸入佳境 國內(nèi)應(yīng)用案例盤點(diǎn)
- 數(shù)據(jù)庫緩存重建不容忽視
- SQL Server數(shù)據(jù)庫恢復(fù)案例分享
- SQL Server數(shù)據(jù)庫最小宕機(jī)遷移方案
- 給你大型數(shù)據(jù)庫遷移的五大建議
