聚會時間公告: 因應COSCUP 2011, Kalug 8月份休會一次

四月 28, 2010
» [雲端計算] NOSQL 背後的共通原則

同樣的這篇文章, 也是老魚從簡體中文譯者那“借來”的, 除了加工再潤詞成正體中文(當然也用紅筆自行畫了重點~呵), 在文中作者提到了 Google 檔案系統論文中最初的設計基礎, 建立在“硬體與網路的失效(Failure)是必定會發生的!”, 這才是一個真正的世界, 大多的 NOSQL 實作可分為二大觀點, 重視使用硬碟, 抑或盡可能的利用 RAM做為一級存儲, 作者也進行了比較說明, 本文中對於想進入 NOSQL 技術領域者, 可以視為一篇入門文選, 所以老魚在此分享本文給各位. Wikipedia - NOSQL, http://en.wikipedia.org/wiki/NoSQLNOSQL Database ORG, http://nosql-database.org/原文: http://natishalom.typepad.com/nati_shaloms_blog/2009/12/the-common-principles-behind-the-nosql-alternatives.html Posted by Nati Shalom at 12:01 PM Dec 15, 2009 譯文: 王旭(http://wangxu.me , @gnawux)2009年12月 16/19日 簡體轉正體中文及校潤詞句:郭朝益(http://wisdomfish.org, @master) 幾個星期之前,我寫了一篇文章描述了經常被稱作 NOSQL 這一類新型資料庫的背後需求動機。幾個星期之前,我在 Qcon 上發表了一個演講,其中,我介紹了一個 可伸縮性(scalable)的 Twitter 應用的構建模式,在我們的議論中,一個顯而易見的難題就是資料庫的 規模可伸縮性(scalability)。要解答這個問題,我試圖尋找隱藏在各種 NOSQL 背後的共通模式,並展示他們是如何解決資料庫規模可伸縮性問題的。在本文中,我將盡力勾勒出這些共通的原則。 實作者們的共通原則 假設失效是必然發生的 Assume that Failure is Inevitable 與我們在此之前認知通過昂貴硬體之類的手段,盡力去避免失效的手段不同,NOSQL 實作都建立在硬碟、機器和網路都會失效(Failure)這些假設之上。我們有需要承認,我們不能徹底阻止這些失效,相反,我們需要讓我們的系統能夠在假使非常極端的條件下也能應付這些失效。Amazon S3 就是這種設計的一個好例子。你可以在我最近的文章 Why Existing Databases (RAC) are So Breakable! 中找到進一步描述。在那裡,我介紹了一些來自 Jason McHugh 所講演的以"失效"為導向的架構設計內容(Jason 是在 Amazon 做 S3 相關工作的高階工程師)。 對資料進行分區 Partition the Data 通過對資料進行分區(分割),我們最小化了失效帶來的服務失效影響,也將讀寫操作的負載分佈到了不同的機器上。如果一個節點(Node)失效了,只有該節點上存儲的資料受到影響,而不是全部的資料。 對同一資料保持多個副本 Keep Multiple Replicas of the Same Data 大部分 NOSQL 實作都基於資料副本的熱備份(hot-backup)來保證連續的高可用性(high availability)。某些實作產品提供了 API,可以控制副本的複製,也就是說,當你存儲一個物件的時候,你可以在物件級別指定你希望保存的副本數量。在 GigaSpaces,我們還可以立即複製一個新的副本到其他節點,甚至在必要時啟動一台新機器。這讓我們不必在每個節點上保存太多的資料副本,從而降低總存儲量以節約成本。 你還可以控制副本複製是同步(synchronous)還是異步(非同步, asynchronous)的,或者兩者兼俱。這決定了你的叢集(Cluster)的一致性、可用性與性能[consistency, reliability and performance]三者。對於同步複製,可以犧牲性能保障一致性和可用性(進行寫入作業之後的任意讀取作業都可以保證得到相同版本的資料,即使是發生失效也會如此)。而最為常見的 GigaSpaces 的配置是同步副本到被分界點,異步存儲到後端存儲。 動態伸縮 Dynamic Scaling 要掌控不斷呈線性增長的資料量,大部分 NOSQL 實作提供了不停機或完全重建分區的擴展叢集的方法。一個已知的處理這個問題的演算法稱為一致性雜湊法(consistent hashing)。有很多種不同演算法可以實作一致性雜湊演算。 演算法會在節點加入或失效時 通知某一分區的鄰近節點。僅有這些節點受到這一變化的影響,而不是整個叢集。有一個協議用於掌控需要在原有叢集和新節點之間重新分佈的資料的變換區間。另一個(簡單很多)的演算法使用邏輯分區。在邏輯分區中,分區的數量是固定的,但分區在機器上的分佈式動態的。於是,例如有兩台機器和 1000 個邏輯分區,那麼每 500 個邏輯分區會放在一台機器上。當我們加入了第三台機器的時候,就成了每 333 個分區放在一台機器上了。因為邏輯分區是輕量級的(基於在記憶體中的雜湊表[hash table]),分散這些邏輯分區非常容易。 第二種方法的優勢在於它是可預測並且一致的,而使用一致性雜湊演算方法,分區之間的重新分佈可能並不平穩,當一個新節點加入網路時可能會消耗更長時間。一個使用 者在這時尋找正在轉移的資料會得到一個異常。邏輯分區方法的缺點是可伸縮性受限於邏輯分區的數量。 更進一步的關於這一問題的討論,建議閱讀 Ricky Ho 的文章 NOSQL Patterns 。 對查詢式的支持 Query Support 在這個方面,不同的實作有著本質上相當的區別。不同實作的一個共通性在於雜湊表中的 key/value 匹配。有些實作提供了更高階的查詢式支持,例如文檔導向(document-oriented)的方 法,其中資料以 blob 的方式存儲,關聯一個鍵值對屬性列表(List)。這種模型是一種無預定義結構的(schema-less)存儲,對一個文檔增加或刪除屬性是非常容易 地,無需考慮文檔結構的演變。而 GigaSpaces 支持很多 SQL 操作。假如 SQL 查詢沒有指出特定的鍵值(key),那麼這個查詢就會被平行地(parallel query) map 到所有的節點去,由客戶端完成結果的聚合(aggregated)。所有這些都是發生在系統後端的,使用者程式碼無需關注這些。 使用 Map/Reduce 處理聚合 Use Map/Reduce to Handle Aggregation Map/Reduce 是一個經常被用來進行複雜分析的模型,經常會和 Hadoop 聯繫在一起。 map/reduce 常常被看作是平行聚合查詢(parallel aggregated queries)的一種模式。大部分 NOSQL 實作並不提供 map/reduce 的內建支持,需要一個外部的框架來處理這些查詢。對於 GigaSpaces 來說,我們在 SQL 查詢中隱含了對 map/reduce 的支持,同時也顯式地提供了一個稱為 executors 的 API 來支持 map/reduce。在這模型中,你可以將程式碼發送到資料所在地地方,並在該節點上直接運行複雜的查詢。這方面的更多細節,建議閱讀 Ricky Ho 的文章 Query Processing for NOSQL DB 。 磁碟基礎 vs. 內部記憶體的實作 Disk-Based vs. In-Memory Implementation NOSQL 實作分為基於檔案的方法和在記憶體(RAM)中的方法。有些實作提供了混合模型,將RAM和磁碟結合使用。兩類方法的最主要區別在於每 GB 成本和讀寫(R/W)性能。最近,Stanford University 斯坦福的一項稱為「The Case for RAMCloud」的調查,對磁碟和 RAM 兩種方法給出了一些性能和成本方面的有趣比較。總體上說,成本也是性能的一個函數。對於較低性能的實作,磁碟方案的成本遠低於基於 RAM 的方法,而對於高性能需求的場合,RAM 方案則更加廉價。 記憶體型態雲端系統 (RAMClouds)最顯而易見的缺點就是單位容量的高成本和高電能耗損。對於這些指標,RAMClouds 會比純粹的磁碟系統差 50到 100倍,比使用快閃記憶體(flash memory)的系統差5-10倍(典型配置情況和指標參見參考文獻[1])。RAMClouds 同時還比基於磁碟和快閃記憶體的系統需要更多的機房面積。這樣,如果一個應用需要存儲大量的廉價資料,不需要高速存取,那麼,快閃記憶體將不是最佳選擇。 然而,對於要求高吞吐量需求的應用,RAMClouds 將更有競爭力。當使用每次操作的 成本和電能耗損作為衡量因素的時候,RAMClouds 的效率是傳統硬碟系統的 100 到 1000 倍,是快閃憶記體系統的 5-10 倍。因此,對於高吞吐量需求的系統來說,RAMClouds不僅提供了高性能,也提供了更高的效率。同時,如果使用 DRAM 動態記憶體晶片組提供的低功耗模式,也可以降低 RAMClouds 的電能功耗,特別是在系統閒置的時候。此外,RAMClouds 還有一些缺點,一些 RAMClouds 無法支持需要將資料在多個資料中心之間進行資料複製。對於這些環境,更新的時間延遲將主要取決於資料中心間資料傳輸的時間消耗

四月 24, 2010
» [雲端計算]HBase vs Cassandra: 我們遷移系統的原因

首先要跟各位聲明的, 這篇文章內容主要是老魚去申請轉載而來, 而我僅是用長年閱讀簡體中文詞彙的經驗加以正體中文和稍加校詞潤飾, 特別選這篇文, 有幾個目的: 老魚為一個新的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 理論的解讀

十一月 8, 2009
» [雲端計算]台灣區Hadoop使用者社群會議

老魚後天 11/10要北上新竹竹科的國家高速網路中心, 做為一位小主題的分享講者 - 台灣區 Hadoop 使用者社群會議, 在這廣邀大家一同到場分享您的心得, 與結交在場的愛好者. 雲端運算於海洋資訊之前瞻應用研習暨 第一屆台灣區 Hadoop 使用者社群會議 Cloud Computing for Advanced Ocean Research and Hadoop Taiwan User Group Meeting 2009 會議時間:九十八年十一月十日(週二) 會議地點:國家高速網路與計算中心 國際會議廳      (新竹市研發六路七號) 主辦單位:國家高速網路與計算中心 協辦單位:台灣海洋科技研究中心 報名網址:http://registrano.com/events/hadoop-tw 聯絡電話:王耀聰 (04)2462-0202 # 834    繼格網運算之後,雲端運算被視為下一代資訊架構的主流。雲端運算平台 Hadoop 及雲端資料庫平台 HBase 與 Hive 均是目前諸多雲端運算服務的基礎架構。Cloudera 是目前全球首先提供自由軟體 Hadoop 技術支援的商業公司,本次使用者會議特別邀請來自 Cloudera 的 Christophe Bisciglia 來跟我們分享如何運用 Hadoop 打造雲端應用程式與軟體服務,並分享自由軟體的可行商業模式:教育訓練與認證機制。此外,也邀請了國內推動 Hadoop 教學、軟體開發、社群建立的幾位同好來進行知識分享,包括:台灣雅虎、老魚研究室、國立台灣大學資訊工程學系通訊與多媒體實驗室與國家高速網路與計算中心雲端運算研究小組。希望透過此次會議,讓更多有興趣瞭解 Hadoop 的夥伴相互交流,進行凝聚出台灣區的 Hadoop 社群。     本會議不收取任何報名費用,歡迎各界踴躍參加。礙於此次會議場地座位有限,請速上網報名(http://registrano.com/events/hadoop-tw),額滿為止。也請大家代為宣傳(議程PDF版)。

十月 16, 2009
» [書摘心得分享] Google 衝擊 (Planet Google) (一)

夫未戰而廟算勝者,得算多也﹔ 未戰而廟算不勝者,得算少也。 多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。 - 孫子兵法第一始計篇 這個學期, 老魚要做 Google 不少相關的報告, 也找了不少本參考書, 內容寫的還不錯, 一邊整理, 一邊也陸續分享資訊和整理給各位 ... Google 衝擊 Planet Google:One Company’s Audacious Plan to Organize Everything We Know http://www.books.com.tw/exep/prod/booksfile.php?item=0010436333 (老魚對文章標記了不同顏色字來提醒留意處 ...) 推薦文一 - 離答案最近的地方 數位時代總主筆 王志仁 Google是二十一世紀頭十年最有代表性的企業,從每年營收和獲利翻倍成長,到品牌價值和市值快速竄升,完全不像一家成立剛滿十年的公司,而這股動能和奇蹟,極可能讓它在第二個十年繼續獨領風騷。 全世界超過半數的上網者,都是google的用戶,它把「搜尋引擎」這個詞變得廣為人知,建立起一整片產業,以關鍵詞廣告幫網路業找到新的商業模式,在泡沫後重新站起。Google成為一個動詞,縮短了每個人的腦海裡的疑問到答案之間的距離。 「上網Google一下」,表示一種新的生活和工作型態,可以是去查天氣、餐館地址、拿破崙出生於那一年、某一個失散多年的大學同學的近照、或者最近要去面試的那一家公司的介紹。當然,最常見的是輸入自己名字,按下enter鍵,看看網路上有那些關於你的消息在流通。 所有這些查詢都是免費,而google又能賺到大錢,因為廣告主樂於在上面購買關鍵詞廣告,隨著被某一位用戶輸入這個關鍵詞查詢時,跟著在頁面右方出現,而且是被點擊之後才收費,用行業術語叫精準投放。另一方面,你個人、公司或機構的網站,要重新規畫,以利於在Google上被查詢時,在出現的頁面上能靠前,更容易被看到。 隨著我們進入後工業社會,或者稱為資訊社會,我們工作當中有愈來愈高的比例,是在生產和取得資訊,而google的企圖,是把全世界公開的資訊組織起來,經由它的分類和檢索,讓這些海量的資訊更容易被查詢,大幅降低取得資訊的門檻。甚至,針對那些未公開的資訊,比如存在各地圖書館的幾千萬本藏書,Google也在努力將之轉化為網頁,納入被查詢的範圍。 不管是人、事、地、物,只要你想知道的資訊,Google都能提供,而且出現的形式不只在電腦上,手機上也可以,下一步則是在任何可以上網的工具上。當Google愈強大,我們能享受的便利性也愈高,「如何使用Google」很快會成為一門課,是更多初學者學會用電腦和上網的理由,很可能從小學就要開始教,這是改變「死讀書,讀死書,讀書死」的硬式教育的一步,讓Google成為小孩子的另一位老師,只要你懂得問問題。 但是,Google愈強大,我們就愈擔心,當這件事牽涉更多公眾利益和公共領域的時候,是誰來授權給Google?誰又來制衡它?當你家的住址可以在網路上查到,房子和街道外觀可以透過衛星圖顯示的時候,個人隱私和公眾利益之間的那條線,誰來劃分?任何在Google上查不到或排序在很後面的資訊,就等於不存在,但誰有權決定Google的排序方法? 這些問題暫時在Google上都找不到答案,但有助於我們理解它所帶來的衝擊。解決資訊不對稱,讓每個人都能公平而有效率地取得資訊,是這家公司最初成立的使命,在這一點它做得很好,並藉此而更加了解我們每一個人:你最常查詢那些詞?最近點擊那些頁面?但我們對它的了解卻很有限,這是新的資訊不對稱。要解決這個不對稱,透過《Google衝擊》這本書是一個開始。 推薦文二 - 我們在塑造Google經驗時,也在被Google塑造 美商Trane公司新事業發展總監 黃逸華 在網路發展史上,Google絕對是一家不容錯過的企業,更是不容忽視的現象。《Google衝擊》一書將帶你一窺其中奧妙。   Google字源來自數學名詞Googol,意謂著很多個零(10的100次方),官方說法是,希望能夠搜索到如此之多的網頁數量,另一個以訛傳訛的不經之談則是,天使投資人簽下支票之際,轉身問了兩位創辦人該署名給哪家公司?創辦人在驚喜之際,隨口說出,「怎麼這麼多零?(what a googol!)」。   不管哪種說法才是事實,在資金與知識的累積上,Google都正快速地向這個目標前進,並把所有的對手都遠遠拋在腦後。微軟公司--上個世代的典範企業--雖然還保有些許領先,但眼看著少年家快速追趕上來,即便努力邁開腳步,但也難免氣喘吁吁了。這是google對業界的衝擊。   二○○四年時,Google創下了八十億個網頁索引的紀錄之後,便不再公佈紀錄。經過五年之後,Google已經是地球上「儲存」最多資訊的公司,或至少是「認識」最多人類知識的公司。從我個人觀點,我認為Google充分詮釋了這個世代的核心觀念:「連結」、「互動」、「快速」、「精準」,而商機也正存在於這些元素的彼此碰撞與反應之中。這是google對商業的衝擊。   從搜索到DNA序列,從古書到社交網站,Google似乎無所不在,而且還將繼續擴大。傳播大師麥克魯漢(Marshall McLuhan)在提出科技決定論時,曾經指出,「我們塑造工具,工具也反過來塑造我們」,「因為傳播模式足以形塑人類經驗。」這句話放在Google身上一樣適合。我們開始習慣說「google一下」,雖然官方苦口婆心用盡方法解釋Google不是動詞,不希望Google之名被大眾如此使用 。但不能忽略的事實是:我們開始習慣在約會之前,先查一下對方背景、我們開始在吃飯之前,先看看網路有無惡評、我們甚至把自己的名字打進那行著名的長格,看看自己是不是和什麼奇怪的字眼或新聞連在一起。毫無疑問地,Google已經成為現代人生活經驗的重要成分,而當我們在不斷用滑鼠點擊塑造Google的同時,我們又被Google塑造成更加渴求資訊的動物。這又是Google對人類文明的衝擊了。   宛若科幻電影裡的終極武器,每當Google啟動,整個宇宙就要震盪一次。這樣的衝擊裡,如果你是攻擊的一方,恭喜你,但也請你把握每次機會,不斷緊跟Google腳步向前衝。如果你是防守的一方,雖然為你捏把冷汗,但更請好好看清楚Google前進的方向,衝擊過後,一定還是會有些美妙的事情發生。 結語 - 三百年的雄心壯志   Google還沒遇到真正的考驗,例如,核心廣告事業遭逢嚴重動盪和下滑、或其中一項大「賭注」演變成大敗筆等。如果它身陷上述這類逆境,仍能不減雄心壯志,重申它組織全世界資訊的承諾,那麼,它便能繼續邁向下一個里程碑。   Google的崛起,是因為微軟的衰落。事實上,沒有一家電腦公司能連續在兩個科技世代中享有如此卓越的成就。即使大型電腦年代的IBM,也無法阻止迷你電腦年代的迪吉多電腦公司興起,同樣地,迪吉多電腦也無法阻止個人電腦年代的微軟崛起。比爾.蓋茲及其同儕充分意識到這段歷史的意義,希望能時時自我警惕,並藉由明智的管理模式,讓微軟成為第一家能於接續個人電腦年代而至的任何世代(無論稱之為什麼年代)維持領導地位的業者。   當網際網路從大學及研究室逐漸傳播開來,並滲透到商業世界後,第一家讓微軟感受震撼教育的挑戰者就是以瀏覽器起家的網景公司。然而,網景因為資金不充足,兩三下便被三振出局,不足為懼。隨之而來的Google卻成功地將微軟逼向一個處處防守的姿態。   Google原有可能將市場優勢地位拱手讓給另一家公司,一家即是創立於網際網路年代早期的公司:雅虎。它是較可能的候選人,它在早於Google創立時的那段時間,便已經在成長方面取得先發的有利地位。不過,由於仰賴勞力密集模式組織網頁,雅虎無法跟上網際網路成長的速度,將原來早先的領先地位平白讓給Google這家與雅虎有網頁搜尋引擎技術合作協定的小小公司。   Google的成長速度之所以能跟得上網際網路世界的脈動,是因為其硬體與軟體技術的設計係採取可以快速升級且成本低廉的方法。同時也因為它能提供與搜尋關鍵字相關的文字廣告連結,讓廣告成為廣告主爭取潛在買家最有效率的工具,因而它也能取得超過所有其他所有網際網路公司的市場資本額。到了二○○七年,它擁有充分的制高點得以成功推出兩項跨產業聯盟的服務:針對社交網站的「OpenSocial」,以及針對行動電話業者的「Open Handset Alliance」。這兩項聯盟皆能在創立前六個月內成功聚集許多合作夥伴,且看似可能大幅重塑它們各自所屬的產業。這可說是非常重大的成就。   然而,Google一路走來一直無法公開確認自己可能吸引最多美國網路訪客造訪其網站。出道之初,它只是一個指點用戶到其他地方的網站。Google相當自豪自己可以依據線上網路訪客的搜尋關鍵字,快速導引他們到最適合的網站。後來,當它增加其他資訊服務類別後,它成了目的網站(destination site)。值此同時,Google的網際網路前輩們,例如:雅虎、MSN及美國線上,都紛紛成為能提供各式各樣資訊的綜合性入口網站。它們也都發展出相當受歡迎的電子郵件服務,時間都比Google的Gmail早。因此,在美國,無論哪一個月份,Google這些的競爭對手都能吸引比Google更多網路訪客造訪它們的網站。 登上美國搜尋引擎人氣冠軍寶座  二○○八年四月是該公司Google邁向跨越其發展史上一個重要里程碑的時刻,當月份,Google的美國線上網路訪客數超越所有競爭對手。全美一億九千零七十萬名線上網路訪客(不重複計算同一人重複造訪同一網站)中,Google吸引了其中的一億

support:

biggo.com.tw

A Django site.