![有关扩展 ElasticSearch 的统计信息](https://linux22.com/image/647260/%E6%9C%89%E5%85%B3%E6%89%A9%E5%B1%95%20ElasticSearch%20%E7%9A%84%E7%BB%9F%E8%AE%A1%E4%BF%A1%E6%81%AF.png)
我设置了多个 Logstash 节点将输入发送到 ElasticSearch,并且有一个 kibana 服务器可以让我将其可视化。
当前的基础架构非常简单,并且位于单节点机器上。我们希望将其扩展到更大的测试平台。然而,在投资扩展 ELK 的大规模部署之前,我希望更好地了解它的扩展能力和性能参数。
我在 Elastic Search 网站或其案例研究中找不到相关数字
问题如下:
Elastic Search 的扩展性如何?每秒可以处理多少日志,需要多少个节点?任何数字或见解都可以。
它在时间作为索引时的表现如何,我们认为用例更多的是结构化查询。特别是它与 SQL 之类的数据库相比如何。提出的一个问题是,如果我们事先知道日志结构,使用 SQL 数据库会更好吗?如果性能是一个很大的瓶颈,我们不一定需要搜索引擎功能。?
我是 ELK/SQL 服务器管理的新手,所以如果问题不太明确,请多包涵。
答案1
这实例探究elastic 的网站上确实有一些数字,例如来自 data dog 案例研究:
在 Stack Exchange 中,我们发现弹性伸缩性非常好(用于 logstash、haproxylogs(每天约 1.5 亿条日志条目)和 syslog/eventlog 以及搜索此站点),但你需要做的第一件事是量化你的负荷. 使用 elastic 的话,它将会像这样:
- 文件(日志条目)率
- 查询率
- 数据大小
ETC...