Google GFS文件系统深入分析(1) 51CTO编辑注：本文是一篇论文，英文原文标题为The Google File System，在Google Labs上公布，由blademaster.ixiezi.com的博主Alex翻译为中文，Google GFS文件系统。 现在云计算渐成潮流，对大规模数据应用、可伸缩、高容错的分布式文件系统的需求日渐增长。 Google根据自身的经验打造的这套针对大量廉价客户机的分布式文件系统已经广泛的在Google内部进行部署，对于有类似需求的企业而言有相当的参考价值。 摘要 我们设计并实现了Google GFS文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。 GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。 虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处，但是，我们的设计还是以我们对自己的应用的负载情况和技术环境的分析为基础的，不管现在还是将来，GFS和早期的分布式文件系统的设想都有明显的不同。 GFS完全满足了我们对存储的需求。 在本论文中，我们展示了能够支持分布式应用的文件系统接口的扩展，讨论我们设计的许多方面，最后列出了小规模性能测试以及真实生产系统中性能相关数据。 常用术语 设计，可靠性，性能，测量 关键词 容错，可伸缩性，数据存储，集群存储 1. 为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统(Google File System – GFS)。 首先，组件失效被认为是常态事件，而不是意外事件。 其次，以通常的标准衡量，我们的文件非常巨大。 第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。 第四，应用程序和文件系统API的协同设计提高了整个系统的灵活性。 Google已经针对不同的应用部署了多套GFS集群。 Distributed Key-Value Database. 這篇是因為在 PIXNET 內講了 n 次，決定寫成文字，至少之後新人進來可以說「就看這篇」，避免整套系統都需要重新講一次。 對了，補充一下，PIXNET 還是有缺人，參考「缺人找人」這篇的內容，如果有想問的細節，可以寫信問我。
資料庫 在 RDBMS 提供了很多而且很豐富的操作方式，但當資料量愈來愈大時，會遇到單台機器的網路頻寬有限以及空間有限。 這時候一定得走向多台的架構。 Replication 最容易解決的情況是「讀取的 query 比寫入的 query 多」，可以用 database replication 解決，這也是 Web 1.0 網站常見的解法之一 (另外一種常見的解法是使用靜態檔案，或是 reverse proxy cache)，同步將資料複製到多台。 Memcached 接下來會發現當 slave 過多時會造成每台記憶體內重複 cache 相同的元素，也就是說，有二十台 slave，每台都有 SELECT * FROM `user` WHERE `name` = 'gslin' 的結果其實很浪費資源。 Sharding 在 Web 2.0 的環境裡，User generated content 成為主流，當寫入的 query 超過單台可以負荷的量時，replication 的架構就不是很適合了，因為每個寫入的 query 在其他台 slave 上也會被執行。 比較常見的解法是 sharding：依照 id，把資料拆散到各台。 但 sharding 就會少了很多 RDBMS 可以用的特性 (JOIN 與 transaction)，在寫 application server 或是 library 的時候得花功夫多下幾次 query，並且注意資料的正確性。 上面這些方法在 2005 年 Brad Fitzpatrick (LiveJournal founder、memcached 作者) 的投影片「LiveJournal’s Backend: A history of scaling」都有提到。
Sharding 是一個解法，但有不少缺點： 需要 application server 或是 library，否則 3rd party 程式得清楚知道 sharding 的架構，才會知道資料要到哪個 cluster 找。 Key-Value Database 大致上是這樣。 Alex && OpenCould » Bigtable：一个分布式的结构化数据存储系统[中文版] Ken Yang 筆記: Android C2DM (一)：元件參數說明. [AppEngine] 實戰 Datastore (1) | ericsk.NET. 其實這些都可以在官方文件及 Google IO 的 slides 裡找到，不過我就幫大家整理一下（並且用中文說 XD）。 Google App Engine 帶給大家一個新的資料儲存概念，就是 Datastore 這個東西，它跟一般的關聯式資料庫（RDB）的概念相差不少，從官方文件或是 Google 工程師的演講中都不斷強調要大家用新的思維去想這個資料儲存方式，而不要一直侷限於怎麼把 RDB 的那一套搬過來。 不過好在 Datastore API 在描述資料的 Model 或 Expando 的資料欄位上提供了不少好用的資料型別（data type），所以一些常用的關聯還是很容易可以完成。
這篇就介紹幾個常用的關聯，在 Datastore 上要怎麼下手。 One-to-One & One-to-Many 通常會用到這個關聯，就是 A model 中有個 column 的值可能是一個串列，在 RDB 中我們可能就會再建立一個 B model，然後在 B 中設下一個 A_id 的 column 用來指向 A 的某個 row，但是在 Datastore 中沒有 join 運算，所以得換個方法來做。 假設我在建立一個通訊錄的 Model，一個人可能會有很多 E-Mail，我的 model （在 Datastore 中）就可以寫成這樣： class User(db.Model): name = db.StringProperty(required=True) class Email(db.Model): user = db.ReferenceProperty(User, collection_name='emails') addr = db.EmailProperty(required=True) mail_type = db.StringProperty() 在 Email model 中，用了一個 Reference 型別的欄位，用來表示這個欄位是 reference 到 User 這個 model，並且在 User 下建立一個集合，名為 emails，用來表示所有的 references。
所以我在建立 Entity 的時候就可以這樣做： ericsk = User(name='Lin-Chieh Shangkuan') ericsk.put() Many-to-Many 參考文獻： 發表 App Engine 的 High Replication Datastore. Google App Engine (04) - Datastore. 伺服器廣播程式範例 - 國立金門大學 九十六學年度資訊工程學系專題 Android教學範例. If you want to discuss contents of this page - this is the easiest way to do it. Click here to edit contents of this page. Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available. Append content without editing the whole page source. Check out how this page has evolved in the past. View and manage file attachments for this page. A few useful tools to manage this Site.
Change the name (also URL address, possibly the category) of the page. View wiki source for this page without editing. View/set parent page (used for creating breadcrumbs and structured layout). Notify administrators if there is objectionable content in this page. Something does not work as expected? General Wikidot.com documentation and help section. Wikidot.com Terms of Service - what you can, what you should not etc. Wikidot.com Privacy Policy. This wizard will create an empty table with the specified properties: This wizard will create an URL (web address) link: 手機連線程式範例 - 國立金門大學 九十六學年度資訊工程學系專題 Android教學範例. If you want to discuss contents of this page - this is the easiest way to do it.
Click here to edit contents of this page. Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available. Append content without editing the whole page source. Check out how this page has evolved in the past. View and manage file attachments for this page. A few useful tools to manage this Site. Change the name (also URL address, possibly the category) of the page. View wiki source for this page without editing. View/set parent page (used for creating breadcrumbs and structured layout). Notify administrators if there is objectionable content in this page. Something does not work as expected? Wikidot.com Terms of Service - what you can, what you should not etc.
This wizard will create an empty table with the specified properties: This wizard will create an URL (web address) link: Malformed URL elements will not be parsed by the wiki engine. PaperReading: Bigtable: A Distributed Storage System for Structured Data @ [todo Austin] 奧斯丁。土豆 :: 痞客邦 PIXNET :: Google App Engine 之 Python 與 BigTable. 上星期 5 (2008/06/27) 從朋友那裡得知有「Google App Engine」這個新的服務後，就開一連串對這個新服務的研究與測試。
結果發現使用 Python 的問題不算大，而 BigTable 這個非關聯資料庫對於已經熟悉傳統關聯資料庫開發的技術人員來說，應該才是個真正的門檻。 首先來說說 Python。 在這次研究「Google App Engine」之前，我對 Python 的瞭解都只限於「是一種直譯式程式語言，跟 JAVA 有點像，可以用於 WEB 與 APPLICATION」，直到這次才有機會比較深入的去試試看 Python 到底是個什麼東西。 我得到 3 點心得： 1.結構鬆散因為我一直都習慣使用 C 與 C++，而網頁程式也大都使用 PHP 開發，因此 Python 給我的第一個感覺是「很鬆散」...Python 並沒有像 C 語言的大括號 { } 可以用來切割程式碼的層級，因此只要程式碼比較長一點或是層級比較多一些，閱讀上就會變得很吃力... 2.格式限制Python 的每個層級「一定」要用「兩個空格」做間隔，多了或少了都不行！ 這對於程式設計師來說真是個惡夢！ 3.其實沒那麼難基本上只要會寫 PHP 5(物件導向)、C++ 或 JAVA 的人，對於 Python 應該都會能夠快速的上手，因為 Python 用起來的感覺是「十分簡化後的 C++」，因此要使用「Google App Engine」這個服務的門檻其實沒有想像中的這麼高。
再來講講 BigTable。 這是我第一次聽到 BigTable 的名號，雖然經過閱讀一堆文件之後發現 Google 的很多產品都是使用這個資料庫，例如有名的 Google Analizy、Google Earth....等等，真是一個令人驚訝的事實阿！ 而這更是我第一次接觸「非關聯式資料庫」，其實也不能這樣說，因為又經過閱讀一堆文件之後，我發現其實「非關聯式資料庫」的典型就是 EXCEL...也就是說，只要用過 EXCEL 的人，都可以自稱使用過「非關聯式資料庫」，只是使用深度上的差異罷了。 我得到以下 3 點心得： 因此 BigTable 的設計，就像是一個「超大號」EXCEL 工作表，每一筆資料擁有超多的欄位。
2.不用 JOIN 好像也不錯因為 BigTable 就像是 EXCEL 一樣，所以沒有 JOIN 這一回事！ Google App Engine 價位調整 - 2011. Google 最近將 GAE 的價位做了調整, 價位如此頁: Google App Engine - Pricing and Features , 但是光看此頁並不會有任何感覺. Google App Engine 價位調整 整理 有聽到不少哀號聲, 但是直接看 Dashboard 好像都沒有什麼變化, 就先不理他了. 沒想到昨天收到通知信, 說我需要去重新調整 Budget, 因為使用量超過, 再仔細查看後, 看到價位後, 會想是不是看錯了, 還要確認這是寫台幣還是美金. 價位調整前的價格: 價位調整後的價格: 註: 這個價格是1天, 美金計價. 看到兩者最大的差別是在把 CPU time 拿掉, 換成 Frontend Instance, 然後這個大爆炸. 除此之外, 另一個最嚴重的是 Datastore Write / Read, 直接在 Dashboard 看到如下: Datastore Write Operations - 0.05 of 0.05 Million OpsDatastore Read Operations - 0.05 of 0.05 Million Ops 依照這種算法, 一天對 DB 的讀寫操作只能 5萬次, 這個在一般 RDBMS 看起來好像還好, 但是這是 key-value 的 nosql DB, 5萬次有給跟沒給差不多意思.
舉個例子來說, 假設是個 Blog 站, 首頁一次列 10篇文章 在加上其他的也算 10就好了, GAE 至少就要拉 20次, 所以 PageView 2500 就爆表了, 而這個價位也不便宜就是了. 結論 我的一個小玩具, 就可以一天花近 1000台幣, 光 DB 的部份, 一天可以花掉 150元以上的台幣, 這價位夠我在 Linode 租 Linode 4096 都還有找. 明天準備開始改寫, 逃離 GAE 的時候到了~ 註1: 如果要逃離到 Linode 的, 麻煩點此 連結 註冊使用 或 referral code 填 792730073953138769a6560468890d410e408bf9 註2: GAE 之前一天 1.69, 現在一天 29.5 - 這篇討論中, Hank 有教導如何設定 Idle Instances, 可以減少一點 Frontend Instances 的價位.
相關網頁. Cloud services – App Engine.
For python.