共计 2074 个字符，预计需要花费 6 分钟才能阅读完成。
12 月 15 日, 即便天气寒冷，飘着雨。跨星空间座无虚席由袋鼠云、阿里云、elastic 中文社区主办袋鼠云、阿里云、有赞、滴滴的技术大牛倾囊相授~
“ElasticSearch 运维技术实践”精彩上演！
Now，温故而知新，一起来回顾吧~
干货来啦，别带着它入睡，赶紧拿小本本记下来吧！
解 惑 篇
在此本萌特别精编了一辑本场沙龙现场讲师和学员的 A &Q，分享给大家~
阿里云 Elasticsearch 实时计算平台实践
Q：使用时一边构建索引一边查询，性能会下降，如何处理？
A：
架构
1）增加 clientnode, 降低 DataNode 的 CPU 开销
2）换更好的硬件，多盘组成 RAID 或 SSD
配置
1）增大 translog flush 时间间隔
2）增加索引 refresh 时间
3）调整 merge 速度，调小 index.merge.scheduler.max_thread_count 和 merge.policy.max_merged_segment，增大 merge.policy.segments_per_tier
4）调整 mapping，不需要分词的字段不用 text 改用 keyword
具体的还是要根据业务场景去测试和做取舍
Q：ES 取消 translog 还有副本吗？性能提升 4 倍是指在哪些方面？
A：
elasticbuild 是用于离线 build，所以不需要副本，依赖的 HDFS 自身有副本机制；去掉 tranlog 和内存 merge 减少 IO 开销以及网络开销。
Q：写入 HDFS 的数据，如何恢复到 ES？增量如何处理？
A：
在全量结束后会做一个 snapshot 到 OSS 上，然后再 restore 到在线集群。bahamut 在拉起全量 build 任务的时候会记住全量启动的数据时间戳，然后增量任务从记录的时间戳开始补数据。
袋鼠云百亿日志数据下 ES 性能优化实践
Q：5 台节点，master 节点经常负载较高，两台 MI，三台 DI，合理吗？
A：
master 建议 3 台以上类似于 zk 三节点的原理防止脑裂。
Q：索引规划，分片不超过 40G，每个 node 不要超过 3 个分片，32G 的内存配置下，每个分片 1Gbuffer，有测试过吗？
A：
分片越多，写入性能更好，分片更多，分片的管理性能消耗增加，对单个索引来说。
Q：分片初始配置后不要修改？三台服务器最多分片数？
A: 改，除非做 reindex 的操作，建议最多不要超过 12 个（包括副本分片）
Q：冷热数据处理，怎么做？如何区分冷数据？查询冷数据体验如何提高？
A：
在我们使用日志的场景中，超过 3 天或 7 天的数据定义为冷数据，冷数据迁移到大存储的节点（OSS）；查询时需要恢复到热节点，恢复有一定的时间。对用户来说有冷热数据存储的概念。
Elasticsearch 的索引和集群隔离实践
Q：索引是每 30S 刷新一次，刷新的那一刻 rp 比较高，如何降低影响？A：
1）建议把数据做拆分，热数据刷新频率高一点，冷数据刷新频率低一点
2）可以适当看下缩短刷新时间能否平滑毛刺
3）数据变更太频繁的内容考虑做下采样，减少更新次数
Q：多索引查询时怎么提高性能？不同索引 mapping 不一致，解析 response 耗时长 A：
1）从查询本身上做优化
2）response 在业务层做多线程处理；
3）加缓存，经常查询的数据结果记录在缓存中；
4）执行中断，查询一部分结果就返回，查询高并发性能不行的。
滴滴 Elasticsearch Query DSL 分析系统
Q：mapping 优化中对用户使用习惯未知，优化的意义在哪？A：
ES 默认对所有字段建立索引，通过 mapping 优化，可以自动化的把索引中用户查询不使用的字段不建索引来节省成本。自动化体现在用户新增或者减少字段能被系统自动感知到，从而减少和用户沟通成本。
Q：有哪些用户？查询的索引中不同字段的数据量是不同，此时进行聚合查询怎么办？A：
滴滴内部使用 ES 的同学，例如客服，运维和 RD。我们会得到查询语句中根据哪个字段进行聚合，另外每个字段基数会由其他服务进行统计，例如根据 IP 字段进行聚合，由于 IP 基数过大 (count distinct IP)。如果是针对大基数字段进行聚合查询预估消耗内存较大时，就会把这种查询熔断。
Q：还没有数据进来时没有建索引时，是自动生成索引还是动态映射？A：
每一类数据写入索引前会根据这个索引中索引模板信息进行映射，在索引模板中会定义一些字段对应的类型，例如字符串内容符合 date format 的字段就会映射成 date 类型。没有在索引模板中找到的字段其类型由 es 根据第一次出现这个字段的内容推导，例如字符串自动映射成 keyword 类型。
Q：复杂的聚合查询如何处理？A：
聚合查询嵌套不能太深 (一般不要超过 3 层)，当然这个跟聚合查询的索引中聚合字段的基数有关，如果字段基数大聚合产生的桶就会有很多，消耗的内存也会很大，需要对消耗内存大的聚合查询语句进行熔断。至于复杂的聚合语句优化，
可以从减少聚合返回的 size，合理调整聚合字段顺序，使用 date_histogram 来代替 histogram 等。
Q：gateway 是自研的吗，是否会考虑开源？A：
gateway 是自研的，后期会开源。
