如何在Elastic cloud上选择合适的Elasticsearch service

文章目录

Elastic cloud简介
Elasticsearch service配置选择
- 服务提供商
- 数据中心
- 集群配置
- 选择服务的例子（Hot-Warm Architecture）
总结

Elastic cloud简介

Elastic Cloud是Elastic不断增长的SaaS产品系列，它使我们能够轻松地在云中部署、操作和扩展elastic的产品和解决方案。从易于使用的托管和管理的Elasticsearch体验到功能强大的开箱即用搜索解决方案，Elastic Cloud是您无缝地将Elastic应用于您的工作的跳板。

目前，Elastic Cloud主要提供以下三种服务：

Elasticsearch service
Elastic App Search Service
Elastic Site Search Service

这篇文章主要介绍的是Elasticsearch service

Elasticsearch service配置选择

服务提供商

在Elastic cloud上选择Elasticsearch service，主要是使用官网上的报价页面进行查询。
目前，Elastic cloud已经在各大云厂商上提供了Elasticsearch service服务。包括：

AWS
GCP
Azure

(阿里云和腾讯云目前是自己提供Elasticsearch service服务，但阿里云和腾讯云也是elastic的合作伙伴，提供的也是完全版的Elasticsearch service服务)

选择哪个基础服务提供商其实没什么好说的，你的数据在哪就选哪个，其他都差不多。

数据中心

AWS：

GCP：

Azure:

也没什么好说的，你的数据在哪就选哪个，但很明显，AWS的数据中心最多。如果你还在考虑应用部署在哪，同时又打算使用Elasticsearch service，考虑数据中心多的。

集群配置

Elastic cloud根据不同的使用场景，提供了不同的集群配置选择方案：

I/O Optimized，I/O优化型。适用于大多数场景，是一个平衡考虑了计算，内存和存储的集群配置组合。当数据量不大，不是特殊用途的Elastic场景，建议使用该配置
Compute Optimized，计算优化型。举个例子，ES+Hbase的架构。当你使用ES来索引大量文档和提供全文检索，而不存储，而使用Hbase作为数据存储的时候，你可以使用这个配置
Memory Optimized，内存优化型。平时的使用场景中，常用ES去分析数据，聚合运算的推荐使用。
Hot-Warm Architecture，冷热部署的架构。适用于时序型数据的场景，比如日志，交易记录等，数据会因为新旧而有使用频率的区别。
Cross Cluster Search，跨集群查询的集群。不存储任何数据，只是作为一个Gateway的集群。

选择服务的例子（Hot-Warm Architecture）

假设你现在有4个T的交易数据准备放到ES当中，由ES提供查询和全文检索的服务。你需要考虑以下几件事情：

你的数据在哪？比如说，你的应用服务器都部署在AWS上，数据由应用产生，那么，你应该选择以AWS作为Elastic cloud elasticsearch service的平台
你的用户在哪？如果你的用户主要集中在中国，你可以选择新加坡或者东京的数据中心
数据的冷热结构。需要搞清楚，用户在查询或者检索数据的时候，最常检索的是哪部分数据，一般来说，最近的数据查询和检索的频率最高，越旧的数据被查询和检索的可能性越低。如果能够对客户的query数据进行一个采样，则可以进一步制定合理的数据存储策略：
- 正在被写入和查询频率最高的数据，使用最好I/O性能的存储，比如SSD
- 区分读写和只读的索引，对于不会再被更新的索引设为只读，并且可以放到成本更低的机械硬盘存储
- 对于访问频率最低的索引，冷冻之（freeze），甚至考虑close
并发的量有多大。因为索引的replica可以动态调整，可以先用1副本的方式进行压测，如果调优无果，再考虑增加副本来应对并发。
数据容灾的需求。是否需要跨数据中的备份

以4个T的交易数据为例，选择了AWS的平台和法兰克福的region。因为交易数据是时序性数据，天然适合Hot-Warm架构，选择了Hot-Warm Architecture

可以看到该架构下，数据节点分为高I/O节点和高存储节点两种:

高I/O节点下，4G内存/120G的存储（亚马逊i3：Amazon EC2 I3 实例具备基于非易失性存储器标准 (NVMe) SSD 的实例存储，经过优化可实现低延迟、极高的随机 I/O 性能、高速连续读取吞吐量，并能以较低的成本提供高 IOPS。I3 实例可提供高达 25Gbps 的网络带宽和高达 14Gbps 的专用 Amazon Elastic Block Store (Amazon EBS) 带宽。）
高存储节点下，4G内存/400G的存储（亚马逊d2：D2 实例拥有高达 48TB 的 HDD 本地存储，具备高磁盘吞吐量，并在 Amazon EC2 上提供了最低的磁盘吞吐量性能单位价格。）

master和machine learning可选，默认不选；APM可以Disable。

4个T的交易数据，假设是1年的时间，在没有用户采样的情况下，可以先做以下假设：

假如交易均匀，则每天大概11.2G的数据，考虑倒排索引和存储效率，假设11.2G的RMDB数据存储到ES中有大概15G，在考虑1副本的情况下，一天的数据大概在30G；
一周内的数据查询频率最高，使用SSD，则30 * 7 = 210G，则高I/O节点的需求为： 210G / 120G = 2。即： 8G内存/240G
剩余的数据都存储在HDD本地存储上，则 30 * 358 = 10740G，则高存储节点的需求为 10740G/400G = 27。即：108G内存/10800G
不做跨数据中的备份
不使用APM

则选择的配置为：

每小时~7美元，61320刀/年

TIPS: 实际上，Enable APM 之后，报价没有发生变化，所以建议是不要Disable APM

总结

Elastic cloud的Elasticsearch service提供了自动托管和完整的X-pack功能，对于商用业务和ES服务的整合是一个完美的选择。但在控制成本的前提下，建议先使用最小满足配置，使用动态扩容的弹性，配合Elastic stack本身完备的日志分析和监控功能，监控ES服务本身的吞吐和性能，在发现跟不上需求时再去做合理的扩容。