自從 BiMAP 代理 InfluxDB 以來，不斷有客戶詢問與 Elasticsearch
的差異，以及如何選擇的問題。我們可以大致將需求分為兩種，一種是正在評估新的解決方案，以及正在使用
Elasticsearch，但同時也在尋找更好的解決方案。
在近幾年的 Log
解決方案中，已經有許多優秀的產品可以選擇，不管是架構、擴充性、效能。而開發人員在使用上也越來越簡單，好上手，所以在許多客戶的服務經驗當中，需求反而不是最擔心的事情，主要在於
Infrastructure 的消耗，與長期使用性的 CP 值是否符合預期。
主要量測面向：
- 資料收容的能力
- 硬碟儲存的容量要求
- 查詢平均的反應時間
官方數據：
- Server 數量：100
- 每台 Server 的量測單位：100
- 測量間隔：10s
- dataset 的集中時間：24h
- dataset 每天：87 M
與優化後的 Elasticsearch 比較：
- 快了 3.8 倍 write throughput
- 少了 90 倍的 disk 空間
- 快了 7.7 倍的系統回應時間
但效能上的比較其實意義不是太大，因為從最一開始的出發點，就是不一樣的。InfluxDB
從一開始的理念就是以 time series 為出發點，採用目前最火紅的 Golang
開發，同時也是筆者目前最常用的語言，所以不管是在效能，或是 Server
資源使用上，表現都非常出色，而且部署非常方便。Influxdb
除了兼具以上性能外，它並不需要額外的 config 去設定 schema，而且 query
language 也是針對 time series 去設計的。
InfluxDB
的應用相較於 Elasticsearch 來說，應用並不那麼的廣泛，像是全文檢索、Log
的各種管理情境，可能就不是強項，最主要的應用在於 infrastructure
metric、IoT、container、sensor 等等與 time series 關聯性比較強的應用。
Elasticsearch
是一個非常完整的企業級解決方案，旨在解決企業中可能遇到的各種情境，從資料收集到儀表版的製作，都有非常多的解決方式，但
Elasticsearch 並不能算是 time series資料庫，且會需要預先決定好一些設定，比如
indexing、heap sizing，甚至可能要懂一些
JVM，如果效能上不足的話，不仿可以參考這篇來校調您的
Elasticsearch。所以如果是希望用一套解決方案，來進行企業內部的各種應用的話，可能還是
Elasticsearch 比較適合。
所以回到最一開始提及的，該如何選擇，還是取決於您是否為 time series
類型的應用，如果是，則 InfluxDB 是您的不二選擇，否則 Elasticsearch
可能還是比較長久之計。
