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
重磅 | 死磕Elasticsearch方法論認知清單（2019國慶更新版）
更短時間更快習得更多幹貨！
