NoSQL 與大資料

標籤：

概覽一下大資料項目中可以使用的資料存放區技術，聚焦於Couchbase 和 Elasticsearch，展示如何使用以及它們的區別，先理解一下NoSQL領域中各種不同的技術。

NoSQL

關係型資料庫是過去的選擇，幾乎是許多開發人員和DBA對於傳統三層架構應用的唯一選擇。使用這一情境有很多原因，資料建模方法，查詢語言與資料互動，保證資料的一致性部署，並能夠為複雜的應用服務。
然而，這不是解決所有資料存放區問題的唯一方案，也是NoSQL 產生的原因。NoSQL 提供了新的方法而不是採用面向標準SQL的範式。
NoSQL 技術與高伸縮性無縫融合，很多技術同時具備了高分布性和高效能。大多數時間裡，它們使 現有RDBMS 技術所實現的架構更加完整，例如 作為快取服務器，搜尋引擎，非結構化儲存，易變資訊儲存等。主要分為4類：

1. Key/value

2. 列儲存

3. 面向文檔的儲存

4. 圖儲存

現在深入到各種技術，選擇最適用於使用情境的技術。

Key/Value

第一個也是最早的 NoSQL 資料存放區就是key/value. 這些資料就像字典一樣根據key來匹配value，通常使用在需要高效能的基本資料儲存，例如需要快速讀寫的session資訊，這些儲存在這樣的情景非常高效，也通常具有高伸縮性。

Key/value也經常被用於內容相關的隊列化來保證資料不丟失，例如日誌架構或搜尋引擎的索引架構。Redis 和Riak KV 是非常有名的key/value資料存放區； Redis 使用的更加廣泛，因為它有著一個記憶體型 K/V 儲存，並且持久化是可選的。Redis 經常用於web應用中來儲存session相關的資料，例如node或者-
PHP的 web應用 ; 每秒鐘可以提取成千上萬的session資訊而沒有效能損失。另一個典型情境是後面要講到的序列化：Redis位於 Logstash 和 Elasticsearch 之間來儲存t Elasticsearch 查詢中的索引。

Column

由於要儲存超大量的記錄資訊 到達了key/value儲存限制的時候就需要用到列儲存。列儲存技術對於RDBMS世界的工程師可能不太容易理解，但事實上非常簡單。RDBMS 中資料是按行儲存的，而列儲存中是按列的。使用列資料庫的主要好處是能高速訪問海量資料。 RDBMS的一行在硬碟上是一個連續的儲存，多行可能儲存在硬碟不同的位置，使訪問稍顯複雜，在列資料庫中的一列資料是連續儲存的。

舉個例子，考慮在RDBMS中查詢索引部落格的標題，尤其是有數百萬資料的時候，需要大量的IO操作，而在列資料庫中，這樣的查詢只是一次訪問。這樣的資料庫在從特定簇提取海量資料中非常順手，但此消彼長的是缺乏靈活性。使用最多的列儲存資料庫是
Google Cloud Bigtable, 但開源的列儲存資料庫是Apache HBase 和Cassandra.
列儲存資料庫的另一個好處是容易伸縮，這些列在海量儲存時具有高伸縮性。這就是為什麼它們主要用於儲存非易變且長久保留資訊的原因。

Document

列儲存資料庫對於含有比較深嵌套結構的結構化資料的儲存不是最好的，這種情境需要使用面向文檔的資料存放區。資料實際上以key/value 儲存,但是所有壓縮的資料叫做文檔。 文檔依賴於一個結構或者編碼例如XML, 但更多時候是 JSON (JavaScript Object Notation).

儘管文檔型資料庫對於資料的結構化儲存和表達都非常有用，但也有其脆弱的一面，特別是與資料的互動性操作。它們基本上要遍曆整個文檔，例如當讀取某個特定欄位的時候，遍曆可能會影響效能。

當需要儲存嵌套資訊的時候，可以採用文檔型資料庫。例如，考慮怎樣表達應用中的一個賬戶，大概有以下資訊：

• 基礎資訊:姓名，生日，照片 ，URL, 建立日期等等

• 複雜資訊: 地址，認證方法(password, Facebook, 等第三方認證),興趣等等。

這也是NoSQL 文檔型資料庫經常用到web應用的原因: 表達嵌套對象非常容易，由雩都使用JSON，還可以與前端的JavaScript技術無縫整合。

使用最多的文檔型資料庫是MongoDB, Couchbase, 和 Apache CouchDB，都非常容易安裝和啟動，有很好的文檔說明，而且都是可伸縮的，除此之外，它們也是開放現代web應用的明確選擇。

Couchbase 是這裡架構中選擇的技術，使用它來儲存，查詢和組織資料。原因是基於它的效能基準測試，它的高輸送量操作時延低於MongoDB.
還有一個值得關注的是，Couchbase 今天是 CouchDB 和Memcached的結合體。從支援的角度上看，使用CouchBase更顯得有意義。

Graph

Graph 資料庫與其它資料庫有著本質的區別。它使用了不同的範式來表達資料——樹結構，節點和邊串連起來叫做關係。這些資料庫是隨著社交網路而誕生的，例如表達使用者的好友網路，他們的好友關係等等。對於其它類型的資料存放區，可能把一個使用者的好友關係儲存在一個文檔中，但是，儲存好友關係還依然非常複雜；使用圖資料庫就非常簡單，為每個好友建立節點，通過關係串連他們，依賴查詢的需要和範圍瀏覽圖。

最著名的圖資料庫是Neo4j, 象前面所說的，主要使用情境是處理複雜的關係資訊，例如實體間的串連，也可以用於分類的情境。
Figure 2-1 展示了在圖資料庫中3個實體是如何串連的。

Figure 2-1. Graph database example

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

使用情境中的NoSQL

根據使用情境，首先需要一個文檔型的 NoSQL資料庫，將儲存在關係型資料庫中的資料結構化的一個 JSON 文檔. 如前所述，傳統的RDBMSs 將資料存放區到多個有關係的表，當得到一個完整對象時變得比較複雜和低效。在Figure 2-2. 中可以看到一個賬戶被分割成多個表的例子。

Figure 2-2. Account tables

如果要獲得所有的賬戶資訊，基本上需要join兩到三個表。現在考慮這樣的情形: 需要處理所有使用者在應用中的每一次串連，這些串連有著不同的商業邏輯。 最後,想要賬戶自身的視圖。通過傳遞一個賬戶標識通過API從全部使用者視圖中得到一個怎樣的文檔呢？

{    "id": "account_identifier",    "email": "[email protected]",    "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 表達,可以更快更好的訪問資料。進一步，將這一方法通用化，從NoSQL資料庫讀取所有的讀操作，而讓所有的寫操作 (create, update,delete) 還在RDBMS上 .但必須實現一個邏輯來維持 RDBMS到NoSQL 的資料同步，如果沒在緩衝中的話還要建立一個關係型資料庫的對象。

在NoSQL高效可伸縮地建立文檔時為什麼還要保持 RDBMS呢？因為這不是應用的真正目的。我不想產生一個Big Bang 的影響. 假設RDBMS已經準備好了，但因為RDBMS缺乏靈活性而整合了一個NoSQL儲存。希望充分利用兩個最好的技術 —特別是RDBMS的資料一致性和NoSQL的伸縮性 。

除此之外，這是一個簡單查詢的例子，但是希望更進一步，例如文檔中任意欄位的全文檢索索引。那麼，在關係型資料庫中如何做的呢？是索引，但是要索引表中所有的列嗎？實際上，這是不可能的，但可以輕鬆地使用NoSQL技術做這件事，例如Elasticsearch. 在深入一個NoSQL 緩衝系統之前，先看一下如何使用 Couchbase 這一文檔型資料庫，然後回顧它的局限再切換到Elasticsearch。

先看一下Couchbase這一可伸縮架構, 但因為Couchbase 的一些嚴重局限, 還要遷移前看一下擁有Elasticsearch的完整架構。

Couchbase 介紹

Couchbase是一個開源的文檔型資料庫，有著靈活的資料模型，效能和伸縮性都適合一般的使用情境，將關係型資料庫的資料存放區到一個結構化的 JSON 文檔.大多數NoSQL技術有著類似的架構—首先看 Couchbase 架構師如何組織的，然後介紹 Couchbase中命名規範, 再深入到儲存資料是如何查詢的，最後討論跨資料中心的複製。

架構

Couchbase是一個真正的無共用架構，這意味著沒有單點故障，因為叢集中的每個節點都是自給自足而且獨立的。分布式技術工作的方式如何？——各節點不共用任何記憶體或硬碟儲存。文檔以JSON或者二進位形式儲存在Couchbase中,在叢集間複製，所組織的單元叫buckets. 一個bucket 通過設定RAM緩衝來根據儲存和訪問需求完成伸縮，還可以設定彈性副本的數量。 從底層看, bucket 被分割成叫做vBuckets 的小單元，實際上是資料分區。 Couchbase 使用一個叢集映射將分區和伺服器關聯起來。一個Couchbase伺服器在一個叢集內對一個bucket有3個副本，每個 Couchbase 管理vbucket 啟用或副本的子集。 這就是Couchbase的彈性原理; 每個文檔的每次索引，都有副本，如果叢集中的一個節點掛了，叢集將啟用副本分區來保證連續的服務。
Figure 2-3 解釋了叢集中只有一個啟用的資料拷貝同時有一個或多個副本。

Figure 2-3. Couchbase active document and replicas

從用戶端視角看,如果使用智能用戶端(Java, C, C++,Ruby等.), 然後這些用戶端串連叢集映射; 用戶端從應用發送請求到合適的伺服器. 就互動而言，有非常重要的一點: 文檔操作預設是非同步。這意味著當你更新文檔的時候，Couchbase 不能在硬碟上立即更新資料。Figure 2-4. 呈現了真實的處理過程。

Figure 2-4. Couchbase data flow

如 Figure2-4 所示, 智能用戶端串連到一個 Couchbase 執行個體，首先非同步將文檔寫到緩衝中，用戶端立即得到響應而不是阻塞到資料流處理完，當寫操作完成時由用戶端改變行為狀態。然後，文檔被放入叢集那邊的寫隊列，所以在叢集間複製; 此後, 文檔被放入硬碟儲存的寫隊列來持久化到相關節點。如果部署了多叢集，Cross Data Center Replication (XDCR) 特性可以在不同叢集間傳播這種資料改變，叢集可以位於不同的資料中心。

Couch base有自己的資料查詢方法; 實際上, 簡單地使用文檔ID就可以查詢文檔，Couchbase的強大在視圖特性的內部. Couchbase 中, 有一個二級索引叫做設計文檔，是在bucket內部建立的. bucket可以包含文檔的多個類型，例如一個簡單的電子商務應用的bucket 包含如下內容:

• Account
• Product
• Cart
• Orders
• Bills

Couchbase 使用設計文檔來完成它們的邏輯分割. 一個bucket 可以包含多設計文檔 , 也包含了多視圖. 一個視圖是由使用者定義bucket內的索引文檔的函數。該函數是使用者定義的map/reduce 函數將文檔映射到叢集中，輸出 key/value 對, 儲存在索引中用於將來的資訊提取。回顧電商網站的例子，嘗試從帳戶標識的所有訂單中建立索引. map/reduce 函數如下所示:

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

if 判斷語句允許函數聚焦在一個文檔，它包含了order_account_id 欄位然後索引這一標識。因此，任何用戶端都可以根據這一標識從Couchbase中查詢資料。

Cluster Manager 和管理主控台

Cluster manager 是叢集中一個特殊的節點。在任何時候，如果叢集內的一個節點掛了, orchestrator 通過通知叢集內所有其它節點來處理故障切換, 定位故障節點的副本分區來使之處於啟用狀態. Figure 2-5 描述了故障切換處理。

Figure 2-5. Couchbase failover

如果 orchestrator 節點掛了,所有節點都可以通過心跳監控檢測到，這個 watchdog 運行在叢集中的所有節點上。所有叢集相關的特性都可以通過API形式來管理Couchbase, 但是有現成的管理主控台。Couchbase 有一個安全控制台來管理和監控叢集; 可以選擇可用的操作包括伺服器搭建，建立buckets, 瀏覽和更新文檔, 實現新的視圖,以及監控 vBucket 和硬碟寫隊列.

Figure 2-6 展示了Couchbase 控制台首頁，有現存buckets所使用的記憶體, 資料使用的硬碟, 以及buckets的活動.

Figure 2-6. Couchbase console home

在 Server Nodes 中執行叢集管理,讓使用者配置故障切換和複製以防止資料丟失。 Figure 2-7 展示了單節點安裝故障切換的不安全型。

Figure 2-7. Couchbase server nodes

任何時候，都可以通過點擊Add Server 按鈕來增加一個新的Couchbase 伺服器，這一操作的時候，資料就開始在節點間複製來保證故障切換。通過點擊
伺服器IP, 可用訪問一個bucket的監控資料, 如 Figure 2-8.

Figure 2-8. Couchbase bucket monitoring

該圖展示了一個叫做DevUser的資料 bucket，包含了使用者相關的JSON文檔.如前所述 ,新文檔索引的處理是複雜的底層處理的一部分。當處理高索引輸送量的海量資料時，可用從監控控制台看到基本的測量資訊。例如，當寫操作時統計磁碟寫隊列的瓶頸。

Figure 2-9 中, 可用看的drain rate—從磁碟寫隊列中寫入磁碟的資料數量——在寫入副本時活躍節點時平滑的，而且在平滑區間內增長相對平均。一個改變的行為將是看到活動項目的平均年齡保持增長，這意味著，寫操作是與資料推入寫磁碟隊列的數量相比太慢了。

Figure 2-9. Couchbase bucket disk queue

管理文檔

通過bucket視圖，可以從管理主控台管理所有的文檔. 這一視圖允許使用者瀏覽buckets， 設計文檔以及視圖.文檔儲存在Couchbase的一個bucket中,可以通過管理主控台的 Data Bucket 欄目訪問，如Figure 2-10 所示.

Figure 2-10. Couchbase console bucket view

從伺服器來看 , 控制台給出了bucket的統計資料如 RAM 和儲存大小以及每秒操作的數量。但真正的好處是這個視圖可以瀏覽文檔並通過ID來提取它們，如 Figure 2-11 所示.

Figure 2-11. Couchbase document by ID

同時，可以通過這一視圖建立設計文檔和索引文檔的視圖如Figure 2-12 所示.

Figure 2-12. Couchbase console view implementation

在Figure 2-12 中, 實現了一個視圖，它基於公司名稱提取文檔。管理主控台可用非常方便的管理文檔，但在真實世界中，需要在管理主控台開始實現一個設計文檔，並且建立一個工業化部署的備份。所有的設計文檔都儲存在一個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}"}            }        }        ...    }}]

已經看到，可以通過管理主控台執行文檔的管理，但是在商用架構中，大量這樣的操作是通過使用Couchbase API 的指令碼完成的。

介紹Elasticsearch

既然瞭解了Couchbase這樣的一個NoSQL，那麼Elasticsearch 也是一個NoSQL技術，但與 Couchbase完全不同. 這是由Elastic公司命名的分散式資料庫。

架構

它是一個建立於Apache Lucene（一個Java寫的全文搜素引擎）之上的索引/搜尋引擎。從一開始, Elasticsearch 就是分布式可伸縮的，可以通過增加節點資源來垂直擴充，也可以通過增加節點來水平擴充增加高可用性同時保持彈性。如果一個節點掛了，由於在叢集間的複製，由其它節點提供服務。

Elasticsearch 是一個無縫引擎；資料以JSON儲存，分區叫做shards. 一個 shard 實際上是一個Lucene的索引，是 Elasticsearch中最小的可擴充單元. Shards 組織成Elasticsearch中的索引，使應用完成讀寫互動。最後, 索引是一個Elasticsearch中邏輯上的命名空間，是shards 集合的一個重新分組，當請求到達時, Elasticsearch 將它路由到合適的shard上，如 Figure 2-13 所示.

Figure 2-13. Elasticsearch index and shards

Elasticsearch中有兩種shard類型:基本 shards 和複製shards. 當啟動一Elasticsearch 節點, 開始只增加一個基本shard, 這就足夠了,當時當讀／檢索請求的輸送量迅猛增加的時候會怎樣呢？這種情況下, 一個基本 shard 可能不夠用了，就需要另一個shard. 不能即時增加shard來期望Elasticsearch 來擴充; 這將在兩個新的基本shard中重新索引所有的資料。所以，在啟動一個 Elasticsearch項目的開始, 適當評估叢集中有多少個基本shard 非常重要。在一個節點增加多個 shards 不能增加叢集的容量，因為有著硬體的現在。為了增加叢集容量，也需要增加更多的節點來承載基本 shards，見Figure 2-14.

Figure 2-14. Elasticsearch primary shard allocation

一個好事情時Elasticsearch在新節點上可以通過網路自動拷貝shard，如 Figure 2-14.但是如何確保資料不丟失呢？這就是replica shards的角色。

Replica shards 開始源於故障切換;當primary shard 掛了, 一個副本被提升為primary來保證叢集的連續性。Replica shards 在primary shards 做索引的時候擁有同樣的負載; 一旦一個文檔在 primary shard中建立了索引, 同樣也在replica shards中做了索引. 這就是為什麼在叢集中增加副本卻不會增加索引的效能，但是如果增加了額外的硬體，就會提升搜尋的效能。在一個三節點叢集中,有一個primary shards 和兩個副本 Figure 2-15 展示了如何重新分區.

Figure 2-15. Elasticsearch primary and replica shards

另外, 通過在叢集中協助請求的負載平衡，從而得到更好的效能。最後要討論的是純 Elasticsearch 架構的indices以及多節點. Indices 被重新分組到 Elasticsearch 的節點,Figure 2-16 展示了3種類型的節點。

Figure 2-16. Elasticsearch cluster topology

這是三種節點的描述:

• Master nodes: 這些節點是輕量級的，負責叢集管理。它們不承載任何資料, server indices,或搜素請求. 它們專門來保證叢集的穩定性，負載較低。推薦使用三個master nodes通過冗餘保證故障切換。

• Data nodes: 這些節點持有資料，索引和搜尋請求。

• Client nodes: 這保證部分處理步驟的負載平衡，且部分工作負載在資料節點執行，例如搜尋請求發散在不同節點上。

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

Elasticsearch 監控

Elastic 提供了一個叫 Marvel 的外掛程式，目標是監控 Elasticsearch 叢集. 這個外掛程式是個商用產品，但你可以在開發模式免費使用它。

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

Marvel 是依賴 Kibana的, Elastic的可視化控制台,帶來大量的可視化技術，使操作者準確地知道在叢集上發生了什麼。 Figure 2-17展示了 Marvel的控制台.

Figure 2-17. Elasticsearch Marvel console

Marvel 提供了節點indices和shards的資訊; CPU 利用率;JVM所使用的記憶體;索引的速度,以及搜尋的速度. Marvel 甚至可以進入到 Lucene的底層查看
flushes 和 merges的資訊.例如叢集中shard的分布列表 見 Figure 2-18.

Figure 2-18. Marvel’s shard allocation view

Marvel 可以提供大量有關叢集的資訊。Figure 2-19展示了節點統計的子集.

Figure 2-19. Marvel Node Statistics dashboard

dashboard 被組織成幾行; 實際上，在截屏中是看不到多於20行的內容的.每行包含一個或列名的可視化。 在 Figure 2-19中，沒看到發送到
indices的GET 請求; 這就是為什麼線圖是平的. 在開發模式中，這些統計可以協助判定伺服器是否伸縮，例如，啟動一個單節點叢集，查看特殊需求的行為。在生產環境，能夠真實地看到叢集的資訊，而不損失什麼。

通過 Elasticsearch搜尋

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

Figure 2-20. Marvel Sense completion feature

也可以將查詢匯出到cURLs, 例如, 使用的指令碼參見Figure 2-21.

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的優勢, 使用來自 Yahoo的資料集，它包含了若干年Yahoo股票的資訊。一個 Elasticsearch’s search API中關鍵的特性是，這是一個彙總架構。可以用不同的方法彙總資料; 更通用的方式是事業日期長條圖，相當於時間軸。Figure 2-22 解釋了一個查詢的例子; 通過日期彙總股票資料，間隔可以是月，也可以計算給定月份的股價最大值。

Figure 2-22. Marvel Sense Aggregation example

作為結果, 得到一個文檔的數組，每個條目包含了日期，每月的文檔數量，最高值，見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

現在熟悉了兩種 NoSQL技術 , 看一下把它們整合到一個電子商務應用的不同方法。

在基於SQL的架構中 使用 NoSQL 緩衝

儘管理解了NoSQL技術相對於 SQL 資料庫的優勢，但不想打破依賴於SQL資料庫的現有架構。下面的方法可以完善這裡的架構，基於NoSQL來增加訪問資料的靈活性。

文檔緩衝

第一個要討論的是如何複製資料到NoSQL的後端。希望每次資料寫到SQL資料庫中的時候，一個文檔同時在NoSQL中建立或更新。文檔的建立、更新欄位，或者豐富子文檔對應於 RDBMS的表關係. 在訪問文檔的時候，只要API的GET 請求產生了，都先看NoSQL後端，如果有則返回此文檔。

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

Figure 2-23. Caching a document in NoSQL

Figure 2-23 描述的內容:

• 第一框圖展示了一個賬戶如何在 RDBMS 中建立的，以及如何在NoSQL中建立一個完整賬戶的文檔表達

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

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

實際上，基於NoSQL為web應用建立了一個緩衝。這種方法依賴於NoSQL訪問整個文檔的靈活性而不增加SQL資料庫的負擔，也充分利用了NoSQL的分布式靈活性。 通過這種方法，隨著請求速度的大量增長可以擴充叢集，減少SQL資料庫的壓力。

Elasticsearch的 Couchbase 外掛程式

為了獲得這樣一個緩衝機制，需要選擇NoSQL技術。第一個方法獨立使用
Couchbase, 但是 Couchbase的搜尋特性不太好使。用map/reduce 函數索引資料較煩瑣，尤其是只做簡單彙總的時候。 Couch base 是個很棒的 NoSQL 資料庫, 但實現搜尋確實痛苦。作為替代方法，可以使用Couchbase/Elasticsearch 整合外掛程式, 基本上使用Cross Data Center Replication (XDCR) 傳輸所有資料到 Elasticsearch 叢集(www.couchbase.com/jp/couchbase-server/connectors/elasticsearch).
就操作任務而言，要維護三種不同的技術:RDBMS, Couchbase, 和 Elasticsearch.

最有效Elasticsearch

保持使用 Couchbase 原因：

• 索引全部對象的能力， 例如將SQL中的賬戶資訊簽到NoSQL

• 通過靈活的搜尋API適應從簡單到複雜彙總查詢的能力

從選擇 Couchbase 開始，作為最佳實務，文檔儲存在資料庫中。當體驗架構的時候，要知道什麼是訪問和請求資料的最有效方法。在大多數使用情境中， Elasticsearch 就是最有效方法。

NoSQL 與大資料