【产品调研】你希望 TiKV 支持共享存储吗?参与调研可获得 100分,抽3名小伙伴送最新款金属手机支架!

场景需求
暂无。 不过当数据量比较大的时候,备份到同一存储,进行数据分析,使用共享存储就比较方便了

痛点描述
暂无,多副本备份恢复,最后再传送到s3或者oss上,恢复时相当麻烦,使用共享存储或许可以解决

功能需求
支持指定方式存储到共享存储,并且能需要时,从共享存储恢复到副本集

  1. 场景需求: 暂无;
  2. 痛点描述: 暂无;
  3. 功能需求:支持指定共享存储到 S3,可指定 TiKV 数据副本数量,副本同步依赖共享存储实现;

1、场景需求:如何确保数据的一致性和低延迟访问?
2、痛点描述:直接连接存储(如NVMe SSD)难以水平扩展
3、功能需求:无缝对接各类共享存储(S3、块存储、NAS),提供灵活的存储选项,支持按需配置TiKV数据副本数量,自动利用共享存储实现跨地域的副本同步。

场景需求
暂时没有。期待高可用,高一致,同时读写。数据同时多人读写

痛点描述
暂无。单点故障,成本问题。

功能需求
支持指定共享存储到 S3,湖库相连。

场景需求:
1、容灾机房建设。按照监管要求,核心系统应满足容灾4级要求,意味着必须有异地实时容灾库。异地机房与生产机房相隔较远,当前网络延时情况无法形成双活的场景,容灾库仅能承担数据容灾和简单数据查询功能,故容灾库的硬件投资会远小于生产库。如TiKV可使用共享存储,容灾库(TiCDC同步)可创建为单副本TiDB集群,数据存储级容灾完全由存储层实现。
2、业务数据归档库,部分业务数据需保留N年,相关历史数据不再参与业务,仅为备查使用。可接受使用外部表的方式访问nas中的数据。

痛点描述:
1、服务器、机房场地占用大。Nvme单盘容量小,单服务器nvme磁盘数量有限,导致TiDB集群相较于使用集中式存储的数据库,对于服务器和机房场地的消耗增加。
2、当前单副本数据丢失风险。当前搭建的容灾库均为单副本集群,任一nvme磁盘损坏均会导致容灾库数据丢失。

功能需求:
1、支持块设备。
2、放宽TiKV实例支持的存储大小。

1 个赞

场景需求

暂无

痛点描述

在使用直通盘NVMe SSD存储解决方案时,遇到了如下问题:
数据丢失风险:单点故障可能导致数据丢失的风险,尤其是在没有完善的备份机制的情况下。
架构调整难度:如果要改变存储架构,可能涉及到大量的迁移工作,这对现有系统的影响较大。

这些问题对业务造成了影响,期望通过TiKV支持共享存储来解决上述痛点,尤其是提高数据的安全性和降低运维复杂度。

功能需求

期望TiKV支持共享存储提供以下功能:

  • 支持多种共享存储类别:如S3、块存储、NAS等,以便根据具体的业务场景选择最合适的存储方案。
  • 自定义副本数量:用户可以根据自身对数据安全性的要求设置数据副本的数量。
  • 混合存储模式:允许在同一集群内同时使用本地存储和共享存储,从而为不同类型的表或分区选择最优的存储方案。
    透明的数据迁移:在不影响在线业务的前提下,支持数据在不同存储层级间的平滑迁移,且迁移过程中数据分析较明确
    高级监控与告警:提供详细的性能指标监控,并能够在潜在问题发生前发出预警,提前预判风险

还是目前的比较好,共享存储不好用,而且还很贵。

  • 场景需求: 数仓需要支持共享存储,数据分层任务侧读写都多,业务侧读多写少
  • 痛点描述: 主要是数据融合闭环一致性,性能不稳定,运维复杂
  • 功能需求:期望支持s3/oss,共享数据支持多集群,性能尽量媲美ssd

1、数据归档场景,性能和qps要求不高,但存储量极大,
2、没遇到啥问题
3、支持指定共享存储类别、指定 TiKV 数据副本数量

场景需求
有点类似于的湖仓的概念了,将数据卸载到湖中,可以选择性装载,减少存储压力,降低成本

痛点描述
Nvme SSD 的成本较高,如果能有Cache + S3 存储的方式,可以减少一些资源压力

功能需求
不论是 tikv 或者是 tiflash,都可以采用 S3 or 共享存储的方式,尽量减少副本的压力,通过S3 的副本能力或者共享存储的高可用,来减少成本

行和列的混合模式会是呼声较高的需求点了,会有更多的混合应用要求,比如:
执行某个SQL,某一段采用 read follower as tikv 的方式,另外一段采用 tiflash 列式获取数据的方式… 这样子的模式可能比较炸裂,但是性能上会有比较好的表现,能支持手动挡的模式,就能解决一部分场景了

1 个赞

场景需求
暂无。

痛点描述
只读实例单独拉出份存储的话,经常有同步延迟,还会有多分存储空间占用问题。

功能需求
一份存储,多个计算节点,现有的TiDB支持么,如果共享存储,多个集群共用一个存储池的话会节省很多成本,免去数据同步的性能损耗。

场景需求:
历史数据,不参与日常页面查询,但在个别统计节点会用到,但数据量很大,共享存储可以节省成本。
痛点描述:
共享存储损坏RTO会很长,且有数据丢失风险。
功能需求:
支持异步的两种存储

场景需求
暂无。目前的tidb,多副本机制,已经能保证相当高水平的数据安全。

痛点描述
单盘可能存在一定的故障风险,会引发一定的数据库可用性。

功能需求
暂无。

1 个赞

场景需求:
共享存储可以见减少管理成本,备份也简单可以基于存储层来做。
痛点描述:
单个共享存储比如nas或者san一类还是有可能坏,数据全丢。
功能需求:
共享存储支持多个存储设备复制,类似oracle的asm可以在数据库上做磁盘高可用。
多副本可以利用共享存储自己高可用,减少复制消耗。

  1. 场景需求: 需要通过共享存储解决磁盘容量的问题
  2. 痛点描述: 可以减少扩缩容以及容量浪费的问题
  3. 功能需求:支持指定共享存储到nas等。能够很好地平衡性能与成本

1、场景需求:如何确保数据的一致性和低延迟访问?
2、痛点描述:直接连接存储(如NVMe SSD)难以水平扩展
3、功能需求:无缝对接各类共享存储(S3、块存储、NAS),提供灵活的存储选项,支持按需配置TiKV数据副本数量,自动利用共享存储实现跨地域的副本同步。

可以提供类似Oracle is rac的内存融合,多节点读写,操作可以引入的

  1. 场景需求: 暂无,目前架构满足使用,目前数据量和使用场景基本能够满足;
  2. 痛点描述:无
  3. 功能需求:指定 TiKV 数据副本数量其实可以

支持共享存储
毕竟,节点再多,TIKV节点也是NVME盘,而众所周知NVMe盘直通到CPU,无法通过传统的RAID卡进行管理,这也意味着无法使用传统的RAID卡来创建不同的RAID级别,从而在坏盘的情况下没有冗余和容灾。
所以,支持共享存储会给出多一种的解决方案,目前各种存储技术也很成熟, DAS、NAS、SAN、FAS,可以根据情况来选择存储方案,但受限于网络吞吐,IO是否能达到要求还需谨慎考虑

暂时没有这种需求