InfoQ 資料庫架構採訪文字修正稿 2

infoq中文站: 在 web 2.0的時代，海量資料對於越來越多的開發者來說，已經不再是乙個遙不可及的話題了，可能隨便哪乙個訪問量很大的web2.0**都有可能擁有令人咂舌的資料量，那麼對於這種**，除了對資料庫儲存進行優化，除了快取，然後還有那些策略？

fenng: 我覺得可能主要是在儲存方面會有一些大的挑戰。比如儲存的可靠性，像以前就有過 bsp服務商對客戶的資料居然沒有備份，導致了很多使用者損失了一段時間之內的資料，這樣總體來說對**的聲譽有很大影響、對使用者的體驗也很糟糕。

隨著網際網路的飛速發展，資料總體來說是趨於膨脹性的，在這個過程中，如何把資料有效的儲存，並且有效的獲取，便是個比較複雜的問題。我們前面說了太多 web 2.0相關的話題，【換個角度】比如說我所在的公司支付寶，也面臨著這樣的大資料量、海量資料的挑戰。當前我們的乙個策略，也是沿襲 soa 的戰略化思想，就是資料庫相關的資料服務進行一定的 soa 化處理。另外乙個比較重要的策略就是資料生命週期的管理，我們對這樣的，在資料生命週期已經完成後，會對相關的資料做一些歸檔化的處理，再進行二級儲存或者分級儲存。那麼話說回來，對一些 web 2.0 **，我覺得也可以運用這樣的思想機制: 對使用者已經不大可能訪問或者訪問頻率比較低的（資料），採用分級儲存，或者額外做一些訪問策略的制訂，是很有必要的。

infoq中文站: 我們也聽說過另外一種分片資料庫機制，那麼請你談談分片這種策略是怎麼樣一種策略？

fenng: 分片總的來說，它不是一種比較新的技術， mysql 在 5 .x 版本之後，有了分割槽功能。那麼在這之前，mysql 是沒有分割槽功能的。當時如果需要處理一些比較大的資料量，比方說要對根據時間對資料進行歷史化處理，就會比較麻煩。人們可能是因地制宜，就產生 sharding 這樣技術策略。

如果建的是商務**，可能根據產品的型別來做，我們會把不同產品型別的資料扔到不同的 db上，這些 db 之間的關聯度是很小的。然後我們在 db 之間，可能會有乙個封裝層，在這個封裝層之上，對應用程式使用者來說，就像是透明的，那麼就達到了我們資料庫上高度擴充套件化的目標。

infoq中文站: 那分片這種策略有什麼利弊嗎？

fenng: 首先，分片的好處還是很容易看到的。起碼我們的 db 能達到不依賴於某個單點，而這樣能做到平滑的擴充套件，就像大家常說的 scale out (橫向擴充套件)機制。它的弊端也是比較明顯，對於事務高速處理這樣的**，它有它的自己的不足之處，事實上好多朋友也應該知道，乙個事務如果跨資料庫，這樣對設計者，對編碼人員來說，還是比較棘手的。那麼如果乙個事務如果跨兩個甚至多個 db，sharding 複雜度就會很高。sharding 在業界的應用場景基本上也就是這種讀應用比較重的情況，而且對事務的安全性要求不高，這樣的場景會非常適合。

【上個月寫了篇 sharding 的東西給《程式設計師》，還不知道什麼時候發表出來】

infoq中文站: 目前在許多**的架構設計中有絕大多數的專案在持久化方面就是採用資料關係對映（orm）的方式。大家對於這種高負載的大規模**應用來說，你覺得存在哪些應用呢？

fenng: 首先一點，我想拿我們支付寶來說，orm 大家覺得用得非常好。在乙個相對比較大的開發環境，對開發團隊來說，它的弊端可能就不大容易看出來。因為我們用的是 orm，就很容易把中間 db 這層完全隔離出來。然後把這一層的 sql 處理交給專門的 db 人員—-我們這邊還有專門的開發dba，由他們來專門對這層進行集中的監控管理，乃至一些規劃類的工作。這樣開發工程師還有架構師這邊，他們可以集中精力在其他方面做更多的投入，乙個比較大的團隊中我覺得像 orm 這些還是很容易能看到好處的。

【orm 還有個比較好的地方在於安全性，能有效減少 sql 注入的隱患】

infoq中文站: 那你所做的支付寶，其實是企業級別的應用，在企業級別應用所採用的這種架構策略和一般 web 2.0 **所採用的這種架構策略會有什麼異同？

fenng: 事實上，很明顯的一點，支付寶其實業務是非常複雜的【也有一部分人誤解支付寶業務很簡單】，這和我們很多的web2.0公司不大一樣，web2.0它可能從乙個點切入進去。在這一點上，我覺得做得比較透。支付寶呢，它可能有點像我們以前做的一些通用軟體，他要考慮不同的行業、不同的使用者、還有像買賣之間，與這麼多銀行之間的關係等等，這個複雜度還是很大的。

這實際上就從一定程度上決定了我們和 web 2.0 公司截然不同的應用解決方案，像當前我們在支付寶，在一年之前，甚至兩年之前就已經考慮，把我們的整個** soa 化、元件化。在這個過程中，也考慮了一些像 web 2.0 中的技術元素，但總體的思路呢，還是說向soa 化，向面向服務這方面大步的跨進，然後就從 soa 這一點，事實上很多 web 2.0 公司，他們未必能完全的實現，完全的做到這樣的面向服務化，我覺得這可能是兩者截然不同的乙個表面特點。

另外，像支付寶也在嘗試做一些，對外部客戶、服務提供一些介面，甚至完全開放的乙個平台，這一點又和我們當前這些像 facebook ，或者是說，像美國的 myspace 這樣的社交區、sns 網路了有一些共通之處。

infoq中文站: 那目前在 web 2.0 **這個領域裡面，**的架構主要有哪些趨勢，下邊還將有怎麼樣乙個走向呢？

fenng: 其實作為乙個技術人員，每當要談到趨勢，肯定要給大家笑。從中長期來看，國內的一些 web 2.0 新服務逐漸湧現出來了，隨著發展，我相信會有更多的商業化元素加進來。像以前是好多 web 2.0 公司是完全使用開源的技術，伴隨規模擴大化，一些以前提供開源技術的組織或個人他們會嘗試進行一些商業化的運作。商業化並不是個壞事情，一方面給我們提供更好的服務。另一方面，他們得到了足夠的商業支援，反過來之後他們又會對整體的開源開發環境、發展環境起到很好的促進。我相信在未來的兩到三年之內，會有一部分的商業公司湧到 web 2.0 的發展生態圈裡面。

然後從技術方面來講，像前面幾個月 mysql 被 sun 收購，起碼是在 web 2.0 這樣的軟體鏈條中的乙個重要環節(mysql),有些人可能會感覺出了一些問題。但現在像在資料庫這一層呢，也不排除像 postgressql 這些其它的資料庫，趁這個機會被商業公司所擁抱，他們也會做出一些更大規模的應用場景出來。在資料庫這方面可能會限制大家，幾家開源資料庫形成乙個僵局，sun 在……這個有些扯遠了，還是繞回來。像現在很多的 web 2.0 公司，他們對 web 伺服器這方面也會採用一些比較新的，像 nginx，我覺得在起碼在接下來的一段時間內會吸引絕大多數公司長期、大規模的去使用它、去擁抱它，甚至為它開發一些更激動人心的新特性。

【這段時間比較熱炒的開放平台、雲計算也或許能給我們帶來一些思路：很多有技術積累的的公司都有自己打造一套底層的架構的意圖，比如針對儲存層面向應用的虛擬化等。】

infoq中文站: 那最後作為乙個由 dba (administrator) 成長為db architect，同樣都是a，但這個a已經有乙個變化，那麼你對後來者有哪些建議呢？

fenng: 建議談不上，跟大家談談自己在這個過程中的一些轉變。首先從dba(的角度說)，因為 dba 做一些實際相關的維護工作，從這個過程轉到架構師這邊，是相對從這比較」實」的崗位轉換到現在看起來相對好像稍稍」虛」了一些，但是在這個」虛」的過程中，又相當於我們且退一步，然後就能看得更遠一些，能看到整個軟體架構的**發展，甚至是公司戰略上的一些事情，這對個人成長是有好處的，我希望大家如果有這個意願也可以稍微嘗試一下，因為 dba 只是我們整個軟體開發行業中的乙個環節，那麼在這個環節前面和後面，其實都有很多可以做的事情。

其實每個人都不是不可替代的，那我們是否可以嘗試一下是否能夠去替代別人呢？謝謝大家。

–eof–

google+

InfoQ 資料庫架構採訪文字修正稿 2

InfoQ 資料庫架構採訪文字修正稿 2

資料庫架構

資料庫 3 1 資料庫架構

相關推薦