大高雄Linux使用者協會

首先要跟各位聲明的, 這篇文章內容主要是老魚去申請轉載而來, 而我僅是用長年閱讀簡體中文詞彙的經驗加以正體中文和稍加校詞潤飾, 特別選這篇文, 有幾個目的： 老魚為一個新的SNS開發專案, 進行研究評估幾個雲端(分散式)儲存系統, 過程中也是棄了 HBase, MongoDB 選 Cassandra, 而當我這二天看到這篇文中的不少技術選型的出發點, 讓我閱讀後有不少處有所同感(在文章中標紅色的段落). 籍由這篇文選, 希望同是身為電腦科學工程與甚至任職企業資訊採購決策管理者一份子的您, 能從這篇文中, 去思考當我們在企業中扮演一個對資訊科技採購時, 不應只是表面名牌價格與廠商行銷手法, 龐大複雜且難以駕馭系統規劃被廠商合理化之, 反造成企業長期的營運維護成本上升, 企業逐漸受外在資訊廠商所“挾持”, 從而失去企業自我資訊自主的競爭本能. 這篇文中如果扣除作者在評論其二家產品, 各位看官也可以獲得不少目前電腦科學領域中當前最競爭的幾點新知, 尤其作者是以該領域的專家評論, 在出發點上就不會有太多被一般新聞過度炒作“雲端計算Cloud Computing”名詞上的疑慮. 文中作者也對 CAP, CA, AP 等理論給予突破性的實證觀點. 原文: http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ 原作者：Dominic Williams 原文發佈日期：February 24, 2010 at 7:27 pm 譯者：王旭（http://wangxu.me/blog/ , @gnawux） 翻譯時間：2010年3月21-25日 簡體轉正體中文及校潤詞句：郭朝益(http://wisdomfish.org, @master) 我的團隊近來正在忙於一個全新的產品——即將發佈的網絡遊戲 www.FightMyMonster.com。 這讓我們得以奢侈地去構建一個全新的 NoSQL 資料存儲庫系統，也就是說，我們可以把恐怖的 MySQL sharding 和昂貴的可伸縮性拋在腦後了。最近有很多人一直在問，為什麼我們要把注意力再從 HBase 上轉移到 Cassandra 上去。我確認，確實有這樣的變化，實際上我們在基礎上已經把程式碼移植到了 Cassandra 上了，這裡我將作出解釋。 為了那些不熟悉 NOSQL 的讀者，在往後的其他文章中，我會介紹為什麼我們將會在未來幾年中看到如地震般的從 SQL 到 NoSQL 的遷移，這正和向雲計算的遷移一樣重要。往後的文章還會嘗試解釋為什麼我認為 NoSQL 可能會是貴公司的正確選擇。不過本文我只是解釋我們選擇 Cassandra 作為我們的 NoSQL 解決方案的選擇。 免責聲明——如果你正在尋找一個捷徑來決定你的系統選擇，你必須要明白，這可不是一個詳盡而嚴格的比較，它只是概述了另一個初創團 隊在有限時間和資 源的情況下的邏輯。Cassandra 的血統是否預言了它的未來 我最喜歡的一個電腦工程師們用來找 bug 的謁語是「廣度優先於深度」。 這也許可能對那些解決技術細節的人來說很惱人，因為它暗示著如果他們只是看看的話，解決方法就會簡單很多（忠告：只對那些能夠原諒你的同事說這個）。我之所以給出這個謁語的原因在於，我發現，軟體工程問題中，如果我們強迫自己在進入某行程式碼的細節層面之前，先去看看那些較高層次的考慮的話，可以節省大量時間。 所以，在談論技術之前，我在做 HBase 和 Cassandra 之間的選擇問題上先應用一下我的箴言。我們選擇切換的技術結論可能已經可以預測了：Hbase 和 Cassandra 有著迥異的血統和基因，而我認為這會影響到他們對我們的商業適用性。 嚴格來說，Hbase 和它的支持系統源於著名的 Google BigTable 和 Google 檔案系統設計（GFS 的論文期刊被發佈於 2003 年，BigTable 的論文發於 2006 年）。而 Cassandra 則是最近 Facebook 資料存儲庫系統的開放源始碼分支專案，它在實作了 BigTable 的資料模型的同時，使用了基於 Amazon 的 Dynamo 系統架構來存儲資料（實際上，Cassandra 的最初開發工作就是由兩位從 Amazon 跳槽到 Facebook 的 Dynamo 電腦工程師完成的）。 在我看來，這些不同的歷史也導致 Hbase 更加適合於資料倉儲、大型資料的處理和分析（如進行 Web 頁面的索引等等），而 Cassandra 則更適合於實時(Real-Time, RT)事務交易處理和提供交互型資料。要進行系統研究來證明這個觀點超出了本文的範疇，但我相信你在考慮資料庫的時候總能發現這個差異的存在。 注意：如果你正在尋找一個簡單的證明，你可以通過主要 Committer(對參與專案程式撰寫並提交貢獻者之稱) 的關注點來進行驗證：大部分 HBase 的 committer 都為 Bing 工作（M$[Microsoft] 在去年09收購了他們的搜尋公司，並允許他們在數月之後繼續提交開放專案的程式碼）。與之對應，Cassandra 的主要 committer 來自 Rackspace，用來可以自由授權獲取, 支持先進且通用的 NoSQL 的解決方案，用以與 Google, Yahoo, Amazon EC2 等所提供的鎖定在專有授權的 NoSQL 系統解決方案的相互抗衡。Malcolm Gladwell 會說只是根據這些背景的不同就可以簡單地選擇了 Cassandra。不過這是小馬過河的問題。但當然，閉著眼睛就進行一個商業選擇是相當困難的…… 哪個 NoSQL資料儲存庫風頭更勁? 另一個說服我們轉向 Cassandra 的原因是我們社群中的大風潮。如你所知，在電腦科學平台行業裡，始終有著大者恆大的慣性——那些被普遍前景看好的系統平台，會有更多人群聚在這個平台周圍，於是，從長遠來看，你可以得到更好的生態系統的支援（也就是說，大部分支援的軟體工程可以從該社群中獲取，並且也會有更多的開發者可以因此被僱傭）。 如果從 HBase 開始時，我的印象就是它後面有巨大的社群力量，但我現在相信，Cassandra 更加強大。最初的印象部分來源於 StumpleUpon 和 Streamy 的兩位 CTO 兩位非常有說服力的出色的演講者，他們是 Web 行業中兩個在 Cassandra 成為一個可選系統之前的 HBase 的兩個重要的貢獻者，同時也部分來源於閱讀一篇名為「HBase vs Cassandra： NoSQL 戰役！」的文章（大部分內容都己被廣泛證實了）。 勢力是很難被確證的，你不得不自己進行研究，不過我可以找到的一個重要的標誌是 IRC 上的開發者動向。如果你在 freenode.org 上比較 #hbase 和 #cassandra 的開發這頻道，你會發現 Cassandra 差不多在任何時候都有達兩倍的開發者在線上。 如果你用考慮 HBase 一般的時間來考察 Cassandra，你就能發現 Cassandra 的背後確實有非常明顯的加速勢力。你可能還會發現那些逐漸出現的鼎鼎大名，如 Twitter，他們也計劃廣泛使用 Cassandra（這裡）。 註：Cassandra 的網站看起來比 HBase 的好看多了，但認真的說，這可能不僅是市場的趨勢。繼續吧。 深入到技術部分: CAP 和 CA 與 AP 的神話 對於分散式系統，有個非常重要的理論（這裡我們在討論分散式資料庫，我相信你 注意到了）。這個理論被稱為 CAP 理論，由 Inktomi 的 聯合創始人兼首席科學家 Eric Brewer 博士提出。 這個理論說明，分散式（或共享資料）系統的設計中， 至多只能夠提供三個重要特性中的兩個——一致性(C)、可用性(A)和容忍網路分區(P)[Consistency, Availability and tolerance to network Partitions.]。簡單的說，一致性指如果一個人向資料庫寫了一個值，那麼其他使用者能夠立刻讀取這個值，可用性意味著如果一些節點(Node)失效了，叢集(Cluster)中的分散式系統仍然能繼續工作，而容忍分區意味著， 如果節點被分割成兩組無法互相通信的節點，系統仍然能夠繼續工作。 Brewer 教授是一個傑出的人物，許多開發者，包括 HBase 社區的很多人，都把此理論牢記在心，並用於他們的軟體系統設計當中。事實上，如果你搜尋網路上攸關於 HBase 和 Cassandra 比較的文章，你通常會發現，HBase 社群解釋他們選擇了 CP，而 Cassandra 選擇了 AP ——毫無疑問，大多數開發者需要某種程度的一致性 (C)。 不過，我需要請你注意，事實上這些生命基於一個不完全的推論。 CAP 理論僅僅適用於一個分散式演算法（我希望 Brewer 教授可以統一）。但沒有說明你不能設計一個超出理論的系統，並在其中各種操作的底層演算法選擇上進行特性切換。所以，在一個系統中，確實一個操作職能提供這些特性中的兩個，但被忽視的問題是在系統設計(SD)中，實際是可以允許調用者來選擇他們的某個操作時需要哪些特性的。不僅如此， 現實世界也非簡單的劃分為黑白兩色，所有這些特性都可以以某種程度來提供。這就是 Cassandra。 這點非常重要，我重申：Cassandra 的優點在於你可以根據具體情況來選擇一個最佳的折衷，來滿足特定操作的需求。Cassandra 證明，你可以超越通常的 CAP 理

服務導向架構(Service-Oriented Architecture, SOA) 的發展不同以往的IT企業架構的變遷, 多數IT人在未深入了解SOA的同時, 大多以舊經驗的推論, SOA不過是一時潮流的"新名詞", 但仍僅是舊瓶新裝的IT技術; 相反的從2004年至今, SOA持續的發展著, 甚至在許多的業界間產生了技術抽象的共識, SOA相關的規範標準與發展制定的組織也逐漸邁入完善, SOA的理論研究發展也逐漸由學術研究教育體係做為深根, 在國外甚至除了不少專業著作不斷發表, 專以SOA為主題的期刊雜誌也已有一段時日, 業界大廠們也朝向符合相關標準規範來實作自家產品, 對於身為開發者的我們, IDE(整合開發環境)對於SOA技術面的支持不斷強化且便利性也持續的增加.

我們合理的預期, SOA不同以往的IT技術發展, 不再只是一時的潮流, 不再僅是特定或是一群業界封閉性的合作結果; 相對的在眾多的規範與開放組織發展下, 企業架構及系統分析與設計模式將趨向SOA來調整發展, 本篇僅就SOA標準規範與組織做一簡要介紹：

網際網路聯盟聯盟(W3C)

• SOAP 1.1 / 1.2
• http://en.wikipedia.org/wiki/SOAP
  
• WSDL 1.1 / 2.0
• http://en.wikipedia.org/wiki/Web_Services_Description_Language
  

結構化資訊標準促進組織(OASIS)

• http://www.oasis-open.org/home/index.php
• SOA 委員會清單：http://www.oasis-open.org/committees/tc_cat.php?cat=soa
  
• 簡體中文: http://www.oasis-open.org/cn/
  

開放SOA合作組織(OSOA)

• Open SOA (OSOA)
  
• SCA 1.0
  
• In March 2007, a set of Final V1.0 Specifications
• SDO 2.1
  

Web服務相互操作性組織 (WS-I)

References

• http://en.wikipedia.org/wiki/World_Wide_Web_Consortium
• http://en.wikipedia.org/wiki/OASIS_(organization)
• http://en.wikipedia.org/wiki/Web_Services_Interoperability
  

The OSOA Collaboration

本文來自 中山資訊管理所-SOA論文研究協作平台, 更多參考請見：
[分享製圖] SOA(服務導向架構)簡要歷史演進與特點
更多的老魚 SOA 筆記請轉見:
http://sites.google.com/site/javacodelibrary/process-management-in-service

柔勝剛，弱勝強。魚不可脫於淵。國之利器，不可以示人。
- 道德經 第三十六

柔弱者性情平和，行事寬恕，剛強者反之，故柔能勝剛，弱能勝強也。
魚必須深藏水底下，魚離水則死，所以不可脫於淵。
國家有價值之厲害武器 的實力，不可以顯露給人知道，顯露則被敵人知其底細，
必敢來侵犯，不可隨便誇張貢高。

SOA, 服務導向架構(Service Oriented Architecture),
是老魚近來準備開工的實體讀書會之一並伴隨著參與者們的研究論文主題發展,
這嚴格來說已不是新的IT發展, 正反二極的看法, 這幾年來有正有負,
但站在研究者的立場, 任何一個新IT的提出, 必有可取之點~

下圖是張很草率但易懂的圖, 但也可能存在點小偏見, 歡迎大家一同討論.

SOA.History.Featurs (點圖放大後再下載)


更多的老魚 SOA 筆記請轉見:
http://sites.google.com/site/javacodelibrary/process-management-in-service