> Elasticsearch 是一個可用於分散式以及符合RESTful 風格的搜尋和資料分析引擎。—— [Elastic Stack 官網](https://www.elastic.co/cn/elasticsearch/) ### 關於Elasticsearch的愛恨情仇 - 或許提起搜尋伺服器,大部分人都會想起Solr 和 Elasticsearch 甚至以及國產大廠自研等。隨著人工智慧和大資料時代的到來，甚至還帶動了一系列的機器引擎的出現，譬如Splunk等。其中Solr 和 Elasticsearch是基於Lucene的搜尋伺服器。一般Solr是面向的是全文檢索引擎，而Elasticsearch是用於全文搜尋、結構化搜尋、分析。而對於Splunk機器資料的引擎，可收集、索引和利用所有應用程式、伺服器和裝置生成的快速移動型計算機資料。可是不論技術如何發展和更替，作為一位程式設計師，我們要做的不就是即時地維護技術儲備知識庫和實時更新自己的技術快取，以及實現可擴充套件性的技術深度樹的增長。 - 關於Elasticsearch，記得當時接觸到Elasticsearch的名詞的時候，那是2017年的夏天。當時的工作任務是實現一個關於知識庫的系統。當時小夥伴們技術選型主要還是偏向Solr+Lucene來的做，有的甚至說直接使用Mysql資料庫的自帶函式來做。我是在無意中，在網上查詢搜尋引擎的技術實戰的時候,看見了一篇對於Elasticsearch應用實戰的應用報告分析，才去查詢了Elasticsearch的相關資料。不過，當時網上大部分對於搜尋功能的Demo，大部分還是關於Solr 的比較多。也許在那個時候，大部分的技術概念基本都是偏向於技術長期穩定和文件資料全，使用程度相對較重的因素。但是，我個人卻留了一個心眼，自己嘗試去實戰Elasticsearch。 - 第一次，動手實操還是在Windows本機上安裝(22G記憶體)的。其中，安裝過程相比利用Tomcat+Solr來說，相對較複雜，而且對於本機的記憶體和功耗佔用較重。個開發基本只能說是能執行起來，可穩定性方面，就有點顯得望而卻步的感覺。第二次，動手實戰是在本機搭建了一個虛擬機器去實戰(2核8G)，可在網路通訊方面，當時選的是網路橋接方式，也讓我對此覺得很是麻煩。第三次，是自己擁有了自己的阿里雲伺服器，在上面按照傳統部署方式(相對於Docker部署來說)，可無奈個人伺服器記憶體較低(2核4G)，修改配置JVM等無法啟動成功，總是丟擲GC日誌什麼的問題，主要還是當時囊中羞澀的問題，甚至一旦執行Elasticsearch服務，其它的應用便無法啟動和 執行。後來，接觸了Docker，於是，有了第四次的Elasticsearch實戰（單節點部署）。第四次，升級了阿里雲伺服器的配置(2核8G)，最終實現了額自己的第一個Elasticsearch服務。甚至，為在後來工作中，動手實戰Elasticsearch分散式叢集服務奠定基礎。 ### 基本概述 * 似乎從某種意義來說Elasticsearch和MongoDB/Redis/Memcache一樣，是一種Nosql資料庫。是一個接近實時的搜尋平臺，從索引這個文件到這個文件能夠被搜尋到只有一個輕微的延遲，企業應用定位：採用Restful API標準的可擴充套件和高可用的實時資料分析的全文搜尋工具。不過在當時，Elastic Stack只有Elasticsearch、Kibana 和 Logstash用例，還沒有包含Beats等。而且在應用方面，除了來當作ELK分散式日誌系統搭建外，更多的是Elasticsearch +Elasticsearch-Head外掛在滿足業務場景方面的需求，能夠安全可靠地獲取任何來源、任何格式的資料，然後實時地對資料進行搜尋、分析和視覺化等。 * 基本特點： 1. 可拓展：支援一主多從且擴容簡易，只要cluster.name一致且在同一個網路中就能自動加入當前叢集；本身就是開源軟體，也支援很多開源的第三方外掛 2. 高可用：在一個叢集的多個節點中進行分散式儲存，索引支援shards和複製，即使部分節點down掉，也能自動進行資料恢復和主從切換 3. 採用RestfulAPI標準：通過http介面使用JSON格式進行操作資料 4. 資料儲存的最小單位是文件，本質上是一個JSON 文字 ### Elasticsearch關鍵詞 * **Node** : 節點，單個裝有Elasticsearch服務並且提供故障轉移和實現可擴充套件的伺服器 * **Cluster** : 叢集，一個Elasticsearch-Cluster叢集是有一個Node或者至少2個Node組成的伺服器，共同服務和分享Node節點資料的具有負載均衡的功能，甚至基於Zookeeper叢集的高可用服務等。 * **Index** : 索引,具有相同或者相似特徵的Document文件物件的集合 * **Type** : 型別，相同Filed欄位的文件定義一個Type型別，一個Type可以建立多個Index索引 * **Document** ：文件，一個Document文件可以被用作Index索引的基礎資訊單元 * **Field** : 欄位列，Field是Elasticsearch的最小單元，相擋當於資料的某一列 * **Shards** ：分片，Elasticsearch把Index索引分成若干份，每一個部分就是一個Shard分片 * **Replicas** ： 複製，每個Inex索引裡每個Shard分片的拷貝或者說是資料備份 ### Elasticsearch 結構與其它資料庫對比 * 資料模型上的對比 | databaseType | databaseName | databaseUnit | databaseTable | databaseRow | databaseColumn | |------| ------ | ------ | ------ | ------ | ------ | |sql| Mysql|資料庫-database|表-table|資料行-row|資料列-column| |Nosql|Elasticsearch|索引-index| 型別-type| 文件-document|欄位列-field| |Nosql|Hbase|名稱空間-namespace| 域/切片-region|資料行-row|資料列-column| * 使用場景上的對比 | databaseType | databaseName |databaseStorage | databaseTransaction | databaseConsistency |databaseScalability| secondaryIndex | fullText | |------| ------ | ------ | ------ | ------ | ------ | ------ | ------ | |sql| Mysql|行數資料儲存,適用OLTP業務|Innodb引擎支援|strong consistency-強一致性|單機可拓展粒度不高|支援| 支援| |Nosql|Elasticsearch|索引儲存-任何檢索業務| 不支援| 支援可配置|水平拓展|支援|支援| |Nosql|Hbase|列式資料儲存,介於OLTP和OLAP模型之間| 不支援|strong consistency-強一致性 和 time consistency-時序一致性|水平拓展|不支援|不支援| 版權宣告：本文為博主原創文章，遵循相關版權協議，如若轉載或者分享請附上原文出處連結和連結