文章目录

  • 引言
    • serverless
    • 实例售卖
    • 结论
  • Azure CosmosDB
    • 预配吞吐量
    • 自动缩放吞吐量
    • Serverless
    • 预留容量
    • 存储量
  • Amazon Timestream
    • 写入计费
    • 查询计费
    • 存储
  • 阿里云TSDB
  • 阿里云Lindom时序引擎
    • 实例固定费用
    • 存储费用
    • 节点费用
  • 华为云GaussDB(for Influx)
  • 腾讯云CTSDB
  • TDengine
  • InfluxDB Cloud
    • AWS
    • Google Cloud
    • Microsoft Azure

引言

使得公有云中架构不得不改变的关键因素有三个,disaggregation,multi-tenancy,serverless。

disaggregation由存储与计算资源需要分别扩容的需求驱动。
multi-tenancy则是源自于为每个租户提供专用硬件根本不符合成本效益,在租户之间共享资源能够使云供应商能够大幅降低提供服务的成本。
而serverless是为了在负载多变的情况下降低成本,租户不再需要提前为高峰期的使用提供资源,由云供应商根据数据库工作负载的需求来获取和释放资源,租户只需为其工作负载实际使用的资源付费。

从多租户的角度讲,安全性/性能与成本其实是互相矛盾的,[7]中提到:

• Degree of consolidation: The higher up in the stack virtualization is supported, the greater the degree of consolidation
achievable, leading to lower cost for the service provider.
• Degree of isolation: The lower down in the stack the virtualization logic is supported, the greater is the security and
performance isolation achievable across tenants.

所以为了成本的卖点,除了KV以外的其他模态时常会放弃提供吞吐量和延时的SLO,而是在实现上保证用户可以使用的资源最低限制,转而提供可用性的的SLO。因为为了保证性能的SLO需要预留资源,不但是POD内部的资源预留(高利用率导致性能下降),也还有POD的级别资源的预留。所以公有云服务提供商往往倾向于SLO要求高的用户独占资源,价格提高,而SLO需求不强的用户则降低价格,出售本来不会被使用到的资源。

从下面列举的各种公有云时序数据库提供方定价来看基本分为三类:

类别 公有云服务提供方
存储量+RU CosmosDB
存储量+扫描数据量+写入数据量 Influxdb Cloud,Amazon Timestream
存储量+实例+其他 腾讯云CTSDB,阿里云Lindom,阿里云TSDB,华为云GaussDB(for Influx)

站在公有云服务提供商的角度:

  1. 存储量+RU:设计原则上看成本最低,因为RU本身代表了CPU/存储IO/网络IO/Memory四个维度的归一化抽象单位,本身可以最真实的反映用户所使用的资源数量。用户体验最好,但是有理解成本。
  2. 存储量+扫描数据量+写入数据量 :更加单一,因为时序场景计算需求也非常强烈,跨越一天的时间查询往往存在千万级别的时间序列,这导致在存储量之前可能有其他资源首先到达瓶颈,这对于提供商来讲意味着亏损,但是因为不提供预配吞吐量和自动缩放吞吐量,看起来就是一个阉割版的serverless。用户体验也不差,且容易理解。
  3. 存储量+实例+其他:对于用户和运营商来说都是成本较高的选择,因为资源本身大概率是闲置的,用户为了流量突发只能购买更大规格的实例,提供商为了保证流量突发也不能过度超卖这部分资源。

serverless

从定价上看前两种就是Serverless的一种体现,但是难点在于多租户的隔离。因为CPU的使用只会转移而不会消失,计算与存储分离可以使得存储层面租户间共享且隔离,但是计算节点此时仍旧独占,这对于公有云提供商来说仍旧是成本,因为我卖的是RU/扫描数据量,但是我还是有单独的机器分配给了某个租户。

如果计算节点共享,此时需要面对的就是CPU隔离的问题,DBaas对于此类问题的讨论已经持续十几年[9][10][11][12],已经拥有了成熟的解决方案,但是均需要从引擎上下手,投入开发的人力成本也不可小觑。

所以以目前的发展现状来看,计算与存储分离,计算层隔离需要引擎的定制化改造,存储层因为吐的是原始数据,基于RU的隔离完全够用,计算层和存储层都做多租户隔离,用户不关心规格,这样Serverless的定价就会非常利好服务提供商和用户。因为对于用户来说,我买了两台机器的RU/写入读取数据量(vcore转RU[13]),可能我的查询实际可能跑在几十台机器上,而且池子够大,业务的高峰流量完全可以hou住;对于提供商来说,因为用户业务属性的不同,我在超卖率极高的情况下仍旧满足用户的需求,且池子随时可以扩缩容。

实例售卖

不利好服务提供商和用户,运营商不敢超卖太多,用户不敢买规格太小。

结论

从上述结论来看,serverless的计费方式显然是大势所趋,但是因为时序场景的特殊,用单纯的扫描数据量无法衡量实际的资源使用情况,数据类型才是影响实际资源消耗的关键,比如iot,监控,trace,会议,直播等场景。维度数,Field稀疏程度,tag大小,短生命周期时间序列等等都对整体资源使用冲击极大,而且冲击是全方位的,存储成本(压缩率),CPU利用率,内存利用率,接入机和存储机器之间的数据传输量都受实际查询类型和数据类型的影响。

所以拥有一个精确衡量资源使用的RU计量方法,且基于此执行serverless收费+存储量是最优的方案。

这个方案有一个问题客观存在,即Dynamodb和CosmosDB对于RU框架有一个重要的约束是:为了方便管理和规划容量,确保针对给定数据集执行的给定数据库操作的 RU 数是确定性的以及用户的可理解性,Dynamodb和CosmosDB均使用扫描的数据量作为RU的计费单位。

时序场景因为查询的特殊性不存在像是KV模态一样稳定的基准线,即扫描的数据量无法代表实际集群的资源消耗(当其他维度先到达瓶颈是就会亏钱),所以不能精确衡量集群资源调度和分配租户,这就是矛盾痛处。

Azure CosmosDB

虽然没有标准的时序模态,但是cosmosdb的计费标准实在是太经典。计费方式分为预配吞吐量,自动缩放吞吐量和Serverless,显然的从RU成本上看,预配吞吐量>自动缩放吞吐量>Serverless。其实从实现的角度讲这么做很好理解,因为云服务是无限扩展的,但是给一个租户总是要预留预期的固定资源,当然这部分资源在实际的存储和计算几点上都是多租户共享的,那自然用户指定上限越高,收费就越贵了。

另外存储量,定期备份(大于两个),流水备份,multi region,专用gateway都是额外收费的选项。通过预留容量,包年的价格还可以优惠14%到44%。

这里很有意思的一点在于这里关于可用性只提到了region级别而没有提及到副本级别,理论上上我们最好给用户足够的自由性,用户不但可以指定副本数,region数,甚至可以指定副本的角色和一致性级别,以达到用户降本的需求。

预配吞吐量

自动缩放吞吐量

Serverless

预留容量

存储量


目前汇率算到话1人民币等于0.14美元,所以这里成本转化人民币分别为¥1.785和¥0.214,可以说是非常实惠了,至于行列导向价钱差别大的的原因也很好理解,列式的压缩比可以做到非常夸张,而行式就没那么容易了,而且还会因为比如集群容量预估不准确导致LSM树形不标准,额外元信息较多等原因造成容量上涨。这里计费采用的是压缩前的容量。

还有这里的容量规划器工具[1]还是很有意思的,以后我们这边也有一个这玩意就好了。

Amazon Timestream

Amazon Timestream按照下面四个维度收费,

  1. 写入次数:从应用程序写入表格的数据量(四舍五入到最接近的 KB)。
  2. 查询次数:Amazon Timestream 的无服务器分布式查询引擎在计算查询结果时扫描的数据量(四舍四入到最近的 MB,最小值为 10MB)。
  3. 内存存储:每个表的内存存储中存储的数据量
  4. 磁性存储:每个表的磁性存储中存储的数据量。

对于这样的定价策略其实可以看出aws还是对自己相当自信。

aws给出了一些优化成本的方法,参考[3]。我觉得其中很多方法我们可以用到,比如:

  1. 用通用属性减少用户的写入量
  2. 给用户一些减少查询使用量的建议,这同时也是保护我们自己,因为公有云中一些架构下多租户隔离还是比较难做的

写入计费

查询计费

存储

阿里云TSDB

TSDB的定价可以参考[5],一看就是典型的上一代云产品,基于Hbase的KV引擎,这种计费模式下其实做多租户很麻烦,因为单个集群盘子太小,超卖的风险太高,无法像云原生数据库那样做到优雅的隔离。

阿里云Lindom时序引擎

Lindom在公有云上的架构构成如下:

  1. Lindom实例固定费用
  2. 存储空间费用
  3. 节点费用(不同规格,不同引擎不同)
  4. 云盘
  5. LTS数据导入服务
  6. 备份
  7. 计算引擎下的弹性计算资源

仅仅看时序引擎,也是传统的按量付费和按照节点规格包月付费。目前Lindom 的架构在官方图中可以看到是LindomStore分布式文件系统之上构建多个协议的引擎,时序引擎则是由TSCore/TSCompute/TSProxy构成,可以想来给用户卖TSProxy,实际数据存储在TSCore,TSCompute做实时数据聚合和降采样(减少TSCore的资源使用)。

但是Lindom基于TSM/TSI的做法也会有不同场景导致性能/资源使用差异极大的情况,这种计费也很难满足一些极端客户的场景,可能会导致为了满足用户的场景,实例需要买非常大,价格收费非常高;而且因为不支持Serverless,虽然时序场景写入稳定,但是用户的查询却是不太稳定的,显然晚上BI分析,视图展示等需求就是会降低很多,这也是一大劣势点。本质其实在于用户可能无法很好的预估自己的使用规格,对用户来说可能造成很大的资源浪费,那用户可能会天天有扩缩容的需求,运营也很麻烦,但倘若支持serverless,不同的用户的就会有更适合的选择余地。


实例固定费用

存储费用

节点费用

华为云GaussDB(for Influx)

华为云的定价可以参考[6],定价策略更加简洁易懂,即就卖节点和存储,这也是存算分离下很经典的计费模式,但是华为的价格真是不便宜啊,比阿里快贵了一倍了。

值得一提的是华为规定了每台实例的可以的时间线上限和没次查询的field和时间线,我的想法就是无法支持基数爆炸的场景,基数爆炸对性能影响太大,只能紧止掉。


这架构图实在是不太走心,画的有点抽象,不过可以看出来和lindom是一个路数。

腾讯云CTSDB

说是内存规格+存储空间,本质还是按照不同的节点规格收费,分为包年包月和按时间消费,不过这个阶梯式收费就很迷。

TDengine

需要联系销售,正在联系中。

InfluxDB Cloud

可以看到在各大公有云上的产品计费策略是使用存储量+实际查询数+查询数据量+写入数据量,不愧是垂直领域龙头,

AWS

Google Cloud

价格和AWS一致

Microsoft Azure

虽然各大公有云厂商没有规定基数限制,但是infludb cloud中是有限制的,但是需要联系销售,正在联系中。

参考:

  1. https://cosmos.azure.com/capacitycalculator/
  2. https://azure.microsoft.com/zh-cn/pricing/details/cosmos-db/
  3. https://docs.aws.amazon.com/timestream/latest/developerguide/metering-and-pricing.html
  4. https://help.aliyun.com/document_detail/387477.html?spm=a2c4g.610211.0.0.2e8a7c30QCWmwn
  5. https://www.alibabacloud.com/zh/product/hitsdb
  6. https://support.huaweicloud.com/influxug-nosql/nosql_05_0045.html
  7. Multi-Tenant Cloud Data Services: State-of-the-Art, Challenges and Opportunities
  8. Tenant Placement in Oversubscribed Database-as-a-Service Clusters
  9. SQLVM: Performance Isolation in Multi-Tenant Relational Database-as-a-Service
  10. Retro: Targeted Resource Management in Multi-tenant Distributed Systems
  11. 2DFQ: Two-Dimensional Fair Queueing for Multi-Tenant Cloud Services
  12. CPU Sharing Techniques for Performance Isolation in Multi-tenant Relational Database-as-a-Service
  13. https://learn.microsoft.com/zh-cn/azure/cosmos-db/convert-vcore-to-request-unit

从一到无穷大 #5 公有云时序数据库定价相关推荐

  1. IBM、Google、Oracle三巨头的公有云之殇(下)

    编者按 \ InfoQ中文站新推出<洞见云计算>专栏,精选包括刘黎明个人公众号上的文章,让更多的读者朋友受益,本栏目的内容都经过原作者授权.本文是<云计算演义>系列文章第四篇. ...

  2. ​IBM、Google、Oracle三巨头的公有云之殇(下)

    InfoQ中文站新推出<洞见云计算>专栏,精选包括刘黎明个人公众号上的文章,让更多的读者朋友受益,本栏目的内容都经过原作者授权.本文是<云计算演义>系列文章第四篇. 企业IT之 ...

  3. 腾讯云数据库公有云市场稳居TOP 2!

    7月4日,国际权威机构IDC发布的<2021年下半年中国关系型数据库软件市场跟踪报告>显示,腾讯云数据库在关系型数据库软件市场(公有云模式)中,位列第二. IDC报告显示,2021下半年中 ...

  4. 云计算演义(3)狂奔在关闭公有云路上的巨头们:IBM、Oracle、Google(下

    版权声明:任何转载需全文转载并保留来源(微信公众号techculture)和该声明,并同时转载文后的二维码,否则视作侵权:如有文字或图片不全,请移步公众号techculture. 企业IT之王IBM, ...

  5. 公有云厂商DDoS防护产品竞品分析——内含CC的一些简单分析,貌似多是基于规则,CC策略细粒度ip/url//ua/refer...

    公有云厂商DDoS防护产品竞品分析 from:http://www.freebuf.com/articles/network/132239.html 行文初衷 由于工作关系,最近接触了很多云上用户,对 ...

  6. 公有云环境下应用程序的自动化部署与水平扩展问题

    先介绍了一下公有云计算环境下的一些特点,再根据这些特点探讨一下作为云计算用户而言,如何对应用程序做好自动化部署和水平扩展(弹性计算)的问题.阅读本文需要有一定的云计算知识.开发运维知识. 公有云环境的 ...

  7. 腾讯云TDSQL-A发布公有云版本 支持第七次全国人口普查等海量数据场景

    5月18日,腾讯云发布首款全自研分布式分析型数据库TDSQL-A,全力应对海量数据实时分析需求. 这是腾讯云数据库在品牌升级后的首次新品发布,意味着腾讯云将这种多年积累的经验更加广泛全面地向社会行业开 ...

  8. Docker在公有云的应用处理能力

    "云"是企业在数字化转型过程中,绕不开的一个主题.即便有些企业表示,近期不会上云,也只是不会将业务部署到公有云上.随着企业旧有软.硬件系统的更替,也势必要从传统数据中心向私有云数据 ...

  9. 漫画:什么是公有云、私有云和混合云?

    在上一篇<什么是云计算>发表之后,很多小伙伴表示终于知道到底什么是云计算了,能够帮到大家真的很开心. 上一篇文章的评论中,有几个朋友希望我们可以介绍下什么是公有云.私有云和混合云.那么这一 ...

最新文章

  1. thymleaf th:text 和 th:utext 之间的区别
  2. hdu2412 Party at Hali-Bula
  3. android 过滤格式,android Intent.setType() 过滤图片,返回所有的文件类型
  4. MATLAB工作环境
  5. 【2019暑假刷题笔记-STL绪论】总结自《算法笔记》
  6. go linux环境搭建,Linux 下 Go 环境搭建以及 Gin 安装
  7. 大数据可视化html模板开源_大数据时代-可视化数据分析平台必不可少
  8. python lxml xpath爬取图片代码
  9. C# winform post请求数据
  10. 利用动态图层实现数据的实时显示
  11. restframework序列化解析详解(番外)
  12. AMiner推荐论文:Strongly coupled N-doped graphene quantum dots/Ni(Fe)OxHy electrocatalysts with accelerat
  13. 家用 NAS 服务器(2)| HyperV的Winserver 2022和Ubuntu 22.04双系统
  14. Hexo博客使用LeanCloud统计页面访问次数
  15. 10万存银行,几年能翻一番?
  16. [微机原理]多点模拟量计算机数据采集实验
  17. 今日金融词汇---新股限购,是什么?
  18. 谓词下推原理和数据框架的应用
  19. 肠-肝轴:宿主-微生物群相互作用影响肝癌发生
  20. Qt实战:Qt5.11.1安装与MSVC配置

热门文章

  1. NOIP2015跳石头【二分答案(最小值最大化) | 贪心】
  2. keil遇到FCARM - Output Name not specified, please check ‘Options for Target - Utilities‘解决方法
  3. ajax异步请求中途取消
  4. 休闲——漫威系列观影顺序
  5. 提示Could not calculate build plan Plugin org.apache.maven.pluginsmaven-resources
  6. 计算机本科毕业要求,计算机本科毕业论文要求.doc
  7. ai电话机器人销售过程自动化功能,黑斑马电话机器人系统
  8. 图片采集-输入关键词批量收集图片免费
  9. 【CO2二氧化碳传感器】senseair S8 LP
  10. html dom 触发等事件