场景需求
暂无。 不过当数据量比较大的时候，备份到同一存储，进行数据分析，使用共享存储就比较方便了
痛点描述
暂无，多副本备份恢复，最后再传送到s3或者oss上，恢复时相当麻烦，使用共享存储或许可以解决
功能需求
支持指定方式存储到共享存储，并且能需要时，从共享存储恢复到副本集
- 场景需求： 暂无；
- 痛点描述： 暂无；
- 功能需求：支持指定共享存储到 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，多副本机制，已经能保证相当高水平的数据安全。
痛点描述
单盘可能存在一定的故障风险，会引发一定的数据库可用性。
功能需求
暂无。
场景需求:
共享存储可以见减少管理成本，备份也简单可以基于存储层来做。
痛点描述：
单个共享存储比如nas或者san一类还是有可能坏，数据全丢。
功能需求：
共享存储支持多个存储设备复制，类似oracle的asm可以在数据库上做磁盘高可用。
多副本可以利用共享存储自己高可用，减少复制消耗。
- 场景需求： 需要通过共享存储解决磁盘容量的问题
- 痛点描述： 可以减少扩缩容以及容量浪费的问题
- 功能需求：支持指定共享存储到nas等。能够很好地平衡性能与成本
1、场景需求：如何确保数据的一致性和低延迟访问？
2、痛点描述：直接连接存储（如NVMe SSD）难以水平扩展
3、功能需求：无缝对接各类共享存储（S3、块存储、NAS），提供灵活的存储选项，支持按需配置TiKV数据副本数量，自动利用共享存储实现跨地域的副本同步。
可以提供类似Oracle is rac的内存融合，多节点读写，操作可以引入的
- 场景需求： 暂无，目前架构满足使用，目前数据量和使用场景基本能够满足；
- 痛点描述：无
- 功能需求：指定 TiKV 数据副本数量其实可以
支持共享存储
毕竟，节点再多，TIKV节点也是NVME盘，而众所周知NVMe盘直通到CPU，无法通过传统的RAID卡进行管理，这也意味着无法使用传统的RAID卡来创建不同的RAID级别，从而在坏盘的情况下没有冗余和容灾。
所以，支持共享存储会给出多一种的解决方案，目前各种存储技术也很成熟， DAS、NAS、SAN、FAS，可以根据情况来选择存储方案，但受限于网络吞吐，IO是否能达到要求还需谨慎考虑
暂时没有这种需求