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