首頁 培訓計劃 培訓課程 企業內訓 學員論壇 技術文章 成功案例 師資簡介 關于我們 在線留言  
行業新聞
FriendFeed實現基于MySQL的無模式存儲

文章來源:http://www.kuqin.com/database/20090406/44396.html 作者: 發布日期:2009-12-25
打 印】【關 閉

對于迅速增長的網站所遇到的問題——“用靈活的模式存儲數據、即時創建新的索引”,FriendFeed的Bret Taylor介紹了一種“無模式的解決方案” 。問題本身源自一些需求:需要不斷增加新功能,不斷更新底層的數據庫結構和數據庫中存儲的數百萬條已有記錄,還要同時支持新舊功能。FriendFeed的辦法是基于MySQL建立一個無模式的解決方案,而不是遷移到別的技術基礎上去。Bret描述了基本問題:

尤其是有一兩千萬行數據的時候,每次修改模式、往數據庫中添加索引都會數小時完全鎖定數據庫。刪除舊索引也需要同樣長的時間,但不刪除又會影響性能,因為數據庫在每次執行INSERT操作時都會繼續讀寫這些不用的塊,而重要的塊卻沒有足夠的內存。經過一些復雜的操作過程可以克服以上困難(比如在從機上創建新索引,然后調換從機和主機),但這些操作過程都很容易出錯,也都是重量級的,因此會使我們因為害怕改變模式/索引而不敢增加新功能。由于我們的數據庫都是嚴重分片的,像JOIN這些MySQL的關系型功能對我們毫無用處,所以我們決定看看RDBMS之外的領域。

研究了幾個可行的解決方案后,他們決定基于MySQL的自定義一種“無模式”持久化方案,而不是徹底改換門庭。

他們的解決方案是把主要數據和這些數據的索引分離開來。“我們的數據存儲儲存了無模式的屬性包……我們在單獨的MySQL表中存儲索引,從而在這些實體中索引數據。”這是以容量來換效率。

結果我們比以前多了很多的表,但添加和刪除索引卻很容易。我們大力優化了填充新索引的進程(我們稱之為“Cleaner”),以便該進程能快速填充新索引,而不會讓站點中斷。

分離數據和索引引起了一致性和原子性問題。他們沒有建立嚴格的事務規則,而是把數據庫表推到最簡,索引只用來引用,發生實際的數據庫讀操作的時候才施加數據過濾。他們改進了持續更新表的自動化進程,讓這個“Cleaner”進程不停地對優先級高的被更新實體進行更新和索引修正。盡管可能出現不一致,但消除不一致的時間平均不到兩秒鐘。

Bret用平均頁面延遲這一指標描述了以下走向。

  • 整體來說——盡管有增加的趨勢,但還是有顯著的減少。
  • 過去二十四小時——即使在高峰時段也保持穩定。
  • 前一周——明顯減少。

Bret的帖子有很多回復。有一種觀點認為“對于模式演變,現代的RDBMS不像MySQL局限那么大”,這種觀點忽略了選擇背后的成本問題。其它讀者則回復了更多種不同的解決辦法。

有意思的是,并沒有人指出FriendFeed的解決方案與古老的ISAM技術(Indexed Sequential Access Method,索引順序存取法)之間的相似性。ISAM用的是同樣的基本架構——分離數據和索引,同時在數據發生變化時自動更新索引。

查看英文原文:FriendFeed Implements Schema-less Storage Atop MySQL
來自:http://www.infoq.com/cn/news/2009/04/friendfeed-schemaless-mySQL

打 印】【關 閉

上一篇:MySql數據庫查詢優化
下一篇:一個時代的終結
相關新聞
版權所有©威課網 粵ICP備13058727號