隨著世界聯(lián)系越來越緊密，越來越智能，許多企業(yè)都希望其IT的使用也變得更加智慧。企業(yè)的數(shù)據(jù)量正在以***的速度增長，業(yè)務對數(shù)據(jù)的依賴強度越來越高。如何讓數(shù)據(jù)更高效幫助業(yè)務的發(fā)展，快速響應業(yè)務需求，在大量數(shù)據(jù)中及時提供決策分析，提升企業(yè)管理者對IT的管理效率，在當前的經(jīng)濟環(huán)境下讓IT為企業(yè)帶來更大經(jīng)濟效益，讓IT幫助企業(yè)未來5-10年的業(yè)務發(fā)展——所有這些都對企業(yè)的數(shù)據(jù)庫系統(tǒng)提出了更高的要求。此時，就出現(xiàn)了數(shù)據(jù)庫的遷移。

為何要對數(shù)據(jù)庫進行遷移?

回顧年初：聯(lián)合可口可樂裝瓶公司將數(shù)據(jù)庫遷移到IBM DB2的事件。為什么可口可樂公司要進行遷移?51CT0記者帶著這一問題對IBM軟件集團大中華區(qū)數(shù)據(jù)庫和數(shù)據(jù)倉庫銷售總監(jiān)何怡靜女士進行了專訪。何怡靜女士表示現(xiàn)在的客戶更多是考慮成本問題。確實，在數(shù)據(jù)庫功能越來越強大的今天，客戶對數(shù)據(jù)庫的選擇更多的考慮，如何用更小的成本獲得更大的效率，當然如何降低成本，也是大家無論是客戶還是合作伙伴面臨的最巨大的挑戰(zhàn)。

數(shù)據(jù)庫間的遷移主要的一個原因是因為客戶考慮的成本問題，舉一個例子：維保問題。因為高額的維保，所以選擇遷移到別家數(shù)據(jù)庫產(chǎn)品，以降低成本。

再看另一個遷移例子：Digg和Reddit宣布轉(zhuǎn)向Cassandra ，因為MySQL對他們來說伸縮性不夠了。一些人認為MySQL+memchche不再是事實上的伸縮解決方案了。

遷移都要考慮什么因素呢?

其實作為客戶，對于他們使用的數(shù)據(jù)庫，無論是出于成本的考慮，還是慣性的原因，亦或是感情的原因，大都是選擇“不拋棄，不放棄”的原則。那么是什么原因使得這些忠實的“粉絲”選擇了拋棄，選擇了放棄呢?這里總結(jié)了以下幾點原因。

一、成本

就像上文中提到的那樣，成本是是否對數(shù)據(jù)庫做遷移的一個根本性因素，誰能為客戶帶去更大的利益，客戶可能就會忽略在遷移中產(chǎn)生的成本，而選擇“搬家”。我們還是以可口可樂公司為例，通過遷移，使用DB2，可口可樂公司的存儲需求減少了大約40%;同時批處理時間也大幅減少了65%以上，從而提高了供應鏈的整體效率。

二、維保

維保的問題是連接著成本而來的，就像上文中何怡靜女士為我們舉的例子一樣，也許客戶從沒有想過遷移，但是卻因為高額的維保費用，從為公司減少不必要的開銷的角度出發(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條。在當當上輸入關(guān)鍵詞SQL Server，共搜到519個商品，MySQL，共搜到313個商品，Oracle，共搜到249個商品，DB2，共搜到82個商品，由此可見，從圖書上說，SQL Server的普遍性最廣泛。

為了遷移的方便，各家更是推出了適應別家遷移到自家的遷移工具，微軟有MySQL向SQL Server遷移工具CTP，不過這個工具只支持到MySQL的4.1/5.0/5.1版本，不知對現(xiàn)在的5.6版本何時才能支持。

四、與時俱進

現(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ù)加強對海量數(shù)據(jù)和非結(jié)構(gòu)化的支持。

SQL Server的動作：運行SQL Server的微軟客戶將通過Hadoop的引入獲得真正的大數(shù)據(jù)處理能力。微軟已經(jīng)發(fā)布了早期代碼，讓客戶可以將這個Java架構(gòu)接入到SQL Server 2008 R2、SQL Server Parallel Data Warehouse以及下一代微軟數(shù)據(jù)庫。

如果hold不住這一形式，會怎么樣呢?

情景一：對不起，我們離婚吧，我愛上了別人。

Craigslist采用MongoDB替代MySQL

視覺中國的NoSQL之路：從MySQL到MongoDB

情景二：親愛的，我們結(jié)婚吧，我們會是最幸福的

新娘：Redis，新郎：MySQL，結(jié)婚地點：新浪

新浪微博是Redis全球***的用戶，在新浪有200多臺物理機，400多個端口正在運行著Redis, 有+4G的數(shù)據(jù)跑在Redis上來為微博用戶提供服務。

在新浪NoSQL和MySQL在大多數(shù)情況下是結(jié)合使用的，根據(jù)應用的特點選擇合適存儲方式。譬如：關(guān)系型數(shù)據(jù)，例如：索引使用MySQL存儲，非關(guān)系數(shù)據(jù)庫，例如：一些K/V需求的，對并發(fā)要求比較高的放入Redis存儲。

總結(jié)

究竟一個客戶會在哪種情況，選擇將一個數(shù)據(jù)庫從一個服務器移到另一個服務器上。這種遷移分兩種情況，一種是整個數(shù)據(jù)服務器全部遷移，一種是只移其中的個別數(shù)據(jù)庫。無論是哪種遷移，是否都說明原有的數(shù)據(jù)庫hold不住客戶的需求呢?總之，現(xiàn)在看來遷移的何去何從是客戶說的算。

【備注】所謂維保，主要包含兩個內(nèi)容，一個是 小版本的更新，一個是平常發(fā)生問題時的7×24小時電話服務。當客戶只需要7×24小時的電話服務，而不需要更新的時候，實際上只用到所謂維保的不到 20%的服務，如果這個時候廠商開出全額的維保費用，對于客戶來說，就是很難接受的。但是如果不買滿維保，客戶又得不到電話服務，這對于很多客戶，可謂是 騎虎難下的局面。于是，他們就會做出另一種選擇——引進第二種數(shù)據(jù)庫。如果說以前為了避免風險，才不愿意用第二種數(shù)據(jù) 庫，在這個痛定之痛之后一定會引進第二種。市場就是這樣，有了競爭公司自動會調(diào)整策略，這樣廠商策略也會作相應調(diào)整。當引進另一種數(shù)據(jù)庫以后，之前數(shù)據(jù)庫 的廠商也就會無形的改變他們的策略，而這也就是無形的降低了客戶的成本。

【編輯推薦】

1. NoSQL數(shù)據(jù)庫漸入佳境 國內(nèi)應用案例盤點
2. 數(shù)據(jù)庫緩存重建不容忽視
3. SQL Server數(shù)據(jù)庫恢復案例分享
4. SQL Server數(shù)據(jù)庫最小宕機遷移方案
5. 給你大型數(shù)據(jù)庫遷移的五大建議