android平台上持久化存储3种手段_influxdb容器化探索

本文探讨了在Android平台上使用InfluxDB进行持久化存储的问题,通过容器化探索了两种方案:1) 本地存储,使用StatefulSet和PV映射实现数据持久化,性能接近物理机;2) 分布式存储Ceph,虽然性能有所下降,但实现了存储计算分离。在CephFS中进行压测后,发现写入性能损失约一半,并存在多节点写入一致性问题。最后讨论了计算节点调度与故障转移的可能性。
摘要由CSDN通过智能技术生成

b46e30a7a0702c6f8060a07c9af3e2b7.png

前言: 在我司应用服务、中间件、数据库服务等的监控数据存储在时序数据库influxdb中。

目前influxdb实例占用资源情况:

  • 8台物理机 48c96G
  • 存储空间 307G
  • 高峰写入ops 22w/s
  • 内存总占用 139G
  • series 411w

写入量随着业务量的增长持续增长,influxdb的扩展起来比较困难。计划装入容器,并使用分布式存储ceph实现存储计算分离,实现计算层的极致扩展与高可用。

容器化探索第一步——本地存储

influxdb配置文件通过volume 挂载configMap映射到POD容器中的配置文件目录

80d135363cb8ba7c02aca49757d2f0d9.png

influxdb需要持久化数据属于有状态的服务 ,所以pod类型选择了StatefulSet。StatefulSet特点是:拥有稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现。

首先通过在k8s中创建PV映射本地磁盘目录,最终挂载到容器中的influxdb的数据目录,这样不管 Pod 调度到哪个节点,都能挂载同一个卷,从而很容易读取或存储持久化数据。

d0bf7525f0581bb7bf0b085c65adf9c6.png

测试写入10w/s

./influx-stress insert -r 60s --strict --pps 100000 --host http://XXXXXX:XXXXX

Write Throughput: 98524

Points Written: 6010000

测试写入60w/s

[root@db6.dwb.dgt bin]# ./influx-stress insert -r 60s --strict --pps 600000 --host http://XXXXXX:XXXX

Write Throughput: 593223

Points Written: 36200000

测试写入60w/s持续2个小时压测

[root@db6.dwb.dgt bin]# ./influx-stress insert -r 7200s --strict --pps 600000 --host http://XXXXX:XXXX

a920f4857c3a52f24e429c9ea9589678.png

总结:可以看出容器中挂载本地存储后性能几乎无损与物理机相当,不过使用本地存储其实还发挥不出来容器化的优势。数据库做容器化主要还是为了提高资源的利用率,实现弹性调度。那么数据库要实现弹性调度首先要解决数据库存储计算分离,然后让计算层在容器中实现弹性调度,这样才能发挥容器的优势在传统数据库如MySQL innodb中存在很严重的写放大问题,如果在存储层再加入网络IO,那么对于大多数应用场景就不太能接受了。不过对于influxdb这种对底层存储引擎采用类似LSM结构的TSM引擎来说问题就小了很多,写入仅有WAL日志开销,对写入很友好。

可以使用 K8s 结合 分布式存储Ceph 完成真正的存储计算分离。

我们知道k8s中PV的访问模式有3种:

  • ReadWriteOnce - 卷可以由单个节点以读写方式挂载
  • ReadOnlyMany - 卷可以由许多节点以只读方式挂载
  • ReadWriteMany - 卷可以由许多节点以读写方式挂载
  • 要实现我们的目前需要第三种模式ReadWriteMany

k8s中CephFS支持以上3种,而Ceph RDB只支持前两种,不支持ReadWriteMany 。

所以下一步来测试influxdb在分布式存储CephFS中的性能。

容器化探索第二步——分布式存储

这里采用k8s部署rook+ceph存储系统

95daa5fe051b9f6b8dec908e3b94dd39.png
部署ceph创建的pod

启动influxdb pod并通过PV、 PVC挂载cephfs

压测对比

74fba57253c023e27cb04588d38e906a.png
容器挂载分布式存储

5af1e6cc36c00ea2f5a4420e61b5ebb8.png
物理机本地存储压测性能

6ce387f6533493ad5f978ac58777b471.png
容器挂载本地存储

总结:存储计算分离后相较于本地存储写入性能损失接近一半,而且伴有写超时。

容器化探索第三步——计算节点调度与故障转移

存储计算分离后将有状态的数据下沉到存储层,调度pod只要满足计算资源要求的 Node上,这样就做到了计算节点随pod漂移。influxdb实例随pod启动时,只需cephfs挂载 mapping 的 volume 即可。显著提高数据库实例的部署密度和计算资源利用率,还能实现计算节点的故障转移与扩容。

不过这里还会存在以下问题:

1、k8s中PV以ReadWriteMany模式挂载到多个节点,那么在每个节点上看到的数据是不是完全一致?

influx0启动并写入数据

3c14e83623fb5f509f0ee8621119c086.png
influx0数据量

influx1启动并挂载数据

73556c43729a808445db1d2bbda511c9.png
influx1数据量

influx0继续写入数据

410d2bb51462a919ea31f257f38abd7e.png
influx0数据量

b96b4b99c513fb9a446871f90be2bf80.png
influx1数据量

以挂载时间点为界,只能看到挂载前已经存在的数据,看不到挂载后其他节点写入的数据。

2、如果多个节点都写入相同的数据会出现什么情况?

多节点写入相同的数据按写入先后顺序,最终后写入的数据覆盖先写入的数据。(需要避免多写)

参考:

记录一次我做的influxDB性能测试 - 测试开发笔记​www.yinyubo.cn
86d6067708003d2d85ca9138686f53ab.png
面向未来的数据库体系架构思考:把数据库装入容器​www.sohu.com
d161cb5780b09782fed6385c60bfb941.png
Persistent Volumes​kubernetes.io
845f7555ee66c3a2573c01e83a2e37c4.png
https://blog.csdn.net/networken/article/details/85772418​blog.csdn.net Shared File System​rook.io
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值