老師提供課程mysql4cache與search

1、Cache Search 尋求數(shù)據(jù)庫本身之外的 Cache 和 Search 來解決數(shù)據(jù)本身的擴展性，已經成為目 Lucene MySQL 數(shù)據(jù)庫更好的結合，就有多種思路存在?？蒀ache Search 的數(shù)據(jù)通訊（數(shù)據(jù)更新），也可以在應用程序端直接實現(xiàn) Cache 與 Search 的數(shù)據(jù)更新。數(shù)據(jù)庫和 Cache 與 Search 可以處于整體架構中不合理利用第 Cache 解決方目前比較流行的第 Cache 解決方案主要有基于對象的分布式內存 Cache Memcached 和數(shù)據(jù)庫編程庫BerkeleyDB 這兩種。下面我將分別針對這兩種解決方 通信協(xié)議簡單，API Cache lib

2、event BSD 們重點看看如何通過 Memcached 來幫助Memcached Memcached 有一個Cache MySQL 數(shù)據(jù)庫Cache 如果僅僅只是系統(tǒng)通過Memcached 來提升系統(tǒng)性能，作為一個Cache ，那么 的是需要通過應用程序來 Memcached 中的數(shù)據(jù)與數(shù)據(jù)庫中數(shù)據(jù)的同步更新。這時候的 Memcached 基本可以理解為比 MySQL 數(shù)據(jù)庫更為前端的一個 Cache 層。如果 Memcached 作為應用系統(tǒng)的一個數(shù)據(jù)Cache 服務，那么對于MySQL 數(shù)據(jù) Memcached Cache INSERTUPDATE DELETE則需要在 UPDATE

3、或者 DELETE MySQL 中數(shù)據(jù)的同時，刪除 Memcached 中的數(shù)據(jù)，以此保 證整體數(shù)據(jù)的一致性。而所有的讀請求首先會發(fā)往 Memcached 中，如果到數(shù)據(jù)則直接返回，如果沒有到數(shù)據(jù)，則再到MySQL Slaves 中數(shù)據(jù)，并將得到的數(shù)據(jù)寫Memcached CacheMySQL 數(shù)MySQL 首先看看如何將 Memcached 和 MySQL 數(shù)據(jù)庫整一個整體來對外提供服務吧。一般來說，有兩種方式將 Memcached 和 MySQL 數(shù)據(jù)庫整一個整體來對外提供數(shù)據(jù)Memcached MySQL MySQL Server 的緩存大小，另一種是通過 MySQL 的 UDF 來和

4、Memcached 進行數(shù)據(jù)通信，和更新 Memcached 中的數(shù)據(jù)，而應用端則直接通過 Memcached 來數(shù)據(jù)。過對應用程序進行改造利用上數(shù)據(jù)庫之外的 Cache 的場景。目 Waffle Grid 就是需要借助的外部力量。IWaffle Grid 是國外的幾位 DBA 在工作之余突發(fā)奇想出來的一個點子：既然 PC Server 的低廉成本如此的吸引，而其ScaleUp 的能力又很難有一個較大的突破，何Memcached PCServer WaffleGrid MySQL Memcached雙雙開源的特性，結合 Memcached 通信協(xié)議簡單的特點，將 Memcached 成功實現(xiàn)成

5、為 MySQL 主機的外部“二級緩存”，目前僅支持用于 Innodb 的 Buffer Pool。WaffleGrid Innodb 據(jù)之前，先通過Memcached 的通信API 接口嘗試從Memcached 中相應的緩存數(shù)據(jù)（我們稱之為 Remote Buffer 吧），只有在 Remote Buffer 中也不存在需要的數(shù)據(jù)的時候， Innodb 才會磁盤文件來數(shù)據(jù)。而且，只有處于 Innodb Buffer pool 中的 LRUList 中的數(shù)據(jù)會被發(fā)送到 Remote Buffer Pool 中，而這些數(shù)據(jù)一旦被修改，就會 Innodb就會將之移入 FLUSH List ，Waff

6、le Grid 同時會將進入 FLUSH List 的數(shù)據(jù)從 Remote Buffer Pool 中清除掉。所以可以說，Remote Buffer Pool 中不會存在 Dirty Pages， RemoteBufferPool 出現(xiàn)故障的時候不會產生數(shù)據(jù)丟失的問題。下圖是使用 Waffle Grid 項目時候的架構簡圖： Memcached 服務器通信。為了保證網絡通信的性能，MySQL Memcached 之間盡可另外，這里的架構圖中并沒有再將數(shù)據(jù)庫區(qū)分 Master 和 Slave 了，并不是說一定不 Slave Waffle Grid 即可，Master 本身并不需要如此大的內存?？?/p>

7、了 Waffle Grid 的實現(xiàn)原理，可能有些讀者朋友會有些疑問了。這樣做不是所有需要產生物理讀的 Query 的性能就會受到直接影響了嗎？所有 Remote Buffer 的操作 Waffle 的實測數(shù) 下面再來介紹一下Memcached 和MySQL 的另外一種整合方式，也就是通過MySQL所提供的 UDF 功能，自行編寫相應的程序來實現(xiàn) MySQL 與 Memcached 的數(shù)據(jù)通信更新操WaffleGrid Memcached MySQL ，而是由應用程序和MySQL 一起來數(shù)據(jù)。每次應用程序從Memcached 數(shù)據(jù)的 Memcached MySQL Memcached 中數(shù)據(jù)的失

8、效清理工作，每次數(shù)據(jù)庫中有數(shù)據(jù)被更新或者被刪除的時候，MySQL UDF Memcached的 API 來通知 Memcached 某些數(shù)據(jù)已經失效并刪除該數(shù)據(jù)。如圖中所示，此架構和上面將 Memcached 完全和 MySQL 讀離開作為常規(guī)的 Cache 服 務器來比較，最大的區(qū)別在于 Memcached 的數(shù)據(jù)變?yōu)橛?MySQL 數(shù)據(jù)庫來更新，而不 是應用程序來更新。首先數(shù)據(jù)被應用程序寫入 MySQL 數(shù)據(jù)庫，這時候將會觸發(fā) MySQL 上面用戶自行編寫的相關 UDF，然后通過該 UDF 調用 Memcached 的相關通口，將數(shù)據(jù) MemcachedMySQL 中的數(shù)據(jù)被更新或者刪除的

9、時候，MySQL UDF 同樣會更新或者刪除 Memcached 中的數(shù)據(jù)。當然，也可以讓MySQL 做更少一些的事情，僅僅只是遇到數(shù)據(jù)被更新或者刪除的時候，通過 UDF 來刪除 Memcached 中的數(shù)據(jù)，寫入 由于 Memcached 基于對象的數(shù)據(jù)存取，以及通過 Hash 進行數(shù)據(jù)檢索的特性，所以所有在 Memcached 中的數(shù)據(jù)都需要設定一個用于標識該數(shù)據(jù)的 Key，所有數(shù)據(jù)的存Key MySQL Query 語句一樣通過 呼 Berkeley DB 了，那就姑且使用網上較為通用的叫法吧。Memcached 所實現(xiàn)的是內存式Cache，如果對性能的要求并沒有如此之高，在方面也不是太

10、充裕的話，還可以選擇 Berkeley DB 這樣的數(shù)據(jù)庫型 Cache ?？赡芎芏嘧x者朋友又會產生疑惑了，使用的 MySQL 數(shù)據(jù)庫，為什么還要再使用一個 Berkeley DB 這樣的“數(shù)據(jù)庫”呢？實際上 Berkeley DB 在之前也是 MySQL 的引擎之一，只不過后期不知道是何原因（獲取與商業(yè)競爭有關吧），被MySQL 從支持的引擎中移除了。之所以在使用數(shù)據(jù)庫的同時還使用 Berkeley DB 這樣的數(shù)據(jù)庫型 Cache，是因為 Berkeley DB 高效的鍵值對方式作為高效數(shù)據(jù)檢索的性能補充，以得到更好的數(shù)據(jù)服務Berkeley DB 自身架構可以分為五個功能模塊，五個模塊的

11、在整個系統(tǒng)中相對比較獨數(shù)據(jù)存取子系統(tǒng)主要負責最主要也是最基本的數(shù)據(jù)存與取的工作。而且 Berkeley DB 同時支持了以下四種數(shù)據(jù)的結果方式：Hash，B-Tree，F(xiàn)ixed Length 以及 DynamicLength。實際上，這四種方式對應了四種數(shù)據(jù)文件的實際格式。數(shù)據(jù)ACID 事務屬理共享 Cache 和 Buffer 的，為系統(tǒng)提升性能而提供數(shù)據(jù)緩存服務。日志系統(tǒng)主要服務于事務管理系統(tǒng)，為保證事務的一致性，BerkeleyDB 也采用先基于BerkeleyDB 的特性，很難像使用Memcached 那樣將他和MySQL 數(shù)據(jù)庫結 大多數(shù)時候都主要是使用Hash 和B-Tree 這

12、兩種結構的數(shù)據(jù)格式，尤其是Hash格式，在應用程序中，每次數(shù)據(jù)請求，都先通過預先設定的 Key 到 Berkeley DB 中取查找一將到的數(shù)據(jù)按照預先設定的 Key，整條存入 Berkeley DB 中，再返回給客戶端。而當MySQL BerkeleyDB 中的數(shù)據(jù)刪除。當然，如果您愿意，也可以直接修改 Berkeley DB 中的數(shù)據(jù)，但是這樣就可能 從原理來看，使用 Berkeley DB 的方式和將 Memcached 作為純 Cache 來使用差別不大嘛，為什么不用Memcached 來做呢？其實主要有兩個原因，一個是Memcached 是使用純內存來存放數(shù)據(jù)的，而 Berkeley

13、 DB 則可以使用物理磁盤，兩者在成本方面還是有較 大差別的。另外一個原因就是 Berkeley DB 所能支持的數(shù)據(jù)方式除了 Memcached 所使用的 Hash 格式之外，同時還可以使用其他格式，如 B-Tree 等。 Cache 還可以通過自行實現(xiàn)的 Cache 來達到完全相同的效果。要您不要一開始就希望作出一個能夠解決所有問題，而且包含所有其他第 Cache 自主研發(fā)實現(xiàn)Cache 服務的前提是系統(tǒng)中存在比較特殊的應用場景，通過自主研 技術實現(xiàn)可能會成為研發(fā)過程中很大的一個難點，能否有穩(wěn)定可靠的數(shù)據(jù)同步（）更新機制決定了該 Cache 最終的成敗。當然，你可以說數(shù)據(jù)同步（或異步）更新

14、完全一個Cache 的同時，還需要前端應用程序作出巨大的調整來適應這個Cache 是一千萬不要忽視了系統(tǒng)的成本，一個一旦開始使用之后，主要工作就是對其進行各種。如果可性太差，很可能帶來極大的工作量，甚至帶來一線應用Cache 服務基于不同的功能特性，可能會有不同的架構組成，但基本上和上面使用 Memcached 所使用的架構區(qū)別不大了，所以這里也就不再詳細了。 服務）的時候，應該盡可能將該Cache 與的MySQL 數(shù)據(jù)庫進行一定能做到后端數(shù)據(jù)服務（Cache）層在進行任何擴展的時候，影響到的僅僅只是中間 Search Memcached BerkeleyDB ，大多數(shù)時候都只能通過特定的方式

15、來 MySQL MyISAM 存 說的 Search（搜索引擎）對數(shù)據(jù)進行全文索引，才能達到較為高效的數(shù)據(jù)檢索效率。同樣，Search 的使用也有使用較為成第解決方案與自行研發(fā)兩種方式。目前最為有名的第解決方案主要就是基于Java 實現(xiàn)的Lucene，隸屬于Apache 基金 Jakarta 項目組下面的一個子項目。當然，他并不是一個完整的搜索引擎工具，而是這里我就不深入 Lucene 本身的技術細節(jié)了，感的讀者朋友可以通過 站點（）來了解也更為的細節(jié)。我這里主要是介紹一下 Luence 能夠給帶來什么，可以怎樣來使用他。由于Lucene 高效的全文索引和分詞算法，以及高效的數(shù)據(jù)檢索實現(xiàn)，完全

16、可以很好的利用這一優(yōu)點來解決數(shù)據(jù)庫和傳統(tǒng)的 Cache 完全無法解決的全文模糊搜索功能。 面的數(shù)據(jù)，只需要將數(shù)據(jù)庫中被持久化下來的數(shù)據(jù)通過應用程序調用 Lucene 的相關 API 寫入，并利用 Lucene 創(chuàng)建好索引，然后就可以通過調用 Lucene 所提供的數(shù)據(jù)檢索 API 得到需要的數(shù)據(jù)，而且可以進行全模糊匹配。由于從數(shù)據(jù)庫到Lucene 這一過程完Lucene 的數(shù)據(jù)也是存放在磁盤上而不是內存中，但是由于高效的分詞算法和索引結構，其效率也是非常的好?？吹胶芏嗑W友在網上，當數(shù)據(jù)量稍微大一些如幾十個 GLucene 的效率會下降的非?？?，其實這是不科學的說法，就從我親眼所見的場景中， 除

17、了使用第的 Search 如 Lucene 之外，也可以自行研發(fā)更適用于自身應用場景的 Search 。就像我目前所供職的公司一樣，自行研發(fā)了一套純內存的更適合于自身應用場景的高性能分布式 Search ，讓各個應用系統(tǒng)能夠作出很多高效的當然，自行研發(fā) Search 的技術門檻可能也比較高，有此技術實力的開發(fā)團隊并不是很多，所以在決定自行研發(fā)之前，一定要做好各方面的評估。不過，如果無法實現(xiàn)一個很通用的 Search ，但是僅僅只是針對某些特定功能來說，可能實現(xiàn)也并沒有那么復雜，更何況如今的開源世界里各種各樣的數(shù)不勝數(shù)，利用現(xiàn)有的工具，加上自身加入了Search 來實現(xiàn)高效的全文檢索功能之后，的架構可以通過如下這IT 界的目前比較流行的分布式并行計算框架主要就是以 的 MapReduce 和 Yahoo 的 Hadoop 二者。其實更為準確的說應該是 的 MapReduce + GFS + BigTable 以及 Yahoo 的 Hadoop + HDFS + HBase 這兩大架構體系。二者都是由三個負責不同功能的組件組成，MapReduce Hadoop 同為解決認任務分解與合并的功能，GFS HDF