我看了文档介绍，tidb负责建表那些，然后数据存储到tikv中，那tidb是不是只是用于存储索引，通过sql查询出数据后，tidb在去tikv批量获取相应的key数据，还是说是其它的方式，目前我是直接使用tikv进行数据的读存，但也用了tidb的事务，有大佬能够解释一下嘛，如果tidb是维护的索引的话，然后将表的数据根据一行一个key的数据转换存到tikv的话，我想使用tidb了，比较可以不用自己一个个遍历tikv获取相应的key数据，业务的用户关系也比较好维护
我理解的是，索引也存储在tikv中。tidb里没有存数据，从部署目录tidb下面只有log文件夹没有data文件夹就可以看出来。
1 个赞
那文档介绍的是，可以通过sql对数据进行操作，然后tidb和tikv进行通信，那这个意思是不是说将tikv的key拼接了表名和表的唯一id了，然后sql检索出相应数据的时候去tikv里面一次性批量获取所有的key，比我自己一个一个key获取数据会快一点，性能高一点，且我的数据可以像mysql那样去定义数据，而不需要自己去维护索引key
你说的这些都是数据库内部逻辑，不需要关心。tidb可以简单理解就是个客户端查询分析器，只是个入口。查数据都是在tikv各个节点查的，查完之后，在tidb里汇总、计算、排序等操作。
那客户端用tikv还是orm的sql对数据操作呢？
三篇经典文章：
(三篇文章了解 TiDB 技术内幕 - 说存储 | PingCAP 平凯星辰)
(三篇文章了解 TiDB 技术内幕 - 说计算 | PingCAP 平凯星辰)
(三篇文章了解 TiDB 技术内幕 - 谈调度 | PingCAP 平凯星辰)
其次，我还有问题，原先的客户端是直接操作tikv进行数据的读取，如果换成tidb写sql的方式，让tidb和tikv自己通信
我自己知道key值，我并没有使用过tidb创建过库和表，纯用的tikv
各位大佬，我就想知道如果我用了tiproxy和tidb的话，是不是所有的请求都是走的tidb那边，其次还可以使用proxy进行负载tidb，客户端业务上只需要写sql，客户端和tikv没有任何关系了，只是tidb的持久化存储，只有tidb和tikv有之间的数据传输关系
兄弟，我建议你先看看我刚才发的那三篇文章。你的key是kv存储的key，并不是tidb要求的key格式。
tikv 就是单纯的 kv 存储，tidb 的话再上面包了一层 sql 的实现。
如果你想用的方便易用角度来看的话，肯定是 sql 比较方便，能支持的接口和功能更丰富。
kv 的好处就是简单，然后裸 kv 的性能也会更好。
tikv是存储数据的。tikv是处理sql连接，相当于前台接待。
嗯，这个我看了，所以我现在想改了，但我就想知道我改了之后不直接kv存储的key话，tikv是不是和我客户端没有关系了，因为原先是直接操作的所以和tikv需要通信连接，现在改成tidb了，是不是只是由tidb和tikv通信了
嗯，因为tidb不能join，再索引方面我觉得会比自己维护的tikv索引性能好点
应该是的，通过tidb方式作为接口后，tikv组件就主要负责kv存储了。其它内部的通信由tidb分布式集群组件(tidb,tikv,pd)自己完成。
嗯，意味着，到时候客户端只会是由pd发现tidb和tiproxy，然后tidb收到请求后，自己和tikv通信，客户端是不需要知道tikv的，也不关心tikv数据的读写是吧
是的，对外只有一个 sql 的接口，可以把 tidb 看成一个整体，内部的组件有 tidb-server、tikv-server 和 pd-server。
注意不要在同一个 tikv-server 的集群里混用 txn kv 和 raw kv，会有一些潜在的问题
TiKV 是一个支持事务的分布式键值数据库，而 TiDB 是基于 TiKV 构建的分布式关系性数据库，SQL 语法高度兼容 MySQL，你看你业务需要什么
很好奇，是什么客户端可以直接读写tikv？