本文字数：1435
预计阅读：3~5分钟
您将了解：
1、数据写入导致的高并发集群打爆问题，如何解决？
2、TB、PB级数据如何降低存储成本？
3、原生Elasticsearch在时序查询上的瓶颈如何突破？
4、峰谷差异大，如何避免闲置成本？
【全链路云上Elastic Stack 全景图】100%兼容开源，9大独有能力
----> 直播回顾 | 请点击观看 ：
阿里云Elasticsearch日志增强版介绍寻根问源
日志场景面临的问题
日志场景是Elasticsearch使用中较为常见的场景，而大量日志数据让企业在追求经济效应与性能效应的同时，对产品本身提出了更为苛刻的要求。
1、高并发写入问题：
Elasticsearch在日志数据写入过程中，会同时对主副分片同步写入，还会去写开销较大的trancelog，从而造成Elasticsearch在高并发写入的时候，对机器CPU以及I/0的性能开销提出了更高的要求。
2、高存储成本问题：
日志数据的存储，往往需要对海量的数据进行存储，起步数据量都是在TB级别，有的企业甚至达到了PB级，而为了数据容灾性，还需要保存至少一个副本，这将对存储带来进一步的成本压力。
3、时序分析性能差
由于Elasticsearch的查询特征，会查一遍所有的segment，当你做较大范围range以及复杂聚合时，他的性能瓶颈就会立马凸显出来。
4、弹性可伸缩问题
日志随着业务变化，往往伴随峰值、均值和谷值的出现，且差异较大，企业通常为了解决峰值问题，会堆较多的机器已便满足峰值需求，那么“均值”、“谷值”期间就会造成机器资源大量浪费。
对【症】下药
1、计算存储分离：大幅提升日志高并发写入能力
计算存储分离的前提是将Elasticsearch的所有节点存基于NFS共享存储。【如图】数据流的写入请求，会先写到主分片，再写入到共享存储，而NRT segment会拷贝到临时目录，那么主分片与副分片在读取时就会存在差异，主分片仅读取commit segmen A，和refresh segment B，副分片读取的A’、B’。
计算存储分离的【核心思路】
1、 索引分片一写多读，且仅保留一个副本数据，降低存储成本，提升写入性能。
2、 依赖云存储保证数据可靠性：CTF底层具备三副本冗余机制，对云业务是透明的，保障数据不丢失。同时阿里云在面对极端情况下，备有分钟级的OSS自动备份机制，进一步提升数据可靠性。
3、 状态与索引分离。
4、 通过IO fence机制保证数据一致性，避免主进程僵死情况下双写的问题。
5、 内存物理复制降低主备延迟，从分钟级，降低至毫秒级。
2、秒级弹性扩缩容：避免因日志峰谷导致的“资源闲置”
3、物理复制状态机：不写实时索引，也能保证数据时效性
最佳应用实践
案例展示（部分集群）
案例背景：在阿里云搜索业务线上，有很多集团内、外的客户，会使用我们各种底层服务。为了保障各个业务之间不受影响，我们会对这些服务做一系列的监控，通过采集大量复杂的Metric做大量聚合，建立Dashboard。但除了做Monitor，相伴而生一定会有告警，也就是Alarming，那么这样一套监控、告警平台，底下使用的就是我们量身定制的日志增强版Elasticsearch。
架构解读
1、运用MetricBeats采集大量Metric数据，通过Gateway，向Elasticsearch集群去传输数据，写入量大概是40W docs/s。
2、传输数据中，有冷、热数据的区分，就需要将冷、热数据做切分配置。
3、由于需要对数据容灾处理，我们将数据自动快照到OSS里。
案例说明
我们通过计算后发现，如果用开源的Elasticsearch做同样的事情，所付出的成本将是该方案的一倍之多。因为不光是阿里云Elasticsearch增强版存储更便宜，同时为了时序Metric的场景更高的聚合效率，我们对阿里云内核也做了一些优化。
你如果是基于开源自建的ES集群，为了能够在聚合查询时有更好的性能，最直接的方式是冗余更多的datenote，来保证性能，当然这样会带来更高的费用，阿里云日志增强版针对性的解决了这个问题，不需要冗余过多的datanote，举这个例子是为了更好的帮助大家理解阿里云Elasticsearch日志增强版的能力
这套服务在阿里云内部是适用的，我们也对外提供同样的能力，供大家选择。
“宗师级”能力对比
数据来源：真实POC数据，开源Elasticsearch与日志增强版对比
- 同样性能，费用节约24%
- 同样客户需求，性能优越140%，成本减少43%
- 综合能力彰显“宗师级”
相关活动
扫码关注公众号‘Elasticsearch技术’，收获大咖最佳行业应用经验