TiDB 喊你来吐槽了!丰厚奖品等你来拿

亲爱的 TiDBer ,

大家好,马上就年末了,很多朋友也都在进行过去 2020 年的一些总结和盘点。过去一年,TiDB 在所有社区小伙伴的支持和帮助下快速发展,成长过程中难免会有一些磕磕绊绊,让大家觉得不舒服、不开心以及需要改进的地方。

因此,我们特地举办此次吐槽活动,不论您是开发者,还是社区用户,大家在了解、学习、使用、贡献 TiDB 过程中有任何需求、建议和问题都可以吐槽给我们。每一位小伙伴的吐槽我们都会认真倾听和思考,积极采纳与改进。 更重要的是,参与的小伙伴还有机会获得我们提供的丰厚的奖品,快快行动吧!

时间 :

2021 年 1 月 27 日 — 2021 年 1 月 29 日

格式:

您可以任选其中的一些项目在本贴内留言吐槽

  • 产品使用过程中遇到的问题及建议:
  • 现有功能建议:
  • 期望产品新增功能:
  • 社区组织的活动体验:
  • 对于目前的社区技术支持服务体验:
  • 对于目前 TiDB 社区项目的吐槽:
  • 对于目前 TiDB 社区运营人员的吐槽:
  • 其他需求和建议:

礼品:

为了感谢大家给予的反馈,本次吐槽活动我们准备了丰厚的礼品

留言点赞数第一名的小伙伴将获得蓝牙音箱一台;

留言点赞数前 5 名的小伙伴将获得 TUG 冬日定制围巾一条;

前 20 位认真吐槽的小伙伴将获得 TUG 周年定制T恤一件;

另外参与本次活动的小伙伴都可以获得 500 积分奖励。


感谢有您,让 TiDB 勇往直前;期待有您,陪伴和见证 TiDB 的每一点进步,欢迎您畅所欲言!

获奖名单公布:

恭喜 TUG微尘 获得蓝牙音箱一台
恭喜 18515065291,bbhy135258,Tjianke,sykp241095,honor100,tsthght 获得周年定制围巾一条

3赞

是否有可以有图形化的安装部署和配置管理及日志搜集呀?谢谢!

我想很清晰的看到每个表所占的存储空间大小。

1、TiDB写入速度不能让人太满意,且调优复杂
2、TiFlash AP性能不能让人满意,且内存无限制
3、dashboard,拉时间范围的组件不好用
4、TiUP的问题居多,例如:
a:tiup执行pd-ctl 命令不能外部调用
b:离线部署多版本,才支持
c:对运维的工作、需求了解不好
d:对于3.x版本升级过来的,还会造成误删除节点
e:总改相关输出项目,导致自动化难度高,改自动化代码频繁(例如获取dashboard地址,新旧版本输出不一样)
5、TiDB对于机器资源要求、使用很高,尤其CPU/磁盘,导致选型困难
6、主键不能操作,最近的问题:自增主键,业务自己指定主键写入,导致写写冲突,主键值变的很大
7、alter 还是只能指定一个操作,不能一个SQL操作加多个索引
8、很多类型不能改,例如varchar只能加长,decimal不能改

14赞

后面稳定版本是否可以推出 日志结构描述的内容呀?谢谢

1 按业务场景,提供现有接入的最佳实践+采坑/避坑指南,用户之间分享经验
2 稳定性加强,确定每个组件异常宕机最大故障时间和故障范围,以及对应故障处理手册
3 TP性能提升,尤其是在混合TP workload 下的性能提升
4 可观测性增强,监控力度更细,能够在dashboard上可以提供按照表维度或者用户维度的监控等

2赞

1、分区表一直不支持 key 分区,也就是不支持 字符串 hash 分区;等待了好久,说是 5.0 会出,结果 5.0 出了,还是没有
2、希望 tikv 也和 tiflash 一样,支持多块盘存储

2赞

为了支持online ddl,引入了一个非常致命的软肋。
tidb几次心跳内无法加载最新的schema就导致tidb服务不可用。
这个事儿有点大。

真正的生产环境,修改表结构是个非常低频的操作,为了支持一个非常低频的操作,引入一个几十秒就要同步一下schema信息,同步不到就拒绝服务的机制,代价有点大。

建议整个选项,或者优化这个机制,如果没有ddl的job,就不需要同步schema了。

1赞

大家肯定会很多不爽的地方,只要实事求是,都可以吐槽。除此之外,我们还有个传统,就是会定期举办《吐槽大会》,本周末 TUG 牵头搞第三期《吐槽大会》,我们会邀请大家当中的代表和 TiDB 产研负责人进行面对面。目前已经有潇姐、春雷、晓磊报名。欢迎更多小伙伴来报名或者给直接给他们几位提供弹药与建议。

3赞

产品使用过程中遇到的问题及建议

问题

1.执行计划突然改变导致业务出问题(频率较高影响较大)
2.Tiflash查询优化,Tiflash查询前需要同步所有数据,保证读取到最新的数据,会影响查询效率
3.tidb insert优化,目前在生产环境遇到过一些瓶颈,希望insert能更快
4. 关于调度,没配置label,我这边扩容之后新节点磁盘降的很慢(调大store limit会加快),老节点磁盘还在快速下降(重点),并且集群稳定后,各节点磁盘使用量并不平衡
5. 集群中有tikv节点磁盘爆掉之后drop partition未执行
6. cdc下游配置mysql/tidb时,配置的用户没检查权限是否满足要求
7. TiUP元数据怎么备份,目前元数据单份,有一定的风险

现有功能建议

1.加强分区表partition的功能

案例:下推至tiflash的执行计划未做分区裁剪

需求

  • 支持更优的分区裁剪功能,加快查询效率
  • 目前mysql规范中,分区键一定要加入到pk/uk中,但是这对业务会有一些侵入性。比如分区键是时间字段,用upsert逻辑更新时间字段会导致多一条数据出来,业务还要先删除原来的数据。需求是upsert也能在原来的数据上直接改。(这个突破了mysql对分区表的定义,或许tiflash/tidb可以支持一种更高级的分区功能)

2.加强算子下推

案例:length、ADDDATE算子未下推至tiflash

需求

  • 案例中的 length, ADDDATE 等算子的下推,特别是和时间处理相关的函数下推,因为分析业务中时间是常用的过滤条件
  • 下推能力至少能和tikv持平,即当前tikv能支持的下推,tiflash都需要支持一下,否则tikv就会比tiflash算得快,tiflash就没有使用的理由
  • 我们某些特殊的业务,里面用到的json类型,相关的json算子也需要支持下推一下,比如json_length, json_extract…,不限于这些。

3.ddl同步至tiflash

案例: enum类型添加枚举值未同步到tiflash

一个是schema层面上忽略了这个enum的变化,第二个是存储层也不支持这个enum的变化

需求

  • DDL要同步到tiflash

4.insert/update/delete/replace select不会走tiflash

案例:replace into select 语句无法走tiflash

需求

  • insert into xxx select from xxx 是很常见的sql业务,这是利用数据库本身的能力做一些简单的类似于物化视图的行为,一个sql同时存在读写,tiflash需要支持这种场景

5.Tiup没对网络打通这一块感觉考虑不足,一般存储服务都在内网,一些功能涉及到内外网或者管理网不通就无法使用了

6.TiUP的设计希望能更贴合一般公司的架构,更方便的接入公司系统。

期望产品新增功能

1.TiDB: 提供智能的表结构优化功能
背景:

  • 一些平台化的服务,在后端建表仅会建字段和属性,并不会考虑加索引、sql优化等事情
  • 业务侧开发人员水平不齐,会造成一些表未加索引或者索引不够优
  1. TiUP搞个Console?

社区组织的活动体验

希望能增加一些偏db开发的分享会

对于目前的社区服务体验

很赞

对于目前 TiDB 社区项目的吐槽

1.建议TUG答疑帖与技术文章分开

对于目前 TiDB 社区运营人员的吐槽

其他需求和建议

1.是否可以考虑对给开源组件首次提pr的同学安排个mentor

15赞

给线上资料的一些建议:有一种感觉,资料十分多,但找不到主线

4赞

期待小表场景的优化。如果Index 和 Data 在不同的 TiKV 上面,就多了一次额外的网络开销

  1. alter 对多个表操作可合并
  2. 增强AP方面的能力
  3. 完善资源隔离性(比如控制SQL占用内存 多少 cpu多少 避免一个SQL 引发集群抖动 )
  4. 添加read_only 范围影响 全局 或者单个tidb server。如果只开单个tidb server read_only 则所有读请求转发到tikv非leard节点,该节点可以给业务做 非实时数据分析,以及elt抽数。
  1. 字段只可以扩容,字段不可以缩容吧

5.安全漏扫 绿盟等软件 扫描tidb时会报成MySQL版本,可以把MySQL版本号调高。或者跟安全厂商沟通,引入tidb漏扫机制。
6.可修改 添加删除自增主键列,使用自增主键也可以使用shard_row_id_bits(主键改为逻辑主键,实际存储还是使用row_id方式 作为物理主键)
7.tidb自带监控项目太多。tidb多套集群监控、报警系统整合一套,避免重复搭建 。

Hi,感谢提出这些中肯的回馈,先回答一下部分与 DDL 限制相关的问题:

  • alter 还是只能指定一个操作,不能一个SQL操作加多个索引
    这一点在 TiDB 中被我们称为 “multi schema change”,目前这部分工作正在进行中(https://github.com/pingcap/tidb/issues/14766),例如 master 分支上,TiDB 已经允许在一条 alter 语句中添加/删除多列。
  • 主键不能操作,最近的问题:自增主键,业务自己指定主键写入,导致写写冲突,主键值变的很大
    这部分工作还没有开展,但是在中长期的 Roadmap 里:https://github.com/pingcap/tidb/issues/18090

总而言之,我们在持续地对 TiDB 的 DDL 能力进行改进,但考虑到元数据操作的重要性和影响,一些已经开发的功能还没有在正式的发布版本中支持,这一点还请理解并期待后续的 TiDB 版本。

慢日志的谜团

希望知道具体 SQL 慢在什么地方…

  • 有些时候看到"整体慢其他地方都很快"…
  • 有的时候看可以看出"某个部分慢"却不知道细分下去什么地方慢(比如 backoff total 慢具体什么 backoff 慢?)
  • Backoff 这个指标非常诡异, cop 部分有个字段, 2pc 部分又有个字段…都自己叫 backoff 如果同时写入+读取(比如 cop + update) 读写都 backoff 日志比较迷惑…希望完善下 Backoff 日志, 能逻辑清晰的知道什么在读写的哪个阶段遇到 Backoff
  • 但目前的"不完善"的慢日志已经被其他用户的日志解析工具使用, 不过如果改格式应该会被其他用户质疑日志格式为什么老变 (逃~

感谢反馈和建议!

对于这一点,我有不同的想法:

tidb几次心跳内无法加载最新的schema就导致tidb服务不可用。

建议整个选项,或者优化这个机制,如果没有ddl的job,就不需要同步schema了。

在这种情况下,我个人会更担心 “这个 TiDB-server 为什么不能加载 schema”,很可能是 TiDB 与 PD/TiKV 之间的通信出现了问题,在这种情况下,即便我们不同步 Schema,TiDB 很可能也无法正常工作。

想象一下,这时候 TiDB 很可能无法确认 “是否真的没有 DDL Job”,相应地,也不敢跳过 “是否需要同步 Schema” 的检查。

1赞

比如说tikv很忙,确实没忙过来,导致tidb加载schema失败。tidb就完全拒绝服务了。这个不科学,一个tikv很忙,其他tikv可以继续提供部分服务,不至于某个tidb上所有请求全部block吧。这是我们集群确实遇到的问题,一个tikv很忙,发生了oom,导致整个tidb服务不可用,这符合tidb的设计理念吗?

至于怎么动态决定是否需要load schema,这个可以再考虑。或者干脆就一个选项,我的集群就关掉了online ddl的支持,我需要的改表结构的时候打开就行了。