概覽一下大數(shù)據(jù)項目中可以使用的數(shù)據(jù)存儲技術，聚焦于Couchbase 和 ElasticSearch耗帕，展示如何使用以及它們的區(qū)別穆端，先理解一下NoSQL領域中各種不同的技術。

NoSQL

關系型數(shù)據(jù)庫是過去的選擇仿便，幾乎是許多開發(fā)者和DBA對于傳統(tǒng)三層架構應用的唯一選擇体啰。使用這一場景有很多原因，數(shù)據(jù)建模方法探越，查詢語言與數(shù)據(jù)交互狡赐，保證數(shù)據(jù)的一致性部署，并能夠為復雜的應用服務钦幔。
然而枕屉，這不是解決所有數(shù)據(jù)存儲問題的唯一方案，也是NoSQL 產(chǎn)生的原因鲤氢。NoSQL 提供了新的方法而不是采用面向標準SQL的范式搀擂。
NoSQL 技術與高伸縮性無縫融合，很多技術同時具備了高分布性和高性能卷玉。大多數(shù)時間里哨颂，它們使 現(xiàn)有RDBMS 技術所實現(xiàn)的架構更加完整，例如 作為緩存服務器相种，搜索引擎威恼，非結構化存儲，易變信息存儲等寝并。主要分為4類：

1. Key/value

2. 列存儲

3. 面向文檔的存儲

4. 圖存儲

現(xiàn)在深入到各種技術箫措，選擇最適用我們場景的技術。

Key/Value

第一個也是最早的 NoSQL 數(shù)據(jù)存儲就是key/value. 這些數(shù)據(jù)就像字典一樣根據(jù)key來匹配value衬潦，通常使用在需要高性能的基本信息存儲斤蔓，例如需要快速讀寫的session信息，這些存儲在這樣的情景非常高效镀岛，也通常具有高伸縮性弦牡。

Key/value也經(jīng)常被用于上下文的隊列化來保證數(shù)據(jù)不丟失，例如日志架構或搜索引擎的索引架構漂羊。Redis 和Riak KV 是非常有名的key/value數(shù)據(jù)存儲驾锰； Redis 使用的更加廣泛，因為它有著一個內(nèi)存型 K/V 存儲走越，并且持久化是可選的稻据。Redis 經(jīng)常用于web應用中來存儲session相關的數(shù)據(jù)，例如node或者-
PHP的 web應用 ; 每秒鐘可以提取成千上萬的session信息而沒有性能損失。另一個典型場景是后面要講到的序列化：Redis位于 Logstash 和 ElasticSearch 之間來存儲t ElasticSearch 查詢中的索引捻悯。

Column

由于要存儲超大量的記錄信息 到達了key/value存儲限制的時候就需要用到列存儲。列存儲技術對于RDBMS世界的工程師可能不太容易理解淤毛，但事實上非常簡單今缚。RDBMS 中數(shù)據(jù)是按行存儲的，而列存儲中是按列的低淡。使用列數(shù)據(jù)庫的主要好處是能高速訪問海量數(shù)據(jù)姓言。 RDBMS的一行在硬盤上是一個連續(xù)的存儲，多行可能存儲在硬盤不同的位置蔗蹋，使訪問稍顯復雜何荚，在列數(shù)據(jù)庫中的一列數(shù)據(jù)是連續(xù)存儲的。

舉個例子猪杭，考慮在RDBMS中查詢索引博客的標題餐塘，尤其是有數(shù)百萬數(shù)據(jù)的時候，需要大量的IO操作皂吮，而在列數(shù)據(jù)庫中戒傻，這樣的查詢只是一次訪問。這樣的數(shù)據(jù)庫在從特定簇提取海量數(shù)據(jù)中非常順手蜂筹，但此消彼長的是缺乏靈活性需纳。使用最多的列存儲數(shù)據(jù)庫是
Google Cloud Bigtable, 但開源的列存儲數(shù)據(jù)庫是Apache HBase 和Cassandra.
列存儲數(shù)據(jù)庫的另一個好處是容易伸縮，這些列在海量存儲時具有高伸縮性艺挪。這就是為什么它們主要用于保存非易變且長久保留信息的原因不翩。

Document

列存儲數(shù)據(jù)庫對于含有比較深嵌套結構的結構化數(shù)據(jù)的存儲不是最好的，這種場景需要使用面向文檔的數(shù)據(jù)存儲麻裳。數(shù)據(jù)實際上以key/value 存儲,但是所有壓縮的數(shù)據(jù)叫做文檔口蝠。 文檔依賴于一個結構或者編碼例如XML, 但更多時候是 JSON (JavaScript Object Notation).

盡管文檔型數(shù)據(jù)庫對于數(shù)據(jù)的結構化存儲和表達都非常有用，但也有其脆弱的一面掂器，特別是與數(shù)據(jù)的交互性操作亚皂。它們基本上要遍歷整個文檔，例如當讀取某個特定字段的時候国瓮，遍歷可能會影響性能灭必。

當需要存儲嵌套信息的時候，可以采用文檔型數(shù)據(jù)庫乃摹。例如禁漓，考慮怎樣表達應用中的一個賬戶，大概有以下信息：

• 基礎信息:姓名孵睬，生日播歼，照片 ，URL, 創(chuàng)建日期等等

• 復雜信息: 地址，認證方法(password, Facebook, 等第三方認證),興趣等等秘狞。

這也是NoSQL 文檔型數(shù)據(jù)庫經(jīng)常用到web應用的原因: 表達嵌套對象非常容易叭莫，由于都使用JSON，還可以與前端的JavaScript技術無縫集成烁试。

使用最多的文檔型數(shù)據(jù)庫是MongoDB, Couchbase, 和 Apache CouchDB雇初，都非常容易安裝和啟動，有很好的文檔說明减响，而且都是可伸縮的靖诗，除此之外，它們也是開放現(xiàn)代web應用的明確選擇支示。

Couchbase 是我們架構中選擇的技術刊橘，使用它來存儲，查詢和組織數(shù)據(jù)颂鸿。原因是基于它的性能基準測試促绵，它的高吞吐量操作時延低于MongoDB.
還有一個值得關注的是，Couchbase 今天是 CouchDB 和Memcached的結合體据途。從支持的角度上看绞愚，使用CouchBase更顯得有意義。

Graph

Graph 數(shù)據(jù)庫與其它數(shù)據(jù)庫有著本質(zhì)的區(qū)別颖医。它使用了不同的范式來表達數(shù)據(jù)——樹結構位衩，節(jié)點和邊連接起來叫做關系。這些數(shù)據(jù)庫是隨著社交網(wǎng)絡而誕生的熔萧，例如表達用戶的好友網(wǎng)絡糖驴，他們的好友關系等等。對于其它類型的數(shù)據(jù)存儲佛致，可能把一個用戶的好友關系存儲在一個文檔中贮缕，但是，存儲好友關系還依然非常復雜俺榆；使用圖數(shù)據(jù)庫就非常簡單感昼，為每個好友創(chuàng)建節(jié)點，通過關系連接他們罐脊，依賴查詢的需要和范圍瀏覽圖定嗓。

最著名的圖數(shù)據(jù)庫是Neo4j, 象前面所說的，主要使用場景是處理復雜的關系信息萍桌，例如實體間的連接宵溅，也可以用于分類的場景。
Figure 2-1 展示了在圖數(shù)據(jù)庫中3個實體是如何連接的上炎。

F2-1 圖數(shù)據(jù)庫示例

Figure 2-1. Graph database example

圖中的兩天賬戶節(jié)點Jane 和 John, 它們之間的每一條邊定義了他們的關系恃逻，在某天相互認識，另一組節(jié)點連接的兩個賬戶展示了Jane 和 Joh在某天后都成為了足球組的成員。

我們使用場景中的NoSQL

根據(jù)我們的使用場景寇损，首先需要一個文檔型的 NoSQL數(shù)據(jù)庫凸郑，將存儲在關系型數(shù)據(jù)庫中的數(shù)據(jù)結構化的一個 JSON 文檔. 如前所述，傳統(tǒng)的RDBMSs 將數(shù)據(jù)存儲到多個有關系的表润绵，當?shù)玫揭粋€完整對象時變得比較復雜和低效线椰。讓我們在Figure 2-2. 中看一個賬戶被分割成多個表的例子。

F2-2 賬戶表

Figure 2-2. Account tables

如果要獲得所有的賬戶信息尘盼，基本上需要join兩到三個表。現(xiàn)在考慮這樣的情形: 需要處理所有用戶在應用中的每一次連接烦绳，這些連接有著不同的商業(yè)邏輯卿捎。 最后,想要賬戶自身的視圖。通過傳遞一個賬戶標識通過API從全部用戶視圖中得到一個怎樣的文檔呢径密？

{
    "id": "account_identifier",
    "email": "account@email.com",
    "firstname": "account_firstname",
    "lastname": "account_lastname",
    "birthdate": "account_birthdate",
    "authentication": [{
        "token": "authentication_token_1",
        "source": "authenticaton_source_1",
        "created": "12-12-12"
    
    }, {
    
        "token": "authentication_token_2",
        "source": "authenticaton_source_2",
        "created": "12-12-12"
    
    }],
    "address": [{
        "street": "address_street_1",
        "city": "address_city_1"
        "zip": "address_zip_1"
        "country": "address_country_1"
        "created": "12-12-12"
    }]

}

好處顯而易見: 通過保持一個實體的 JSON 表達,可以更快更好的訪問數(shù)據(jù)午阵。進一步，將這一方法通用化享扔，從NoSQL數(shù)據(jù)庫讀取所有的讀操作底桂，而讓所有的寫操作 (create, update,delete) 還在RDBMS上 .但我們必須實現(xiàn)一個邏輯來維持 RDBMS到NoSQL 的數(shù)據(jù)同步，如果沒在緩存中的話還要創(chuàng)建一個關系型數(shù)據(jù)庫的對象惧眠。

當我們在NoSQL高效可伸縮地創(chuàng)建文檔時問什么還要保持 RDBMS呢籽懦？因為這不是我們應用的真正目的。我門不想產(chǎn)生一個Big Bang 的影響. 假設RDBMS已經(jīng)準備好了氛魁，但因為RDBMS缺乏靈活性而集成了一個NoSQL存儲暮顺。希望充分利用兩個最好的技術 —特別是RDBMS的數(shù)據(jù)一致性和NoSQL的伸縮性 。

除此之外秀存，這是一個簡單查詢的例子捶码，但是希望更進一步，例如文檔中任意字段的全文檢索或链。那么惫恼，在關系型數(shù)據(jù)庫中如何做的呢？是索引澳盐，但是要索引表中所有的列么祈纯？實際上，這是不可能的洞就，但可以輕松地使用NoSQL技術做這件事盆繁，例如ElasticSearch. 在我們深入一個NoSQL 緩存系統(tǒng)之前，先看一下如何使用 Couchbase 這一文檔型數(shù)據(jù)庫旬蟋，然后回顧它的局限再切換到ElasticSearch油昂。

先看一下Couchbase這一可伸縮架構, 但因為Couchbase 的一些嚴重局限, 還是在遷移前看一下?lián)碛蠩lasticSearch的完整架構。

Couchbase 介紹

Couchbase是一個開源的文檔型數(shù)據(jù)庫，有著靈活的數(shù)據(jù)模型冕碟，性能和伸縮性都適合我們的使用場景拦惋，將關系型數(shù)據(jù)庫的數(shù)據(jù)存儲到一個結構化的 JSON 文檔.大多數(shù)NoSQL技術有著類似的架構—首先看 Couchbase 架構師如何組織的，然后介紹 Couchbase中命名約定, 再深入到存儲數(shù)據(jù)是如何查詢的安寺，最后討論跨數(shù)據(jù)中心的復制厕妖。

架構

Couchbase是一個真正的無共享架構，這意味著沒有單點故障挑庶，因為集群中的每個節(jié)點都是自給自足而且獨立的言秸。分布式技術工作的方式如何？——各節(jié)點不共享任何內(nèi)存或硬盤存儲迎捺。文檔以JSON或者二進制形式存儲在Couchbase中,在集群間復制举畸，所組織的單元叫buckets. 一個bucket 通過設置RAM緩存來根據(jù)存儲和訪問需求完成伸縮，還可以設置彈性副本的數(shù)量凳枝。 從底層看, bucket 被分割成叫做vBuckets 的小單元抄沮，實際上是數(shù)據(jù)分區(qū)。 Couchbase 使用一個集群映射將分區(qū)和服務器關聯(lián)起來岖瑰。一個Couchbase服務器在一個集群內(nèi)對一個bucket有3個副本叛买，每個 Couchbase 管理vbucket 激活或副本的子集。 這就是Couchbase的彈性原理; 每個文檔的每次索引蹋订，都有副本率挣，如果集群中的一個節(jié)點掛了，集群將激活副本分區(qū)來保證連續(xù)的服務辅辩。
Figure 2-3 解釋了集群中只有一個激活的數(shù)據(jù)拷貝同時有一個或多個副本难礼。

F2-3 Couchbase 復制

Figure 2-3. Couchbase active document and replicas

從客戶端視角看,如果使用智能客戶端(Java, C, C++,Ruby等.), 然后這些客戶端連接集群映射; 客戶端從應用發(fā)送請求到合適的服務器. 就交互而言，有非常重要的一點: 文檔操作默認是異步的玫锋。這意味著當你更新文檔的時候蛾茉，Couchbase 不能在硬盤上立即更新數(shù)據(jù)。Figure 2-4. 呈現(xiàn)了真實的處理過程撩鹿。

F2-4

Figure 2-4. Couchbase data flow

如 Figure2-4 所示, 智能客戶端連接到一個 Couchbase 實例谦炬，首先異步將文檔寫到緩存中，客戶端立即得到響應而不是阻塞到數(shù)據(jù)流處理完节沦，當寫操作完成時由客戶端改變行為狀態(tài)键思。然后，文檔被放入集群那邊的寫隊列甫贯，所以在集群間復制; 此后, 文檔被放入硬盤存儲的寫隊列來持久化到相關節(jié)點吼鳞。如果部署了多集群，Cross Data Center Replication (XDCR) 特性可以在不同集群間傳播這種數(shù)據(jù)改變叫搁，集群可以位于不同的數(shù)據(jù)中心赔桌。

Couch base有自己的數(shù)據(jù)查詢方法; 實際上, 簡單地使用文檔ID就可以查詢文檔供炎，Couchbase的強大在視圖特性的內(nèi)部. Couchbase 中, 有一個二級索引叫做設計文檔，是在bucket內(nèi)部創(chuàng)建的. bucket可以包含文檔的多個類型疾党，例如一個簡單的電子商務應用的bucket 包含如下內(nèi)容:

• Account
• Product
• Cart
• Orders
• Bills

Couchbase 使用設計文檔來完成它們的邏輯分割. 一個bucket 可以包含多設計文檔 , 也包含了多視圖. 一個視圖是由用戶定義bucket內(nèi)的索引文檔的函數(shù)音诫。該函數(shù)是用戶定義的map/reduce 函數(shù)將文檔映射到集群中，輸出 key/value 對, 存儲在索引中用于將來的信息提取雪位〗叨郏回顧電商網(wǎng)站的例子，嘗試從帳戶標識的所有訂單中建立索引. map/reduce 函數(shù)如下所示:

function(doc, meta) {
    if (doc.order_account_id)
        emit(doc.order_account_id, null);
}

if 判斷語句允許函數(shù)聚焦在一個文檔雹洗，它包含了order_account_id 字段然后索引這一標識香罐。因此，任何客戶端都可以根據(jù)這一標識從Couchbase中查詢數(shù)據(jù)时肿。

Cluster Manager 和管理控制臺

Cluster manager 是集群中一個特殊的節(jié)點穴吹。在任何時候，如果集群內(nèi)的一個節(jié)點掛了, orchestrator 通過通知集群內(nèi)所有其它節(jié)點來處理故障切換, 定位故障節(jié)點的副本分區(qū)來使之處于激活狀態(tài). Figure 2-5 描述了故障切換處理嗜侮。

F2-5 couchbase 故障切換

Figure 2-5. Couchbase failover

如果 orchestrator 節(jié)點掛了,所有節(jié)點都可以通過心跳監(jiān)控檢測到，這個 watchdog 運行在集群中的所有節(jié)點上啥容。所有集群相關的特性都可以通過API形式來管理Couchbase, 但是有現(xiàn)成的管理控制臺锈颗。Couchbase 有一個安全控制臺來管理和監(jiān)控集群; 可以選擇可用的操作包括服務器搭建，創(chuàng)建buckets, 瀏覽和更新文檔, 實現(xiàn)新的視圖,以及監(jiān)控 vBucket 和硬盤寫隊列.

Figure 2-6 展示了Couchbase 控制臺主頁咪惠，有現(xiàn)存buckets所使用的內(nèi)存, 數(shù)據(jù)使用的硬盤, 以及buckets的活動.

F2-6 couchbase 控制臺主頁

Figure 2-6. Couchbase console home

在 Server Nodes 中執(zhí)行集群管理,讓用戶配置故障切換和復制以防止數(shù)據(jù)丟失击吱。 Figure 2-7 展示了單節(jié)點安裝故障切換的不安全型。

F2-7 couchbase 服務器節(jié)點

Figure 2-7. Couchbase server nodes

任何時候遥昧，都可以通過點擊Add Server 按鈕來增加一個新的Couchbase 服務器覆醇，這一操作的時候，數(shù)據(jù)就開始在節(jié)點間復制來保證故障切換炭臭。通過點擊
服務器IP, 可用訪問一個bucket的監(jiān)控數(shù)據(jù), 如 Figure 2-8.

F2-8 couchbase 監(jiān)控

Figure 2-8. Couchbase bucket monitoring

該圖展示了一個叫做DevUser的數(shù)據(jù) bucket永脓，包含了用戶相關的JSON文檔.如前所述 ,新文檔索引的處理是復雜的底層處理的一部分。當處理高索引吞吐量的海量數(shù)據(jù)時鞋仍，可用從監(jiān)控控制臺看到基本的測量信息常摧。例如，當寫操作時統(tǒng)計磁盤寫隊列的瓶頸威创。

Figure 2-9 中, 可用看的drain rate—從磁盤寫隊列中寫入磁盤的數(shù)據(jù)數(shù)量——在寫入副本時活躍節(jié)點時平滑的落午，而且在平滑區(qū)間內(nèi)增長相對平均。一個改變的行為將是看到活動項目的平均年齡保持增長肚豺，這意味著溃斋，寫操作是與數(shù)據(jù)推入寫磁盤隊列的數(shù)量相比太慢了。

F2-9 couchbase 磁盤隊列

Figure 2-9. Couchbase bucket disk queue

管理文檔

通過bucket視圖吸申，可以從管理控制臺管理所有的文檔. 這一視圖允許用戶瀏覽buckets梗劫， 設計文檔以及視圖.文檔存儲在Couchbase的一個bucket中,可以通過管理控制臺的 Data Bucket 欄目訪問享甸，如Figure 2-10 所示.

F2-10 Couchbase bucket view

Figure 2-10. Couchbase console bucket view

從服務器來看 , 控制臺給出了bucket的統(tǒng)計數(shù)據(jù)如 RAM 和存儲大小以及每秒操作的數(shù)量。但真正的好處是這個視圖可以瀏覽文檔并通過ID來提取它們在跳，如 Figure 2-11 所示.

F2-11 Couchbase document by ID

Figure 2-11. Couchbase document by ID

同時枪萄，可以通過這一視圖創(chuàng)建設計文檔和索引文檔的視圖如Figure 2-12 所示.

F2-12 couchbase 視圖實現(xiàn)

Figure 2-12. Couchbase console view implementation

在Figure 2-12 中, 實現(xiàn)了一個視圖，它基于公司名稱提取文檔猫妙。管理控制臺可用非常方便的管理文檔瓷翻，但在真實世界中，需要在管理控制臺開始實現(xiàn)一個設計文檔割坠，并且創(chuàng)建一個工業(yè)化部署的備份齐帚。所有的設計文檔都存儲在一個JSON 文件中，有著一個簡單的結構來描繪上所有的視圖彼哼，如表 2-1 所示.

Listing 2-1. Designing a Document JSON Example

[{
    ...
    "doc": {
        "json": {
            "views": {
                "by_Id": {"map": "function (doc, meta)
                {\n emit(doc.id, doc);\n}"},
                "by_email": {"map": "function (doc, meta)
                {\n emit(doc.email, doc);\n}"},
                "by_name": {"map": "function (doc, meta)
                {\n emit(doc.firstname, null);\n}"},
                "by_company": {"map": "function (doc, meta)
                {\n emit(doc.company, null);\n}"},
                "by_form": {"map": "function (doc, meta)
                {\n emit(meta.id, null);\n}"}
            }
        }
        ...
    }
}]

已經(jīng)看到对妄，可以通過管理控制臺執(zhí)行文檔的管理，但是在商用架構中敢朱，大量這樣的操作是通過使用Couchbase API 的腳本完成的剪菱。

介紹ElasticSearch

已經(jīng)了解了Couchbase這樣的一個NoSQL; ElasticSearch 也是一個NoSQL技術，但與 Couchbase完全不同. 這是由Elastic公司命名的分布式數(shù)據(jù)庫拴签。

架構

它是一個建立于Apache Lucene（一個Java寫的全文搜素引擎）之上的索引/搜索引擎孝常。從一開始, ElasticSearch 就是分布式可伸縮的，可以通過增加節(jié)點資源來垂直擴展蚓哩，也可以通過增加節(jié)點來水平擴展增加高可用性同時保持彈性构灸。如果一個節(jié)點掛了，由于在集群間的復制岸梨，由其它節(jié)點提供服務喜颁。

ElasticSearch 是一個無縫引擎；數(shù)據(jù)以JSON存儲曹阔，分區(qū)叫做shards. 一個 shard 實際上是一個Lucene的索引半开，是 ElasticSearch中最小的可擴展單元. Shards 組織成ElasticSearch中的索引，使應用完成讀寫交互次兆。最后, 索引是一個ElasticSearch中邏輯上的命名空間稿茉，是shards 集合的一個重新分組，當請求到達時, ElasticSearch 將它路由到合適的shard上芥炭，如 Figure 2-13 所示.

F2-13

Figure 2-13. Elasticsearch index and shards

ElasticSearch中有兩種shard類型:基本 shards 和復制shards. 當啟動一ElasticSearch 節(jié)點, 開始只增加一個基本shard, 這就足夠了,當時當讀／檢索請求的吞吐量迅猛增加的時候會怎樣呢漓库？這種情況下, 一個基本 shard 可能不夠用了，就需要另一個shard. 不能實時增加shard來期望ElasticSearch 來擴展; 這將在兩個新的基本shard中重新索引所有的數(shù)據(jù)园蝠。所以渺蒿，在啟動一個 ElasticSearch項目的開始, 適當評估集群中有多少個基本shard 非常重要。在一個節(jié)點增加多個 shards 不能增加集群的容量彪薛，因為有著硬件的現(xiàn)在茂装。為了增加集群容量怠蹂，也需要增加更多的節(jié)點來承載基本 shards，見Figure 2-14.

F2-14 es primary shard

Figure 2-14. ElasticSearch primary shard allocation

一個好事情時ElasticSearch在新節(jié)點上可以通過網(wǎng)絡自動拷貝shard少态，如 Figure 2-14.但是如何確保數(shù)據(jù)不丟失呢城侧？這就是replica shards的角色。

Replica shards 開始源于故障切換;當primary shard 掛了, 一個副本被提升為primary來保證集群的連續(xù)性彼妻。Replica shards 在primary shards 做索引的時候擁有同樣的負載; 一旦一個文檔在 primary shard中建立了索引, 同樣也在replica shards中做了索引. 這就是為什么在集群中增加副本卻不會增加索引的性能嫌佑，但是如果增加了額外的硬件，就會提升搜索的性能侨歉。在一個三節(jié)點集群中,有一個primary shards 和兩個副本 Figure 2-15 展示了如何重新分區(qū).

F2-15 ES shards

Figure 2-15. ElasticSearch primary and replica shards

另外, 通過在集群中幫助請求的負載均衡屋摇，從而得到更好的性能。最后要討論的是純 ElasticSearch 架構的indices以及多節(jié)點. Indices 被重新分組到 ElasticSearch 的節(jié)點,Figure 2-16 展示了3種類型的節(jié)點幽邓。

F2-16 ES 集群拓撲結構

Figure 2-16. ElasticSearch cluster topology

這是三種節(jié)點的描述:

• Master nodes: 這些節(jié)點是輕量級的炮温，負責集群管理。它們不承載任何數(shù)據(jù), server indices,或搜素請求. 它們專門來保證集群的穩(wěn)定性牵舵，負載較低柒啤。推薦使用三個master nodes通過冗余保證故障切換。

• Data nodes: 這些節(jié)點持有數(shù)據(jù)畸颅，索引和搜索請求白修。

• Client nodes: 這保證部分處理步驟的負載均衡，且部分工作負載在數(shù)據(jù)節(jié)點執(zhí)行重斑，例如搜索請求發(fā)散在不同節(jié)點上。

理解了ElasticSearch架構, 就可以使用API運行一些查詢了肯骇。

ElasticSearch 監(jiān)控

Elastic 提供了一個叫 Marvel 的插件窥浪，目標是監(jiān)控 ElasticSearch 集群. 這個插件是個商用產(chǎn)品，但你可以在開發(fā)模式免費使用它笛丙。

下載和安裝都非常簡單:https://www.elastic.co/downloads/marvel

Marvel 是依賴 Kibana的, Elastic的可視化控制臺,帶來大量的可視化技術漾脂，使操作者準確地知道在集群上發(fā)生了什么。 Figure 2-17展示了 Marvel的控制面板.

F2-17 ES Marvel

Figure 2-17. ElasticSearch Marvel console

Marvel 提供了節(jié)點indices和shards的信息; CPU 利用率;JVM所使用的內(nèi)存;索引的速度,以及搜索的速度. Marvel 甚至可以進入到 Lucene的底層查看
flushes 和 merges的信息.例如集群中shard的分布列表 見 Figure 2-18.

F2-18 Marvel shard

Figure 2-18. Marvel’s shard allocation view

Marvel 可以提供大量有關集群的信息胚鸯。Figure 2-19展示了節(jié)點統(tǒng)計的子集.

F2-19 Marvel 節(jié)點統(tǒng)計面板

Figure 2-19. Marvel Node Statistics dashboard

dashboard 被組織成幾行; 實際上骨稿，在截屏中是看不到多于20行的內(nèi)容的.每行包含一個或行標題的可視化。 在 Figure 2-19中姜钳，沒看到發(fā)送到
indices的GET 請求; 這就是為什么線圖是平的. 在開發(fā)模式中坦冠，這些統(tǒng)計可以幫助判定服務器是否伸縮，例如哥桥，啟動一個單節(jié)點集群辙浑，查看特殊需求的行為。在生產(chǎn)環(huán)境拟糕，能夠真實地看到集群的信息判呕，而不損失什么倦踢。

通過 ElasticSearch搜索

Marvel又一個叫 Sense的特性，是ElasticSearch的一個查詢編輯器. Sense 的強大是又一個自動補全查詢的能力侠草，當不熟悉
ElasticSearch API時非常有用, 見Figure 2-20.

F2-20 Marvel Sense

Figure 2-20. Marvel Sense completion feature

也可以將查詢導出到cURLs, 例如, 使用的腳本參見Figure 2-21.

F2-21 copy as cURL

Figure 2-21. Marvel Sense copy as cURL feature

在這種情況下,查詢被視為cURL 命令,見 Listing 2-3.

Listing 2-3. Example of cURL Command Generated by Sense

curl -XGET "http://192.168.59.103:9200/yahoo/_search" -d'
{
    "query": {
        "match_all": {}
    }
}'

這一查詢基本上搜索了Yahoo索引下的全部文檔. 未來展示 search API的優(yōu)勢, 使用來自 Yahoo的數(shù)據(jù)集辱挥，它包含了若干年Yahoo股票的信息。一個 ElasticSearch’s search API中關鍵的特性是边涕，這是一個聚合框架晤碘。可以用不同的方法聚合數(shù)據(jù); 更通用的方式是事業(yè)日期直方圖奥吩，相當于時間線哼蛆。Figure 2-22 解釋了一個查詢的例子; 通過日期聚合股票數(shù)據(jù)，間隔可以是月霞赫，也可以計算給定月份的股價最大值腮介。

F2-22 聚合示例

Figure 2-22. Marvel Sense Aggregation example

作為結果, 我們得到一個文檔的數(shù)組，每個條目包含了日期端衰，每月的文檔數(shù)量叠洗，最高值，見Listing 2-4.

Listing 2-4. Aggregation Bucket

{
    "key_as_string": "2015-01-01T00:00:00.000Z",
    "key": 1420070400000,
    "doc_count": 20,
    "by_high_value": {
        "value": 120
    }
}

可以看到如 Figure 2-22的查詢, 有兩個層次的聚合: 一個是日期直方圖旅东，第二個是最大值灭抑。實際上 , ElasticSearch 支持多層次聚合。
搜素API 非常豐富抵代，不可能逐個瀏覽腾节，詳情參見:

https://www.elastic.co/guide/en/elasticsearch/reference/1.4/search-search.html

現(xiàn)在熟悉了兩種 NoSQL技術 , 看一下把它們集成到一個電子商務應用的不同方法。

在基于SQL的架構中 使用 NoSQL 緩存

盡管理解了NoSQL技術相對于 SQL 數(shù)據(jù)庫的優(yōu)勢荤牍，但不想打破依賴于SQL數(shù)據(jù)庫的現(xiàn)有架構案腺。下面的方法可以完善我們的架構，基于NoSQL技術增加訪問數(shù)據(jù)的靈活性康吵。

文檔緩存

第一個要討論的是如何復制數(shù)據(jù)到我們NoSQL的后端劈榨。希望每次數(shù)據(jù)寫到SQL數(shù)據(jù)庫中的時候，一個文檔同時在我們的NoSQL創(chuàng)建或更新晦嵌。文檔的創(chuàng)建同辣、更新字段，或者豐富子文檔對應于 RDBMS的表關系. 在訪問文檔的時候惭载，只要API的GET 請求產(chǎn)生了旱函，都先看NoSQL后端，如果有則返回此文檔描滔。

如果文檔沒找到怎么辦陡舅？緩存沒有命中的事件將被觸發(fā)，NoSQL manager 從 RDBMS中重建此文檔. 那在SQL層插入的transaction失敗了怎么辦? 框架應該是交易型的伴挚，只有當SQL 的交易完成時才觸發(fā)文檔的重建靶衍。Figure 2-23 總結了這一機制.

F2-23 文檔緩存

Figure 2-23. Caching a document in NoSQL

Figure 2-23 描述的內(nèi)容:

• 第一框圖展示了一個賬戶如何在 RDBMS 中創(chuàng)建的灾炭，以及如何在NoSQL中創(chuàng)建一個完整賬戶的文檔表達

• 第二框圖展示了API如何從NoSQL存儲中獲得一個賬戶信息.

• 第三個框圖展示了一個緩存丟失的例子,當文檔不在NoSQL中的時候必須從RDBMS中重建

實際上，基于NoSQL為web應用建立了一個緩存颅眶。這種方法依賴于NoSQL訪問整個文檔的靈活性而不增加SQL數(shù)據(jù)庫的負擔蜈出，也充分利用了NoSQL的分布式靈活性。 通過這種方法涛酗，隨著請求速度的大量增長可以擴展集群铡原，減少SQL數(shù)據(jù)庫的壓力。

ElasticSearch的 Couchbase 插件

為了獲得這樣一個緩存機制商叹，需要選擇NoSQL技術燕刻。第一個方法獨立使用
Couchbase, 但是 Couchbase的搜索特性不太好使。用map/reduce 函數(shù)索引數(shù)據(jù)較煩瑣剖笙，尤其是只做簡單聚合的時候卵洗。 Couch base 是個很棒的 NoSQL 數(shù)據(jù)庫, 但實現(xiàn)搜索確實痛苦。作為替代方法弥咪，可以使用Couchbase/ElasticSearch 集成插件, 基本上使用Cross Data Center Replication (XDCR) 傳輸所有數(shù)據(jù)到 ElasticSearch 集群(www.couchbase.com/jp/couchbase-server/connectors/elasticsearch).
就操作任務而言过蹂，要維護三種不同的技術:RDBMS, Couchbase, 和 ElasticSearch.

最有效的ElasticSearch

保持使用 Couchbase 原因：

• 索引全部對象的能力油航， 例如將SQL中的賬戶信息簽到NoSQL

• 通過靈活的搜索API適應從簡單到復雜聚合查詢的能力

從選擇 Couchbase 開始殿怜，作為最佳實踐，文檔存儲在數(shù)據(jù)庫中固该。當體驗架構的時候扳躬，要知道什么是訪問和請求數(shù)據(jù)的最有效方法脆诉。在我們使用場景中， ElasticSearch 就是最有效的方法贷币。