云原生数据库系列谈：Eon 模式下性能和成本几何？我们用实验告诉您！

前段时间，我们为大家带来了刘定强老师关于云原生数据库的系列文章。从Vertica 的核心架构、分片模式、查询和存储机制、操作行为进行了详细的讲解：

往期回顾

今天，我们带来的是大家最为关心的性能与成本问题。

1

ONE

性能篇

“在大多数查询中，

Eon模式的性能相当甚至优于企业模式”

Eon 模式承诺提供可靠的基线性能，随着节点添加和移除而扩展性能，并展现良好的操作行为。

对于Vertica企业模式用户而言，良好的基线性能意味着即使在共享存储环境中运行，也可以实现与企业模式一样的性能。

我们通过3个小实验来说明这个问题：

实验1

我们分别在企业模式和Eon模式下运行TPC-H查询，结果如图所示：

TPC-H查询持续时间，Eon模式与企业模式对比，

以及Eon模式分别从缓存和S3读取数据的性能差异。

数值越低性能越好

上述实验表明：在大多数查询中，Eon 模式的性能相当甚至优于企业模式。Eon 模式有缓存的性能是合理的，因为在许多部署场景下会把缓存的大小规划为足够放下常用工作数据集。对于无缓存数据，性能会受到明显影响，但响应时间看起来仍然是合理的。

Eon模式的弹性吞吐能力扩展优化，为短查询在群集扩展时提供了额外的吞吐量。下面这个实验说明了该问题：

实验2

以c3.2xlarge实例，以实例存储为缓存。 查询是客户提供的，它是包含多个表关联和聚合的短查询，单独运行通常需要约100毫秒。

将群集从3节点扩展到9节点群集，同时保持分段型分片数为3，测试结果显示吞吐能力接近线性提升。

9个节点的企业模式吞吐能力反而有些下降，因为额外增加的计算资源抵不上协调更多节点所花的开销。

使用吞吐能力弹性扩展的Eon横向扩展。

数值越高性能越好

上图展示了Eon模式在许多并发小型负载上的性能提升。在实验中，每个批量加载或COPY语句加载50MB的数据。 许多表小批量并发加载就属于这种情形; 这也是物联网典型的工作负载。

▼▼▼

实验3

当节点失败时，操作性的关键要素是系统性能。

如下图所示，Eon的分片机制使得在一个节点被杀死时性能不会急剧下降。

这是包含多个聚合和一个分组的查询，通常需要运行6秒。 在4个节点3个分片的Eon模式集群中运行，当一个节点被杀死时性能平滑地衰减。

与前面的实验一样，如果在企业模式下运行杀死一个节点，性能会更明显地下降。

4个节点Eon模式集群杀死1个节点时的吞吐量

上述实验表明：Eon模式下的集群扩展时间是缓存大小的函数，因为大部分时间都花费在移动数据上了。 典型的客户部署，在同时运行着完整工作负载时需要不到30分钟就能完成集群扩展。 如果不填充缓存，这个过程只需要几分钟。 当然，这与企业模式进行比较有点不公平，因为企业模式必须重新分布整个数据集。

2

TWO

成本篇

“采用Eon模式分离计算和存储，

仅计算成本就可节省约66％！”

以一个零售用例来说明。零售商努力应对最繁忙的购物节，这个购物节从周四感恩节开始延续到黑色星期五和周末，并在星期一结束。

零售商必须增加其计算能力才应付这个业务高峰—— 也许还包括周一之后的一个部分高峰，直到新年结束后大约十天后。

让我们分解一下，假设零售商需要：

购物节周末和星期一，20节点

12节点，直到新年过后

一年中的其他时间，6个节点

如下图所示，集群容量按工作负载伸缩，可显著节约成本。 与传统的解决方案按全年最高工作量进行配置相比，采用Eon模式分离计算和存储，仅计算成本就可节省约66％！

▼▼▼