轉載（原文連結）：https://blog.csdn.net/laoyang360/article/details/103379651

0、引言

 現在幾乎網上所有資料都說資料儲存在傳統資料庫，再在 es 中同步一份資料作為檢索使用，但是也都沒有很詳細的說明為什麼要這麼做，而且在 es 本身可以儲存資料的情況下，儲存兩份資料是不是沒有必要？還會引起別的問題。

雖然收費而且支援的語法不完全，但是在現在 es 已經支援 sql 的情況下，我越來越搞不清楚 es 和資料庫之間的界限。

es 不支援事務但是能夠確保單條資料的寫入，這樣事務可以通過程式碼實現。很難進行聯合查詢可以像其他 nosql 一樣用寬表實現。實時性可以通過配置調整，而在擴充套件效能和複雜統計上肯定 es 更優。

基於以上疑問，請問現階段 es 與資料庫的區別或者說界限到底在哪？

https://elasticsearch.cn/question/8885

——來自社群的提問

其實拿傳統關係型資料庫和 Elasticsearch 直接來對比有些牽強，畢竟一個是資料庫，一個是搜尋引擎。

如果硬要對比，我們剝繭抽絲，一點點探究一下 Elasticsearch 與傳統資料庫的不同。

1、使命不同

Oracle 對關係型資料庫的定義：

關係型資料庫，是指採用了關係模型來組織資料的資料庫，其以行和列的形式儲存資料，以便於使用者理解，關係型資料庫這一系列的行（包含唯一 key 的記錄）和列（儲存了屬性）被稱為表，一組表組成了資料庫。

Elasticsearch 的官方定義：

Elasticsearch 是一個分散式的開源搜尋和分析引擎，適用於所有型別的資料，包括文字、數字、地理空間、結構化和非結構化資料。Elasticsearch 在 Apache Lucene 的基礎上開發而成，由 Elasticsearch N.V.（即現在的 Elastic）於 2010 年首次釋出。Elasticsearch 以其簡單的 REST 風格 API、分散式特性、速度和可擴充套件性而聞名，是 Elastic Stack 的核心元件；Elastic Stack 是適用於資料採集、充實、儲存、分析和視覺化的一組開源工具。人們通常將 Elastic Stack 稱為 ELK Stack（代指 Elasticsearch、Logstash 和 Kibana），目前 Elastic Stack 包括一系列豐富的輕量型資料採集代理，這些代理統稱為 Beats，可用來向 Elasticsearch 傳送資料。

A relational database can store data and also index it.

A search engine can index data but also store it.

如上可通俗解讀為：

關係資料庫可以儲存資料併為其建立索引。

搜尋引擎可以索引資料，但也可以儲存資料。

2、適用場景不同

關係型資料庫更適合 OLTP（是一種以事務元作為資料處理的單位、人機互動的計算機應用系統，最大優點：最大優點是可以即時地處理輸入的資料，及時地回答）的業務場景；而 Elasticsearch不能當做純資料庫來使用。

原因 1：不支援事務，

原因 2：近實時而非準實時，由 refresh_interval 控制，最快 1s 資料寫入後可檢索。

Elasticsearch 適合 OLAP的場景（它使分析人員能夠迅速、一致、互動地從各個方面觀察資訊，以達到深入理解資料的目的。側重分析）。

舉例：

海量日誌分析和檢索、

海量大文字的全文檢索等。

3,儲存型別不同

關係型資料庫一般只支援儲存結構化資料（pgsql 支援 json）。

結構化資料的特點：

由二維表結構來邏輯表達和實現的資料

嚴格地遵循資料格式與長度規範。

舉例：銀行交易資料、個人資訊資料等。

而 Elasticsearch 支援關係型和非結構化資料，如：json 由 object 或者 nested 型別或者父子 Join 儲存。

非結構化資料的特點：

資料結構不規則或不完整；

沒有預定義的資料模型，不方便用資料庫二維邏輯表來表現的資料。

舉例：包括所有格式的辦公文件、文字、圖片、XML,HTML、各類報表、影象和音訊/視訊資訊等等。

腦海中想一下：是不是實戰中遇到：資料結構不定、欄位個數不定、欄位型別不定、是否動態新增不定等多變的業務場景？

4,可擴充套件性不同

關係型資料庫通病， 如：mysql 單表支援資料量有限，資料量大了就得分庫分表，再大了考慮分散式，原生分散式的瓶頸如下：

分庫分表非常麻煩，

業務依賴性高，

複雜查詢會出現錯誤，

更重要的是分散式事務無法有效處理。

催生了很多第三方 NewSql 公司如：TIDB（開源+解決方案付費）。

而 Elasticsearh 支援橫向擴充套件，天生支援多節點叢集部署，擴充套件能力強，甚至支援跨叢集檢索；能支援 PB+的資料。

國內的：滴滴、攜程、順豐、今日頭條、bat 等很多核心資料業務都已經通過 Elasticsearch 實現。

5,解決問題不同

關係型資料庫針對核心：增刪改查的業務場景，對於全文檢索會慢的要死（很多客戶遷移 Elasticsearch 就是這個原因，早期用 lucene 後用 solr，但發現 Elasticsearch 更好用）；而 Elasticsearch 的倒排索引機制更適合全文檢索。

實際業務中：

如果資料量不大，建議使用簡單的關係資料庫結合簡單的 SQL 查詢就能解決問題。

如果您對效能沒有問題，請保持架構簡單並使用單個數據庫儲存，必要時加些快取（如 redis）。

如果您在搜尋中遇到效能問題，則可以將關係型資料庫和 Elasticsearch 結合使用。

6,資料模型不同

關係型資料庫通常針對複雜業務會多表設計、不同表不同模型，多表通過 join 關聯或者檢視查詢。

而 Elasticsearch 支援複雜業務資料，通常不建議多表關聯，確切說 Elasticsearch 倒排索引機制決定了它天然不適合多表關聯。複雜業務資料通常解決方案：

1,寬表（空間換時間）；

2,nested

3,父子關聯 join（針對頻繁更新場景）。

對於聚合業務場景，的確大資料量（千萬級以上）多重巢狀全量聚合 es 會很慢，業務選型可以考慮其他輔助方案。

7、底層邏輯不同

傳統資料庫的儲存引擎為 B+樹，包括 ES 的很多 NOSQL 資料庫使用的 LSM Tree，對寫操作支援更高效。

為什麼 Elasticsearch/Lucene 檢索可以比 mysql 快？

Mysq 的分詞詞典（term dictionary）是以 b-tree 排序的方式儲存在磁碟上的。檢索一個 term 需要若干次的隨機訪問磁碟操作。

而 Lucene 在分詞詞典的基礎上添加了 term index（以 FST（finite state transducers）形式儲存，非常節省記憶體）來加速檢索，term index 以樹的形式快取在記憶體中。從 term index 查到對應的 term dictionary 的 block 位置之後，再去磁碟上找 term，大大減少了磁碟的隨機訪問次數。

8、小結

所以，沒有最牛逼“一招先,吃遍天”的方案，只有最適合的方案。

適合自己業務場景的才是最好的！

其他歡迎補充。

參考：

[1] https://stackoverflow.com/questions/51639166/elasticsearch-vs-relational-database 

[2] https://zhuanlan.zhihu.com/p/73585202 

[3] https://www.elastic.co/cn/what-is/elasticsearch 

[4] https://www.oracle.com/database/what-is-a-relational-database/ 

[5] https://zhuanlan.zhihu.com/p/33671444

END