一、問題描述
公司想嘗試使用Elasticsearch來存一部分數據，以此緩解數據增長帶來的對數據庫的壓力。在研究了一段時間后，發現Elasticsearch不適合作為數據存儲使用。
二、理由如下
1、mapping不可改，不能改index屬性。Elasticsearch中以定義的mapping不能修改名字和屬性，無法修改名字勉強能接受，但無法需要改屬性。
官方文檔中介紹了幾種修改mapping的方法。一個是新建一個字段，程序中所有地方修改名字，這對於復雜的項目容易出錯，而且無法保留原來的數據；另一個是利用aliaa創建一個新的索引，但是所有數據需要重新導入，這需要很長時間，操作性不強。
2、無法多對多。Elasticsearch中提供3中關聯關系，Field collapsing（嚴格來說不是關聯），Nested object，Parent-child。前兩種都是直接將一個mapping聲明在另一個mapping中，第三種關聯是在創建子文檔是指明他的父文檔，但是一個子文檔只能有一個父文檔，因此也不能實現多對多的關聯。其實如果理解了ES的目的是提升檢索效率，就不難理解為什么沒有多對多關聯了，在關系數據庫里這就是個效率瓶頸。
3、沒有用戶驗證和權限控制。ES本身的訪問權限可以通過nginx進行控制，但是同一個ES中不同索引間目前是沒有權限控制的。從ES設計的初衷看，為了檢索，為了統計。這個從字段的store屬性中可以看出來，查看ES手冊（https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-store.html）可以發現，默認情況下字段的原始值是不會被保存的，這跟數據存儲是南轅北轍了。
4、項目開始時不好確定shards數量。少了以后擴展不方便，多了一開始影響性能。這個可以通過將type命名為doctype-yyyymmdd來解決，每天都生成新的一個或多個shard，但是注意在搜索時需要在doctype-*中搜索。
5、ES非常適合特定的需求，但不適合用於數據存儲。ES索引速度快，擴展方便，性能優異，但在功能上不適合作為數據庫使用。數據存儲的目的是為了以后能方便的使用，不僅是針對當前的需求，也要為未來可能出現的需求做准備。由於ES有以上幾點問題，無法適應需求變化。
ES適合的場景
1、檢索。ES本身作為一個搜索引擎，用來處理檢索的任務再合適不過。你可以在線上項目中直接將內容寫入ES以提供檢索服務，也可以把以往的數據導入ES以處理特定的需求。關於ES和Solr的比較以后有時間的話會寫一篇
2、統計。ES的統計也是基於檢索功能的，聚合功能使得統計結果處理起來非常方便。如果你只需要統計而不用檢索，可能有其他工具更適合你，比如Spark SQL。