深入研究查詢Elasticsearch，過(guò)濾查詢和全文搜索

或如何了解缺少哪些官方文件

創(chuàng)新互聯(lián)致力于網(wǎng)站建設(shè)、網(wǎng)站制作,成都網(wǎng)站設(shè)計(jì),集團(tuán)網(wǎng)站建設(shè)等服務(wù)標(biāo)準(zhǔn)化，推過(guò)標(biāo)準(zhǔn)化降低中小企業(yè)的建站的成本，并持續(xù)提升建站的定制化服務(wù)水平進(jìn)行質(zhì)量交付，讓企業(yè)網(wǎng)站從市場(chǎng)競(jìng)爭(zhēng)中脫穎而出。 選擇創(chuàng)新互聯(lián)，就選擇了安全、穩(wěn)定、美觀的網(wǎng)站建設(shè)服務(wù)！

如果我不得不用一個(gè)短語(yǔ)來(lái)描述Elasticsearch，我會(huì)說(shuō)：

目前，Elasticsearch在十大最受歡迎的開(kāi)源技術(shù)中。 公平地說(shuō)，它結(jié)合了許多本身并不獨(dú)特的關(guān)鍵功能，但是，當(dāng)結(jié)合使用時(shí)，它可以成為最佳的搜索引擎/分析平臺(tái)。

更準(zhǔn)確地說(shuō)，由于以下功能的結(jié)合，Elasticsearch變得如此流行：

· 搜索相關(guān)性評(píng)分

· 全文搜索

· 分析（匯總）

· 無(wú)模式（對(duì)數(shù)據(jù)模式無(wú)限制），NoSQL，面向文檔

· 豐富的數(shù)據(jù)類型選擇

· 水平可擴(kuò)展

· 容錯(cuò)的

通過(guò)與Elasticsearch進(jìn)行合作，我很快意識(shí)到，官方文檔看起來(lái)更像是所謂文檔的"擠壓"。 我不得不在Google上四處搜尋，并且大量使用stackowerflow，所以我決定編譯這篇文章中的所有信息。

在本文中，我將主要撰寫有關(guān)查詢/搜索Elasticsearch集群的文章。 您可以通過(guò)多種不同的方式來(lái)實(shí)現(xiàn)大致相同的結(jié)果，因此，我將嘗試說(shuō)明每種方法的利弊。

更重要的是，我將向您介紹兩個(gè)重要的概念-查詢和過(guò)濾器上下文-在文檔中沒(méi)有很好地解釋。 我將為您提供一組規(guī)則，以決定何時(shí)使用哪種方法更好。

在閱讀本文后，如果我只想讓您記住一件事，那就是：

當(dāng)我們談?wù)揈lasticsearch時(shí)，總會(huì)有一個(gè)相關(guān)性分?jǐn)?shù)。 相關(guān)性分?jǐn)?shù)是嚴(yán)格的正浮點(diǎn)數(shù)，表示每個(gè)文檔滿足搜索標(biāo)準(zhǔn)的程度。 該分?jǐn)?shù)是相對(duì)于分配的最高分?jǐn)?shù)的，因此，分?jǐn)?shù)越高，文檔與搜索條件的相關(guān)性越好。

但是，過(guò)濾器和查詢是您在編寫查詢之前應(yīng)該能夠理解的兩個(gè)不同概念。

一般來(lái)說(shuō)，過(guò)濾器上下文是一個(gè)"是/否"選項(xiàng)，其中每個(gè)文檔都與查詢匹配或不匹配。 一個(gè)很好的例子是SQL WHERE，后面是一些條件。 SQL查詢總是返回嚴(yán)格符合條件的行。 SQL查詢無(wú)法返回歧義結(jié)果。

另一方面，Elasticsearch查詢上下文顯示了每個(gè)文檔與您的需求的匹配程度。 為此，查詢使用分析器查找最佳匹配。

經(jīng)驗(yàn)法則是將過(guò)濾器用于：

· 是/否搜索

· 搜索精確值（數(shù)字，范圍和關(guān)鍵字）

將查詢用于：

· 結(jié)果不明確（某些文檔比其他文檔更適合）

· 全文搜索

此外，Elasticsearch將自動(dòng)緩存過(guò)濾器的結(jié)果。

在第1部分和第2部分中，我將討論查詢（可以轉(zhuǎn)換為過(guò)濾器）。 請(qǐng)不要將結(jié)構(gòu)化和全文與查詢和過(guò)濾器混淆-這是兩件事。

結(jié)構(gòu)化查詢也稱為術(shù)語(yǔ)級(jí)查詢，是一組查詢方法，用于檢查是否應(yīng)選擇文檔。 因此，在很多情況下，沒(méi)有真正必要的相關(guān)性評(píng)分-文檔匹配或不匹配（尤其是數(shù)字）。

術(shù)語(yǔ)級(jí)查詢?nèi)匀皇遣樵儯虼怂鼈儗⒎祷胤謹(jǐn)?shù)。

名詞查詢 Term Query

返回字段值與條件完全匹配的文檔。 查詢一詞是SQL select * from table_name where column_name =...的替代方式

名詞查詢直接進(jìn)入倒排索引，這可以使其快速進(jìn)行。 在處理文本數(shù)據(jù)時(shí)，最好僅將term用于keyword字段。

名詞查詢默認(rèn)情況下在查詢上下文中運(yùn)行，因此，它將計(jì)算分?jǐn)?shù)。 即使所有返回的文檔的分?jǐn)?shù)相同，也將涉及其他計(jì)算能力。

帶有過(guò)濾條件的 名詞 查詢

如果我們想加速名詞查詢并使其得到緩存，則應(yīng)將其包裝在constant_score過(guò)濾器中。

還記得經(jīng)驗(yàn)法則嗎？ 如果您不關(guān)心相關(guān)性得分，請(qǐng)使用此方法。

現(xiàn)在，該查詢沒(méi)有計(jì)算任何相關(guān)性分?jǐn)?shù)，因此，它更快。 而且，它是自動(dòng)緩存的。

快速建議-對(duì)文本字段使用匹配而不是名詞。

請(qǐng)記住，名詞查詢直接進(jìn)入倒排索引。名詞查詢采用您提供的值并按原樣搜索它，這就是為什么它非常適合查詢未經(jīng)任何轉(zhuǎn)換存儲(chǔ)的keyword字段。

多名詞查詢 Terms query

如您所料，多名詞查詢使您可以返回至少匹配一個(gè)確切名詞的文檔。

多名詞查詢?cè)谀撤N程度上是SQL select * from table_name where column_name is in...的替代方法

重要的是要了解，Elasticsearch中的查詢字段可能是一個(gè)列表，例如{“ name”：[“ Odin”，“ Woden”，“ Wodan”]}。如果您執(zhí)行的術(shù)語(yǔ)查詢包含以下一個(gè)或多個(gè)，則該記錄將被匹配-它不必匹配字段中的所有值，而只匹配一個(gè)。

與名詞查詢相同，但是這次您可以在查詢字段中指定多少個(gè)確切術(shù)語(yǔ)。

您指定必須匹配的數(shù)量-一，二，三或全部。 但是，此數(shù)字是另一個(gè)數(shù)字字段。 因此，每個(gè)文檔都應(yīng)包含該編號(hào)（特定于該特定文檔）。

返回查詢字段值在定義范圍內(nèi)的文檔。

等價(jià)于SQL select * from table_name where column_name is between...

范圍查詢具有自己的語(yǔ)法：

· gt 大于

· gte 大于或等于

· lt 小于

· lte 小于或等于

一個(gè)示例，該字段的值應(yīng)≥4且≤17

范圍查詢也可以很好地與日期配合使用。

正則表達(dá)式查詢返回其中字段與您的正則表達(dá)式匹配的文檔。

如果您從未使用過(guò)正則表達(dá)式，那么我強(qiáng)烈建議您至少了解一下它是什么以及何時(shí)可以使用它。

Elasticsearch的正則表達(dá)式是Lucene的正則表達(dá)式。 它具有標(biāo)準(zhǔn)的保留字符和運(yùn)算符。 如果您已經(jīng)使用過(guò)Python的re軟件包，那么在這里使用它應(yīng)該不是問(wèn)題。 唯一的區(qū)別是Lucene的引擎不支持^和$等錨運(yùn)算符。

您可以在官方文檔中找到regexp的完整列表。

除正則表達(dá)式查詢外，Elsticsearch還具有通配符和前綴查詢。從邏輯上講，這兩個(gè)只是regexp的特殊情況。

不幸的是，我找不到關(guān)于這三個(gè)查詢的性能的任何信息，因此，我決定自己對(duì)其進(jìn)行測(cè)試，以查看是否發(fā)現(xiàn)任何重大差異。

在比較使用rehexp和通配符查詢時(shí)，我找不到性能上的差異。如果您知道有什么不同，請(qǐng)給我發(fā)消息。

由于Elasticsearch是無(wú)模式的（或沒(méi)有嚴(yán)格的模式限制），因此當(dāng)不同的文檔具有不同的字段時(shí)，這是一種很常見(jiàn)的情況。 結(jié)果，有很多用途來(lái)了解文檔是否具有某些特定字段。

全文查詢適用于非結(jié)構(gòu)化文本數(shù)據(jù)。 全文查詢利用了分析器。 因此，我將簡(jiǎn)要概述Elasticsearch的分析器，以便我們可以更好地分析全文查詢。

每次將文本類型數(shù)據(jù)插入Elasticsearch索引時(shí)，都會(huì)對(duì)其進(jìn)行分析，然后存儲(chǔ)在反向索引中。根據(jù)分析器的配置方式，這會(huì)影響您的搜索功能，因?yàn)榉治銎饕策m用于全文搜索。

分析器管道包括三個(gè)階段：

總有一個(gè)令牌生成器和零個(gè)或多個(gè)字符和令牌過(guò)濾器。

1）字符過(guò)濾器按原樣接收文本數(shù)據(jù)，然后可能在對(duì)數(shù)據(jù)進(jìn)行標(biāo)記之前對(duì)其進(jìn)行預(yù)處理。 字符過(guò)濾器用于：

· 替換與給定正則表達(dá)式匹配的字符

· 替換與給定字符串匹配的字符

· 干凈的HTML文字

2）令牌生成器將字符過(guò)濾器（如果有）之后接收到的文本數(shù)據(jù)分解為令牌。 例如，空白令牌生成器只是將文本分隔為空白（這不是標(biāo)準(zhǔn)的）。 因此，Wednesday is called after Woden， 將被拆分為[Wednesday, is, called, after, Woden.]。 有許多內(nèi)置標(biāo)記器可用于創(chuàng)建自定義分析器。

刪除標(biāo)點(diǎn)符號(hào)后，標(biāo)準(zhǔn)令牌生成器將使用空格分隔文本。 對(duì)于絕大多數(shù)語(yǔ)言來(lái)說(shuō)，這是最中立的選擇。

除標(biāo)記化外，標(biāo)記化器還執(zhí)行以下操作：

· 跟蹤令牌順序，

· 注釋每個(gè)單詞的開(kāi)頭和結(jié)尾

· 定義令牌的類型

3）令牌過(guò)濾器對(duì)令牌進(jìn)行一些轉(zhuǎn)換。您可以選擇將許多不同的令牌過(guò)濾器添加到分析器中。一些最受歡迎的是：

· 小寫

· 詞干（存在多種語(yǔ)言?。?/p>

· 刪除重復(fù)

· 轉(zhuǎn)換為等效的ASCII

· 模式的解決方法

· 令牌數(shù)量限制

· 令牌的停止列表（從停止列表中刪除令牌）

標(biāo)準(zhǔn)分析器是默認(rèn)分析器。 它具有0個(gè)字符過(guò)濾器，標(biāo)準(zhǔn)令牌生成器，小寫字母和停止令牌過(guò)濾器。 您可以根據(jù)需要組成自定義分析器，但是內(nèi)置分析器也很少。

語(yǔ)言分析器是一些最有效的即用型分析器，它們利用每種語(yǔ)言的細(xì)節(jié)來(lái)進(jìn)行更高級(jí)的轉(zhuǎn)換。 因此，如果您事先知道數(shù)據(jù)的語(yǔ)言，建議您從標(biāo)準(zhǔn)分析器切換為數(shù)據(jù)的一種語(yǔ)言。

全文查詢將使用與索引數(shù)據(jù)時(shí)使用的分析器相同的分析器。更準(zhǔn)確地說(shuō)，您查詢的文本將與搜索字段中的文本數(shù)據(jù)進(jìn)行相同的轉(zhuǎn)換，因此兩者處于同一級(jí)別。

匹配查詢是用于查詢文本字段的標(biāo)準(zhǔn)查詢。

我們可以將匹配查詢稱為名詞查詢的等效項(xiàng)，但適用于文本類型字段（而在處理文本數(shù)據(jù)時(shí)，名詞應(yīng)僅用于關(guān)鍵字類型字段）。

默認(rèn)情況下，傳遞給查詢參數(shù)的字符串（必需的一個(gè)）將由與應(yīng)用于搜索字段的分析器相同的分析器處理。 除非您自己使用analyzer參數(shù)指定分析器。

當(dāng)您指定要搜索的短語(yǔ)時(shí)，將對(duì)其進(jìn)行分析，并且結(jié)果始終是一組標(biāo)記。默認(rèn)情況下，Elasticsearch將在所有這些標(biāo)記之間使用OR運(yùn)算符。這意味著至少應(yīng)該有一場(chǎng)比賽-更多的比賽雖然會(huì)得分更高。您可以在運(yùn)算符參數(shù)中將其切換為AND。在這種情況下，必須在文檔中找到所有令牌才能將其返回。

如果要在OR和AND之間輸入某些內(nèi)容，則可以指定minimum_should_match參數(shù)，該參數(shù)指定應(yīng)匹配的子句數(shù)。 可以數(shù)字和百分比指定。

模糊參數(shù)（可選）可讓您忽略錯(cuò)別字。 Levenshtein距離用于計(jì)算。

如果您將匹配查詢應(yīng)用于關(guān)鍵字keyword字段，則其效果與詞條查詢相同。 更有趣的是，如果將存儲(chǔ)在反向索引中的令牌的確切值傳遞給term查詢，則它將返回與匹配查詢完全相同的結(jié)果，但是會(huì)更快地返回到反向索引。

與匹配相同，但順序和接近度很重要。 匹配查詢不了解序列和接近度，因此，只有通過(guò)其他類型的查詢才能實(shí)現(xiàn)詞組匹配。

match_phrase查詢具有slop參數(shù)（默認(rèn)值為0），該參數(shù)負(fù)責(zé)跳過(guò)術(shù)語(yǔ)。 因此，如果您指定斜率等于1，則短語(yǔ)中可能會(huì)省略一個(gè)單詞。

多重比對(duì)查詢的功能與比對(duì)相同，唯一的不同是多重比對(duì)適用于多個(gè)欄位

· 字段名稱可以使用通配符指定

· 默認(rèn)情況下，每個(gè)字段均加權(quán)

· 每個(gè)領(lǐng)域?qū)Φ梅值呢暙I(xiàn)都可以提高

· 如果沒(méi)有在fields參數(shù)中指定任何字段，那么將搜索所有符合條件的字段

有多種類型的multi_match。 我不會(huì)在這篇文章中描述它們，但是我將解釋最受歡迎的：

best_fields類型（默認(rèn)值）更喜歡在一個(gè)字段中找到來(lái)自搜索值的令牌的結(jié)果，而不是將搜索的令牌分配到不同字段中的結(jié)果。

most_fields與best_fields類型相反。

phrase類型的行為與best_fields相同，但會(huì)搜索與match_phrase類似的整個(gè)短語(yǔ)。

我強(qiáng)烈建議您查閱官方文檔，以檢查每個(gè)字段的得分計(jì)算準(zhǔn)確度。

復(fù)合查詢將其他查詢包裝在一起。 復(fù)合查詢：

· 結(jié)合分?jǐn)?shù)

· 改變包裝查詢的行為

· 將查詢上下文切換到過(guò)濾上下文

· 以上任意一項(xiàng)

布爾查詢將其他查詢組合在一起。 這是最重要的復(fù)合查詢。

布爾查詢使您可以將查詢上下文中的搜索與過(guò)濾器上下文搜索結(jié)合在一起。

布爾查詢具有四個(gè)可以組合在一起的出現(xiàn)（類型）：

· must或"必須滿足該條款"

· should或"如果滿足條款，則對(duì)相關(guān)性得分加分"

· 過(guò)濾器filter或"必須滿足該條款，但不計(jì)算相關(guān)性得分"

· must_not或“與必須相反”，不會(huì)有助于相關(guān)度得分

必須和應(yīng)該→查詢上下文

過(guò)濾器和must_not→過(guò)濾器上下文

對(duì)于那些熟悉SQL的人，必須為AND，而應(yīng)為OR運(yùn)算符。 因此，必須滿足must子句中的每個(gè)查詢。

對(duì)于大多數(shù)查詢，提升查詢與boost參數(shù)相似，但并不相同。 增強(qiáng)查詢將返回與肯定子句匹配的文檔，并降低與否定子句匹配的文檔的得分。

如我們?cè)谛g(shù)語(yǔ)查詢示例中先前看到的，constant_score查詢將任何查詢轉(zhuǎn)換為相關(guān)性得分等于boost參數(shù)（默認(rèn)值為1）的過(guò)濾器上下文。

讓我知道是否您想閱讀另一篇文章，其中提供了所有查詢的真實(shí)示例。

我計(jì)劃在Elasticsearch上發(fā)布更多文章，所以不要錯(cuò)過(guò)。

你已經(jīng)讀了很長(zhǎng)的內(nèi)容，所以如果你閱讀到這里：

綜上所述，Elasticsearch符合當(dāng)今的許多用途，有時(shí)很難理解什么是最佳工具。

如果不需要相關(guān)性分?jǐn)?shù)來(lái)檢索數(shù)據(jù)，請(qǐng)嘗試切換到過(guò)濾器上下文。

另外，了解Elasticsearch的工作原理也至關(guān)重要，因此，我建議您始終了解分析器的功能。

Elasticsearch中還有許多其他查詢類型。 我試圖描述最常用的。 我希望你喜歡它。

(本文翻譯自kotartemiy ??的文章《Deep Dive into Querying Elasticsearch. Filter vs Query. Full-text search》，參考：)

一、NoSQL數(shù)據(jù)庫(kù)簡(jiǎn)介

Web1.0的時(shí)代，數(shù)據(jù)訪問(wèn)量很有限，用一夫當(dāng)關(guān)的高性能的單點(diǎn)服務(wù)器可以解決大部分問(wèn)題。

隨著Web2.0的時(shí)代的到來(lái)，用戶訪問(wèn)量大幅度提升，同時(shí)產(chǎn)生了大量的用戶數(shù)據(jù)。加上后來(lái)的智能移動(dòng)設(shè)備的普及，所有的互聯(lián)網(wǎng)平臺(tái)都面臨了巨大的性能挑戰(zhàn)。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關(guān)系型的數(shù)據(jù)庫(kù)。

NoSQL 不依賴業(yè)務(wù)邏輯方式存儲(chǔ)，而以簡(jiǎn)單的key-value模式存儲(chǔ)。因此大大的增加了數(shù)據(jù)庫(kù)的擴(kuò)展能力。

Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫(kù) 列式數(shù)據(jù)庫(kù) Hbase Hbase

HBase是Hadoop項(xiàng)目中的數(shù)據(jù)庫(kù)。它用于需要對(duì)大量的數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時(shí)的讀寫操作的場(chǎng)景中。

HBase的目標(biāo)就是處理數(shù)據(jù)量非常龐大的表，可以用普通的計(jì)算機(jī)處理超過(guò)10億行數(shù)據(jù)，還可處理有數(shù)百萬(wàn)列元素的數(shù)據(jù)表。

Cassandra Cassandra

Apache Cassandra是一款免費(fèi)的開(kāi)源NoSQL數(shù)據(jù)庫(kù)，其設(shè)計(jì)目的在于管理由大量商用服務(wù)器構(gòu)建起來(lái)的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達(dá)到PB級(jí)別)。在眾多顯著特性當(dāng)中，Cassandra最為卓越的長(zhǎng)處是對(duì)寫入及讀取操作進(jìn)行規(guī)模調(diào)整，而且其不強(qiáng)調(diào)主集群的設(shè)計(jì)思路能夠以相對(duì)直觀的方式簡(jiǎn)化各集群的創(chuàng)建與擴(kuò)展流程。

主要應(yīng)用：社會(huì)關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜(n*(n-1)/2)

為什么選擇使用NoSQL數(shù)據(jù)庫(kù)開(kāi)發(fā)如此困難

傳統(tǒng)觀念中 NoSQL數(shù)據(jù)庫(kù)非常適合某些數(shù)據(jù)類型，如：非關(guān)系數(shù)據(jù)源。同時(shí)，NoSQL被吹捧為最適合Web應(yīng)用程序的優(yōu)秀平臺(tái)。然而他適合大多數(shù)數(shù)據(jù)，特別是web應(yīng)用程序的數(shù)據(jù)是相關(guān)型。那么，這是否可以給你一個(gè)堅(jiān)持使用RDMS的理由呢？也不一定，即使很困難，我們還是要做出選擇。

評(píng)估NoSQL是一個(gè)很茅盾的理論，一些人認(rèn)為，應(yīng)該將所有文檔數(shù)據(jù)存儲(chǔ)在一個(gè)文檔中，做鏈接代碼就是褻瀆神明。另外一部分人認(rèn)為，存儲(chǔ)應(yīng)用文檔，

加入代碼，才是合理選擇。與此同時(shí)，不同的數(shù)據(jù)庫(kù)，需要在文檔中限制嵌套數(shù)據(jù)數(shù)量。有的人會(huì)鼓勵(lì)文檔引用。這是NoSQL數(shù)據(jù)模型的基本部分，也沒(méi)有一個(gè)

明確的共識(shí)。

曾經(jīng)有一篇很熱的帖子"Why you should never use

XYZ"，我想，讀到這里，一定會(huì)有人搜索這篇文章。當(dāng)然，這種文章各式各樣，太過(guò)于籠統(tǒng)的標(biāo)題也沒(méi)什么幫助。毫無(wú)疑問(wèn)，會(huì)有人會(huì)搜索這個(gè)文章，然后再找

到這個(gè)文章，進(jìn)一步深入，找到該文章的方法遠(yuǎn)比成功（理解問(wèn)題）的故事多。很難知道誰(shuí)提供了一個(gè)有效的技術(shù)問(wèn)題，誰(shuí)又誤讀了這個(gè)問(wèn)題（或者缺少證據(jù)證明其

觀點(diǎn)）。

有大量選擇，RDBMS的世界，選擇就很容易。你有4或5個(gè)目標(biāo)，大家工作方式差不多，來(lái)選擇環(huán)境、預(yù)算支持的平臺(tái)。對(duì)于成熟的產(chǎn)品，風(fēng)險(xiǎn)比較小。 NoSQL的世界，有很多數(shù)據(jù)庫(kù)引擎功能選擇。每一個(gè)有自己的獨(dú)特優(yōu)勢(shì)，也有致命弱點(diǎn)。所以選擇很難， NoSQL項(xiàng)目生命周期短，嘗試新項(xiàng)目或者流行項(xiàng)目也會(huì)有風(fēng)險(xiǎn)。上次，我的的項(xiàng)目是在 CouchDB上，而現(xiàn)在似乎停擺了。

做出這個(gè)痛苦決定的原因是，這可能是一個(gè)案例：你需要做一大堆工作，才能知道，你做出的選擇對(duì)與錯(cuò)。你可以實(shí)體化你的數(shù)據(jù)模型，了解他與系統(tǒng)的工作

情況，但是，這只有你正真撞到南墻，才可以找到裂縫（答案）。以我為例，我建的應(yīng)用程序是關(guān)系數(shù)據(jù)庫(kù)，移動(dòng)文件存儲(chǔ)的主要因素是，需要一個(gè)無(wú)模式設(shè)計(jì)來(lái)達(dá)

到我的目標(biāo)。使用NoSQL 數(shù)據(jù)庫(kù)存儲(chǔ)關(guān)系型數(shù)據(jù)庫(kù)并不是我們所常說(shuō)的，雖然，這種事常常發(fā)生。

現(xiàn)在我在用 Couchbase 和

MongoDB，Mongo對(duì)我沒(méi)多大吸引力，不過(guò)鑒于他非常流行，對(duì)于引起來(lái)說(shuō)，很有好處。當(dāng)然，很多都可以以同樣的方式流行。PHP很流行，因?yàn)樗?/p>

易用性，而不是因?yàn)樗芎?。我現(xiàn)在在使用MongoDB和PHP，也在學(xué)習(xí)Couchbase，如果你有任何NoSQL平臺(tái)的使用感想，歡迎交流。

什么是NoSQL數(shù)據(jù)庫(kù)？

2. 什么是NoSQL？

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，

泛指非關(guān)系型的數(shù)據(jù)庫(kù)。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問(wèn)題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來(lái)的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。

（例如谷歌或Facebook每天為他們的用戶收集萬(wàn)億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模式，無(wú)需多余操作就可以橫向擴(kuò)展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 關(guān)系型數(shù)據(jù)庫(kù)與NoSQL的區(qū)別？

3.1 RDBMS

高度組織化結(jié)構(gòu)化數(shù)據(jù)

結(jié)構(gòu)化查詢語(yǔ)言（SQL）

數(shù)據(jù)和關(guān)系都存儲(chǔ)在單獨(dú)的表中。

數(shù)據(jù)操縱語(yǔ)言，數(shù)據(jù)定義語(yǔ)言

嚴(yán)格的一致性

基礎(chǔ)事務(wù)

ACID

關(guān)系型數(shù)據(jù)庫(kù)遵循ACID規(guī)則

事務(wù)在英文中是transaction，和現(xiàn)實(shí)世界中的交易很類似，它有如下四個(gè)特性：

A (Atomicity) 原子性

原子性很容易理解，也就是說(shuō)事務(wù)里的所有操作要么全部做完，要么都不做，事務(wù)成功的條件是事務(wù)里的所有操作都成功，只要有一個(gè)操作失敗，整個(gè)事務(wù)就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個(gè)步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會(huì)莫名其妙少了100元。

C (Consistency) 一致性

一致性也比較容易理解，也就是說(shuō)數(shù)據(jù)庫(kù)要一直處于一致的狀態(tài)，事務(wù)的運(yùn)行不會(huì)改變數(shù)據(jù)庫(kù)原本的一致性約束。

I (Isolation) 獨(dú)立性

所謂的獨(dú)立性是指并發(fā)的事務(wù)之間不會(huì)互相影響，如果一個(gè)事務(wù)要訪問(wèn)的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改，只要另外一個(gè)事務(wù)未提交，它所訪問(wèn)的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個(gè)交易還未完成的情況下，如果此時(shí)B查詢自己的賬戶，是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事務(wù)提交后，它所做的修改將會(huì)永久的保存在數(shù)據(jù)庫(kù)上，即使出現(xiàn)宕機(jī)也不會(huì)丟失。

3.2 NoSQL

代表著不僅僅是SQL

沒(méi)有聲明性查詢語(yǔ)言

沒(méi)有預(yù)定義的模式

鍵 - 值對(duì)存儲(chǔ)，列存儲(chǔ)，文檔存儲(chǔ)，圖形數(shù)據(jù)庫(kù)

最終一致性，而非ACID屬性

非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)

CAP定理

高性能，高可用性和可伸縮性

分布式數(shù)據(jù)庫(kù)中的CAP原理(了解)

CAP定理：

Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動(dòng)都是同步的

Availability(可用性), 好的響應(yīng)性能

Partition tolerance(分區(qū)容錯(cuò)性) 可靠性

P: 系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。

定理：任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒(méi)法三者兼顧。

CAP理論的核心是：一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性，可用性和分區(qū)容錯(cuò)性這三個(gè)需求，

因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫(kù)分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：

CA - 單點(diǎn)集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)大。

CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。

AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐?duì)一致性要求低一些。

CAP理論就是說(shuō)在分布式存儲(chǔ)系統(tǒng)中，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。

而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問(wèn)題，所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。

所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒(méi)有NoSQL系統(tǒng)能同時(shí)保證這三點(diǎn)。

說(shuō)明：C：強(qiáng)一致性 A：高可用性 P：分布式容忍性

舉例：

CA：傳統(tǒng)Oracle數(shù)據(jù)庫(kù)

AP：大多數(shù)網(wǎng)站架構(gòu)的選擇

CP：Redis、Mongodb

注意：分布式架構(gòu)的時(shí)候必須做出取舍。

一致性和可用性之間取一個(gè)平衡。多余大多數(shù)web應(yīng)用，其實(shí)并不需要強(qiáng)一致性。

因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。

4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用

當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。

代表項(xiàng)目：阿里巴巴商品信息的存放。

去 IOE 化。

ps：I 是指 IBM 的小型機(jī)，很貴的，好像好幾萬(wàn)一臺(tái)；O 是指 Oracle 數(shù)據(jù)庫(kù)，也很貴的，好幾萬(wàn)呢；M 是指 EMC 的存儲(chǔ)設(shè)備，也很貴的。

難點(diǎn)：

數(shù)據(jù)類型多樣性。

數(shù)據(jù)源多樣性和變化重構(gòu)。

數(shù)據(jù)源改造而服務(wù)平臺(tái)不需要大面積重構(gòu)。

網(wǎng)站欄目：NoSQL無(wú)模式,為什么需要nosql
網(wǎng)址分享：http://jinyejixie.com/article8/dsecoop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、品牌網(wǎng)站建設(shè)、小程序開(kāi)發(fā)、微信小程序、動(dòng)態(tài)網(wǎng)站、品牌網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)