elasticsearch作為一款開源的全文搜尋引擎在如今的軟體開發得到了越來越廣泛的應用，在業務功能開發方面，可以選用elasticsearch提供比資料庫查詢更強大的搜尋方式，同時基於搜尋結果評分（權重）和高亮讓我們很輕易地通過它實現乙個站內的搜尋引擎。
剛接觸elasticsearch（es）時我們經常將它與資料庫模擬起來學習，從結構上：
儘管如此，es本質上的定位仍是乙個搜尋引擎。nosql和es一樣都有著相同鬆散的結構，雖然我們也有一些討論是否可以用es來替代非關係型資料庫(撇開es是不是一種nosql)，但是乙個現實是es和nosql依舊是互有利弊；再者，傳統關係型資料庫的事務性、多表關聯結構也是es無法提供的。
所以，在實際的開發過程中，關係型資料庫、nosql、es依舊是相輔相成的關係，我們一般只會在較複雜的搜尋場景下會選用es提供搜尋服務，而其源資料依舊來自於資料庫，所以這就引出了es與資料庫之間的資料同步問題。
在第一次將儲存在資料庫裡面的資料匯入到es需要執行全量匯入，當後續有資料更新時通過訊息佇列通知es更新資料。
訊息佇列在軟體開發領域是乙個十分常見的名詞。
在作業系統層面，我們可以利用訊息佇列做程序間的通訊；在乙個單體應用，比如android應用，利用乙個messagequeue類來解決ui執行緒與耗時子執行緒之間的介面重新整理問題，在物聯網領域，基於發布/訂閱模型模型的mqtt協議被廣泛應用於平台對海量裝置的訊息分發，而在分布式系統，以及最近幾年日益熱門的微服務架構中，是乙個十分常用的實現非同步訊息、解耦應用、最終一致性的元件。
常見的訊息佇列採用「發布-訂閱」模式，初入門者幾乎可以認為這是個「觀察者模式」。
訊息佇列模式-「發布-訂閱」模式
es索引更改發生在elasticsearch 索引結構發生變化，比如隨著業務的發展對type中字段的增減以及字段型別的更改，或者發生在es版本公升級帶來的結構變化時，例如es 5.0版本將之前的string型別拆分為text和keyword型別，當我們希望對es進行版本公升級時，那麼之前的string型別就不可再用了。
與常見的web服務的藍綠部署實現無宕機公升級類似，es無縫公升級也可以模擬實現。web服務的藍綠部署的原理是使用loadbalancer（負載均衡器）做流量切換，新舊服務都有不同的訪問url，但是只有loadbalancer的url對外可訪問，即：
藍綠部署
es提供了通過索引別名（alias）來訪問索引的方式：比如
}就為索引test_20181007建立了一條別名test，這樣訪問localhost:9200/test/_search和localhost:9200/test_20181007/_search都可以搜尋索引裡面的內容。
es的別名的存在為es的無縫公升級和切換提供了可能，類似於負載均衡切換指向一樣，我們可以讓es別名在公升級前後，指向新舊不同版本的索引即可。
put /test_v2
, }
}
post /_aliases
}, }]}
delete /test_v1Elasticsearch 搜尋資料
elasticsearch 修改資料 elasticsearch 搜尋資料 現在我們已經了解了基本知識，讓我們嘗試使用更真實的資料。我們提供了一些虛構的客戶銀行賬戶資訊，格式如下所示 curl localhost 9200 cat indices?v 響應 health status index u...
二 elasticsearch入門（資料）
程式中大多的實體或物件能夠被序列化為包含鍵值對的json物件，鍵 key 是字段 field 或屬性 property 的名字，值 value 可以是字串 數字 波爾型別 另乙個物件 值陣列或者其他特殊型別，比如表示日期的字串或者表示地理位置的物件。accounts 文件元資料 乙個文件不只有資料。...
elasticSearch修改資料
elasticsearch幾乎能實時提供資料操作和搜尋功能。預設情況下，從開始索引 更新 刪除資料到出現搜尋結果的時間可以認為需要一秒的時間。這是與sql等其他平台的重要區別，其中資料在事務完成後可以立即使用。在上節中我們給索引建立了乙個文件，命令為 put customer doc 1 prett...