它尤其與SQL無(wú)關(guān). 比方說(shuō)， Hive 查詢(xún)語(yǔ)言的靈感顯然來(lái)自 SQL.  Esper查詢(xún)語(yǔ)言同樣如此, 只是它操作的是流而不是關(guān)系. 還有你知道 PostgreSQL 過(guò)去被命名為 “Postgres” 并使用 “Quel” 作為它的查詢(xún)語(yǔ)言么? 而首先作為一個(gè)關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)（ ORDBMS）, 它現(xiàn)在同樣有許多的特性使其具備無(wú)模式文檔存儲(chǔ)的能力.

它同樣也和ACID-特性無(wú)關(guān). Hyperdex 就是一個(gè) NoSQL-數(shù)據(jù)庫(kù)的例子，它的目標(biāo)就是提供 ACID-事務(wù)能力. MySQL, 確實(shí)是一個(gè) SQL-數(shù)據(jù)庫(kù), 歷史上它有一段解釋 ACID 的真正意義的曖昧?xí)r期.

關(guān)系型的? 雖然大多數(shù)的 NoSQL-數(shù)據(jù)庫(kù)并不支持加入傳統(tǒng)關(guān)系型數(shù)據(jù)意義相同的功能，但還是有一些那樣做了，并將其留給用戶(hù)當(dāng)做練習(xí)使用. RethinkDB, Hive 還有 Pig, 等等. Neo4j, 面向圖形的數(shù)據(jù)庫(kù), 確實(shí)是處理關(guān)系用的 - 它擅于遍歷圖中的關(guān)系 (比如，圖中的邊) . Elasticsearch 有一個(gè)概念叫做加入父子關(guān)系的“查詢(xún)時(shí)間”和加入嵌套類(lèi)型的“索引時(shí)間“.

分布式的? 已經(jīng)有一些分布式的 SQL-數(shù)據(jù)庫(kù) 了, 并以 一些項(xiàng)目 旨在做一些像一個(gè)NoSQLite那樣的事情, 更新一代的數(shù)據(jù)庫(kù)趨向于在某些方式上具備分布式能力.

總而言之, 既沒(méi)有道理給 NoSQL 做出精確的定義, 也不能簡(jiǎn)單的說(shuō) Elasticsearch 是一個(gè)“文檔存儲(chǔ)”-類(lèi)型的NoSQL-數(shù)據(jù)庫(kù). 在我寫(xiě)這篇文章的時(shí)候, nosql-database.org 列出了超過(guò)20 個(gè)那樣的東西.

在下一節(jié)，我們將關(guān)注一些重要的屬性并且看看 Elasticsearch 為什么要實(shí)現(xiàn)或者不去實(shí)現(xiàn)它們。

在逐個(gè)切片進(jìn)行處理的方式中，當(dāng)一個(gè)索引被刷新時(shí)，默認(rèn)是一秒鐘一次，就需要對(duì)變更的可見(jiàn)性進(jìn)行控制。

通過(guò)制定提交文檔的版本，可以進(jìn)行樂(lè)觀(guān)并發(fā)控制。

Elasticsearch追求的是速度。支持分布式事務(wù)是一大塊工作。不支持分布式事務(wù)會(huì)使得很多事情變得容易起來(lái)。只要我們能接受讀取到的數(shù)據(jù) 有些陳舊，而且所有人看到的是同一時(shí)間點(diǎn)的數(shù)據(jù)，那么Elasticsearch就可以利用緩存提供很多服務(wù) - 這對(duì)于我們鐘愛(ài)的極速性能來(lái)說(shuō)是至關(guān)重要的。

模式靈活

Elasticsearch 不要求你先指定模式。扔給它一個(gè) JSON 文檔，它就會(huì)進(jìn)行一些訓(xùn)練有素的猜測(cè)來(lái)推斷其類(lèi)型。對(duì)于數(shù)值、布爾、時(shí)間戳它可以做的很好。對(duì)于字符串，它會(huì)使用“標(biāo)準(zhǔn)化”的分析，這通常是良好的開(kāi)始。

它是有商榷的“無(wú)模式”，在這個(gè)意義上你不必指定一個(gè)模式，我們更愿意把它認(rèn)做是“模式靈活”。為了開(kāi)發(fā)大規(guī)模的搜索、分析，你確實(shí)需要對(duì)模式進(jìn)行 微調(diào)。Elasticsearch 有大量的強(qiáng)大工具可以幫助你，例如動(dòng)態(tài)模板、多字段對(duì)象等。這在我們關(guān)于映射的文章里會(huì)談及更多。

關(guān)系和約束

Elasticsearch是一種面向文檔的數(shù)據(jù)庫(kù)。你想要對(duì)之進(jìn)行搜索的整個(gè)對(duì)象關(guān)系圖，都需要進(jìn)行索引，在對(duì)文檔進(jìn)行索引之前，它們必須先被反規(guī)范化。反規(guī)范化提升了查詢(xún)性能(因?yàn)椴辉傩枰M(jìn)行關(guān)聯(lián)查詢(xún))，使用了更多存儲(chǔ)空間(因?yàn)閿?shù)據(jù)必須被存儲(chǔ)多次)，但是，要保持?jǐn)?shù)據(jù)一致性和實(shí)時(shí)性則更加困難(因?yàn)槿魏螖?shù)據(jù)改變都必須被寫(xiě)入到所有實(shí)例中去)。不過(guò)，對(duì)于一次寫(xiě)入頻繁讀取的工作場(chǎng)景，它的表現(xiàn)相當(dāng)優(yōu)異。

換句話(huà)說(shuō)，在面向文檔類(lèi)型的數(shù)據(jù)庫(kù)中，比如Elasticsearch, 我們對(duì)文檔進(jìn)行映射和存儲(chǔ)設(shè)計(jì)只是為了優(yōu)化查詢(xún)和信息獲取的性能。

在介紹中已經(jīng)提到，Elasticsearch中可以使用父/子-關(guān)系進(jìn)行“查詢(xún)時(shí)”連結(jié)，也可以使用內(nèi)嵌類(lèi)型進(jìn)行“索引時(shí)”連結(jié)。我們會(huì)在以后的文章中對(duì)該主題進(jìn)行深入介紹。我們推薦Martijn van Groningen的一篇文章“Document relations with Elasticsearch”.

大多數(shù)關(guān)系型數(shù)據(jù)庫(kù)也會(huì)允許你指定約束關(guān)系，來(lái)定義什么需要保持一致性，什么不需要保持一致性。比如，參照完整性和唯一性都是強(qiáng)制性的。你可以要求賬戶(hù)變更金額必須是正數(shù)，等等。而面向文檔的數(shù)據(jù)庫(kù)不傾向于這么做，Elasticsearch就是如此。

魯棒性

一個(gè)數(shù)據(jù)庫(kù)應(yīng)當(dāng)是魯棒的，尤其是當(dāng)它是你權(quán)威的記錄系統(tǒng)時(shí)。理想情況下，一個(gè)耗費(fèi)資源的查詢(xún)應(yīng)當(dāng)可以被撤銷(xiāo)，你肯定不希望數(shù)據(jù)庫(kù)停止工作，除非你命令它停下來(lái)。

不幸的是，Elasticsearch (以及它的組件)目前并沒(méi)有很好的處理OutOfMemory錯(cuò)誤。我們?cè)贓lasticsearch in Production, OutOfMemory-Caused Crashes一文中進(jìn)行了更加深入的討論。所以，給Elasticsearch配置足夠多的內(nèi)存就顯得非常重要，而且在生產(chǎn)集群中要謹(jǐn)慎運(yùn)行那些無(wú)法預(yù)知將會(huì)耗費(fèi)多少內(nèi)存的查詢(xún)。

不過(guò)，隨著Elasticsearch越來(lái)越成熟，這個(gè)問(wèn)題很可能會(huì)得到改善，記住Elasticsearch的目標(biāo)是追求速度，所以它假設(shè)內(nèi)存永遠(yuǎn)是充足的。

分布式

另請(qǐng)參考: Elasticsearch in Production, Networking.

Shay Banon在創(chuàng)建Elasticsearch之前，在Compass工作過(guò)。由于意識(shí)到它很難轉(zhuǎn)變成一個(gè)分布式的搜索引擎，他就從頭開(kāi)始創(chuàng)建了Elasticsearch¹。 Elasticsearch被設(shè)計(jì)成分布式的且易于擴(kuò)展，用來(lái)在商用硬件上處理海量數(shù)據(jù)。

作為一個(gè)分布式的系統(tǒng)，Elasticsearch的上手和使用都令人難以置信的簡(jiǎn)單，但是分布式系統(tǒng)本身是很復(fù)雜的。關(guān)于這一點(diǎn)，我們?cè)贓lasticsearch in Production, Networking有更多討論，所以下面只是一個(gè)簡(jiǎn)短的摘要。

分布式系統(tǒng)天生的特性，意味著很多事情都可能會(huì)出錯(cuò)。同樣的，不同的數(shù)據(jù)庫(kù)系統(tǒng)致力于擁有不同強(qiáng)項(xiàng): 有些力爭(zhēng)強(qiáng)大的安全保證，另外一些則致力于高可用性，即使某些時(shí)候（甚至多數(shù)時(shí)候）出現(xiàn)錯(cuò)誤也在所不惜。而且，正如Kyle Kingsbury在他杰出的網(wǎng)絡(luò)分區(qū)的風(fēng)險(xiǎn)系列文章中所指出的那樣，當(dāng)問(wèn)題發(fā)生時(shí)，實(shí)際上數(shù)據(jù)庫(kù)系統(tǒng)并沒(méi)有像它們所宣稱(chēng)的那樣來(lái)處理問(wèn)題。簡(jiǎn)言之，他發(fā)現(xiàn)當(dāng)分布式數(shù)據(jù)庫(kù)運(yùn)行良好晴空萬(wàn)里時(shí)，絕大部分?jǐn)?shù)據(jù)庫(kù)在遭受到大量可能的問(wèn)題時(shí)所做的努力，都會(huì)以失敗而告終。

Elasticsearch 選擇自己的主節(jié)點(diǎn)。然而這是一個(gè)相當(dāng)簡(jiǎn)單但不是非?？煽康乃惴ǎ@在現(xiàn)實(shí)世界的網(wǎng)絡(luò)壓力下可能導(dǎo)致很多問(wèn)題。事實(shí)上，我們管理成百上千的集群，經(jīng)常看到主節(jié)點(diǎn)選擇問(wèn)題，因此我們主動(dòng)將主節(jié)點(diǎn)移入ZooKeeper， 當(dāng)然我們也有其他目的。

在拓展性方面，索引被分到了一個(gè)或多個(gè)碎片中。這在索引創(chuàng)建時(shí)就指定了并且不能改變。因此，隨著預(yù)期的增長(zhǎng)，一個(gè)索引應(yīng)該被合理的分割。隨著越來(lái)越 多的節(jié)點(diǎn)添加到Elasticsearch集群中來(lái)，它在重新分配和移動(dòng)碎片上表現(xiàn)良好。因此，Elasticsearch很容易拓展。

安全

另請(qǐng)參閱: Elasticsearch in Production, Security.

Elasticsearch沒(méi)有提供授權(quán)和認(rèn)證特性。你可以認(rèn)為，任何人只要能連接到你的Elasticsearch集群，就擁有了“超級(jí)用戶(hù)”權(quán)限，尤其是當(dāng)Elasticsearch的強(qiáng)大腳本功能被激活時(shí)。