【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.4
如题
这题，我表示，木有get 到 你的点 
这两种方式，官方都支持。但是不支持同时存在的
还是分开两个集群来搞吧，万一你用RawKV模式写入的key，把TiDB产生的数据给覆盖了，TiDB集群100%就会有问题了
我的建议还是部署两套集群吧
看样子最好还是不混用。
意思就是在同一套集群上，我即想用tidb，又想用tikv做kv存储
这么做的意义是什么呢，感觉不是很懂
建议还是分两套集群稳妥一点，稳定压倒一切
是什么业务，还是什么需求要这么搞 
你们没有既要用关系型存储，又要用kv存储的场景吗？
例如实时数仓中，要从维度表中取数据，走jdbc就延迟高了。
哦，底层拿数据，连tidb都不过，直接去拿tikv啊
你的具体使用场景是什么？理论上如果部署了完整的tidb，tikv就可以直接使用，为什么还要单独使用tikv服务呢，如果不够直接扩容tikv就行了
kv存储，非关系模型。这样的需求很常见吧
是很常见，我的意思是已经安装好了tikv的情况下为什么还要单独使用tikv，原有集群的tikv服务可以直接使用啊
我记得TiSpark是支持直接从TiKV读数据的，也不需要直接裸KV模式。
TiDB写入的数据，通过tikv-client貌似没办法简单的直接读吧，每个表对应的前缀想获取到，还是需要了解TiDB的编码格式，以及table_id，index_id这些内部值，让数仓团队了解这个，更不友好。
没说要读tidb写入的数据啊。
我是既想用tidb存储关系型数据，还要用tikv做kv存储，类似Redis。既然有现成的tikv，就想着复用它，如此而已。
目前读写tikv都不是问题，就是不知道会不会对tidb的数据产生影响。