“我的 TiDB 听我的”第二季来袭——TiDB 5.0 需求全面征集

  • 功能/改进说明 :支持 Lock tables 语句,提供表锁
  • 为什么需要这个功能/改进 :TiDB集群拆分/迁移场景下,需要在源端锁定待迁移表(LOCK TABLES t1 WRITE, t2 WRITE)阻止写入,等数据验证完毕写入流量迁移完毕后,再释放锁
  • 其他数据库对应功能 :MySQL的Lock tables

期待改善的一些点:

  1. 功能:
    • TiUP集成进DashBoard,对用户提供API,方便业务自建平台
    • DashBoard单独部署,不要占用集群性能,不依赖集群(集群挂掉依然可以进行诊断)
    • 完善下游Binlog方案
    • 提供表:数据、索引的占用空间,提高统计信息的准确度
  2. 稳定性提升:
    • region物理隔离:分裂、合并、调度需要扫描keys实现,耗费性能
    • 无差别的MVCC:读写放大、降低性能,GC会带来性能抖动
    • Compaction:性能抖动
    • 热点:降低热点对系统带来的影响(木桶效应,我们当前的木桶短板太低了)
    • 故障隔离:一个组件的宕机,理论上不应该影响整个集群的服务(比如PD切换Leader,会让QPS短暂掉底)
  3. 故障诊断:
    • 日志格式不统一,排查问题困难,希望能规范错误代码
    • SQL执行的全链路追踪
7赞

功能/改进说明:tidb 读写分离,可定具体的tikv节点做读服务,相应tikv节点可异步同步数据,接受可指定延迟。

3赞

1、 功能/改进说明: 更多的参数支持全局在线修改,比如:oom-action、mem-quota-query、slow-threshold 为什么需要这个功能/改进: 为了修改慢查询的阀值还需要重启tidb实例,这个有点。。。 其他数据库对应功能: Mysql可以在线修改慢查询阀值、innodb_buffer等

2、 功能/改进说明: tidb的慢日志支持pt-online-schema-change做分析入库,目前只支持分析,不支持入库 为什么需要这个功能/改进: 目前大家公司都有慢查询分析系统了,并且大部分都是基于pt-online-schema-change做分析入库的,tidb如果不支持还需要为tidb单独写一套分析入库的程序 其他数据库对应功能: 下面是pt_query_digest分析mysql慢日志并入库的功能 pt_query_digest –review h=$monitor_db_host,D=$monitor_db_database,t=mysql_slow_query_review
–history h=$monitor_db_host,D=$monitor_db_database,t=mysql_slow_query_review_history
–no-report --limit=0% --charset=utf8
–since “$last_analysis_time”
–filter="$event->{Bytes} = length($event->{arg}) and $event->{hostname}="$host" and $event->{client}=$event->{User} and $event->{user}=$event->{User} and $event->{db}=$event->{DB}" $slowquery_file

3、 功能/改进说明: drainer to kafka支持多个分区,可以按表的主键分区 为什么需要这个功能/改进: 一个分区的话消费端只能同时有一台服务器消费,一个是单独问题一个是并发问题 其他数据库对应功能: 无

4、 功能/改进说明: Tidb兼容更多的Mysql DDL操作,比如:字符集变更、int变varchar,varchar(100)变varchar(10)、 为什么需要这个功能/改进: 因为我们比较依赖DM做Mysql 到Tidb的同步,这些不兼容的话Task同步经常报错,需要投入很多精力处理 其他数据库对应功能: 无

5、 功能/改进说明: DM支持从monogdb同步数据到Tidb,并且支持全量、增量、全量+增量的方式 为什么需要这个功能/改进: 1、方便从MongoDB迁移到tidb,2、可以很方便的把MongoDB的数据接入tidb,在tidb上做多种数据源的分析 其他数据库对应功能: 阿里云开源的datax有这个功能,但是只支持全量迁移

2赞
  1. 功能/改进说明 :优化小表读取性能,小表指100万记录以下的数据表处理能力。
  2. 为什么需要这个功能/改进 :优化应用架构,其实小表在实际的应用中占比也是挺大的,而当前 TiDB 处理小表读取时间大约在100-400ms 之间,而 MySQ 远远小于100ms。
  3. 其他数据库对应功能 :MySQ 远远小于100ms
1赞

PD加减节点现在是可以不滚动升级集群的

1赞
  • 功能/改进说明 :TiKV支持日志最大保留天数或者日志最大个数
  • 为什么需要这个功能/改进 :不需要定期去清理TiKV的日志
  • 其他数据库对应功能 :大部分数据库都提供

1赞
  1. 功能/改进说明 :优化热表读取性能,提供数据缓存到内存的功能。
  2. 为什么需要这个功能/改进 :部分公共核心表被高频访问,目前是通过缓存到redis实现高性能访问。如果从tidb反复读取,性能差强人意。
  3. 其他数据库对应功能 :MySQ 远远小于100ms,redis访问更快。
1赞
  1. 功能/改进说明 :SQL提交后想取消,退出当前终端,无法准确找到并取消该查询
  2. 为什么需要这个功能/改进 :当DBA误操作使用select * 查询一个TB级别的表,无法正常kill掉而导致tidb-server出现OOM。如果是update或者delete语句还可能会出现数据污染的情况。
  3. 其他数据库对应功能 :MySQ 退出终端则SQL取消,tidb分布式事务可能需要考虑更加复杂的情况。
  1. 功能/改进说明 :建议实现存储过程
  2. 为什么需要这个功能/改进 :报表开发中存储过程的使用还是很方便的,比外部脚本靠谱。而且,实现存储过程的很多要素实际上已经具备了。
  3. 其他数据库对应功能 :MySQL 存储过程
1赞
  1. 功能/改进说明 :DM 部署配置项比较多
  2. 为什么需要这个功能/改进 :部署可以跟集群一起,配置项类似tiup 放在一个文件里
  3. 其他数据库对应功能 :其他数据库木有
1赞
  1. 功能/改进说明 :增加审计/操作日志, 把审计日志写入到TiDB 表或者本地日志. 允许指定各种 filters: 用户名, 命令类型等.
  2. 为什么需要这个功能/改进 :审计需求. 一般的系统都需要收集超级用户操作日志; 金融系统需要更全面的日志.
  3. 其他数据库对应功能 :Percona Server for MySQL 5.5 开始支持 audit log plugin; 5.7 支持audit 过滤.
2赞
  1. 功能/改进说明 :binlog 消费组件可以支持直接打到canal,或者binlog组件的整合
  2. 为什么需要这个功能/改进 :binlog组件下游消费链路过长,配置容易出问题,排查问题不方便
  3. 其他数据库对应功能 :其他数据库木有,mysql的binlog解析工具有很多
  1. 功能/改进说明 :默认配置3个kv副本,1个tiflash副本。
  2. 为什么需要这个功能/改进 :系统运行一段时间,发现AP类查询慢日志较多,自动转换表到tiflash的副本,优化查询
  3. 其他数据库对应功能 :其他数据库木有
2赞
  1. 功能/改进说明 :线上配置建议强制不同组件指定不同路径部署,扩容也必须指定完整

  2. 为什么需要这个功能/改进 :减少混部署资源配置不合理,影响使用和维护

  3. 其他数据库对应功能 :其他数据库木有

  4. 功能/改进说明 :Dashboard 的权限隔离,访问信息快照,审计功能

  5. 为什么需要这个功能/改进 :制定规则,或者是提供接口模版,方便和公司内部的管理系统集成

  6. 其他数据库对应功能 :其他数据库木有

功能/改进说明:AP类SQL执行时间比较长,希望执行过程中有进度输出,当前sql执行过程中相当于卡住,没有任何信息输出

为什么需要这个功能/改进:AP类SQL经常跑分钟级,需要通过输出判断执行情况,使用更友好

其他数据库对应功能:hive、presto、sparksql等

  1. 功能/改进说明 :实现存储过程和触发器
  2. 为什么需要这个功能/改进 :公司里这两个东西用的比较多
  3. 其他数据库对应功能 :oracle,mysql 储过程和触发器
  1. 功能/改进说明 :支持批量添加列,添加索引,有损变更等DDL操作
  2. 为什么需要这个功能/改进 :尝试上一些tp业务,开发反馈表结构变更太不方便,列(索引)只能一个一个加,不能一条DDL语句执行。还有如果将varchar(100)改为varchar(50)也不支持,或者是int类型改为varchar,这些有损变更希望能支持。因为业务逻辑可能存在多变,表结构经常会跟着改
  3. 其他数据库对应功能 :mysql这些是常规操作
1赞
  1. 功能/改进说明 :多副本宕机时,支持一键恢复集群,可以先记录可能丢失数据的region信息,后续可以通过先前的备份找回数据
  2. 为什么需要这个功能/改进 :当前如果有多副本宕机时,某些失去多数派peer的Region会不可用,手动恢复比较机械,而且时间较长。在用户接受可能数据丢失风险的情况下,可以一键恢复集群,避免某些Region长时间不可访问
  3. 其他数据库对应功能 :不清楚

+1 支持