“我的 TiDB 听我的”活动开启:你的需求,就是我们努力的方向

活动背景

2019 年 6 月 TiDB 3.0 版本正式 GA,性能上相比之前的版本有了很大的提升,这背后离不开 TiDB 活跃的开发者社区的贡献。同时随着产品的不断成熟,TiDB 也被应用到了更多场景,用户群体愈发壮大。用户在使用过程中遇到的问题反馈及实践经验,对于 TiDB 产品的完善及应用推广有着不可忽视的重要作用。

很欣喜 TiDB 在发展过程中能得到社区的大力支持,我们也一直重视社区并不断反哺社区,与社区小伙伴们一起成长。产品是开源社区的基石,好的产品是吸引人才、壮大社区力量的动力;而丰富产品架构、扩充生态周边也需要社区伙伴们的共同努力。

上周的“老房说数”给大家剧透了 TiDB 4.0 的一些新功能和改进,小伙伴们都很期待 TiDB 的提升,同时也留言说出了自己对 TiDB 更多的需求。

为了更好地了解大家对于 TiDB 的需求,TiDB 开发者社区将联合 TUG 举办“我的 TiDB 听我的”活动。活动将收集来自 TiDB 使用者的真实需求,并将呼声最高的功能和改进放到 TiDB 的版本迭代中。有了大家的意见和参与,TiDB 的版本制定和发布将更加透明公开。

活动内容

第一阶段

需求收集(2019.12.17-2020.01.12):TiDB 使用者在该主题下留言你对 TiDB/TiKV 的需求,可以是新功能,也可以是一些小的功能或者易用性改进,比如优化某某 error message 或者 log 内容等,功能越小实现的周期越短,越能在短期内看到改进。在此阶段欢迎正在使用 TiDB 的你畅所欲言。

留言模板如下

  1. 功能/改进说明:SELECT INTO OUTFILE 支持把数据库中数据导出到指定文件内。

    如,执行:

               `SELECT * FROM t INTO OUTFILE '/tmp/table_t'`
    

    后会把表 t 的数据导入到 /tmp/table_t 文件中。

  2. 为什么需要这个功能/改进:能够方便的把线上数据离线导出,对排查问题会有帮助。

  3. 其他数据库对应功能:MySQL 支持这个功能,见:https://dev.mysql.com/doc/refman/8.0/en/select-into.html

第二阶段

需求整理并投票(2020.01.13-2020.02.16):我们会将大家的需求汇总整理,并在 AskTUG 上发起投票。TiDB 的所有使用者都可以参与投票,从投票结果将可以看到大家呼声最高的功能和改进。

第三阶段

需求实现(2020.02.17 以后):投票结束后,我们将把 TiDB 使用者的心声传达给开发者社区,让开发者社区的小伙伴们一起来实现这些需求,需求开发进度也会及时向用户社区同步。

开源精神是 TiDB 不断发展的内驱力,不管是开发者还是使用者,我们希望大家都能更好地交流互动,参与进来一起推动 TiDB 社区的健康发展,一起将 TiDB 打磨得更加完善!

欢迎在此贴留言告诉我们你对 TiDB/TiKV 的需求,留言点赞数前 5 名的小伙伴将获得 TUG 定制精美帽衫:tada:

4赞
  1. 功能/改进说明 :RawKV 支持 prefix extractor
  2. 为什么需要这个功能/改进 :直接使用 RawKV 时,不可避免会有 prefix extractor 这样的需求,例如:基于 Raw KV 实现 MVCC 时,支持 prefix extractor 可以提高性能。
  3. 其他数据库对应功能 :RocksDB
4赞

1: 功能/改进说明 :>TIDB支持存储过程 TIDB支持修改字段类型 TIDB对oracle数据抽取兼容工具或者插件开发

2:为什么需要这个功能/改进 :>对于不少OLAP用户来说,数据分析使用存储过程进行数据分析是习以为常的,tidb不支持,对于依赖存储过程的系统改造很麻烦。 目前看了下文档tidb好像不支持修改字段类型,如int修改到varchar,mysql是可以修改的。 对于不少维护Oracle同学来说,oracle同步到tidb的自带组件还是没有,自己测试过一些同步工具,ogg,datax等工具,目前选用ogg全库同步维护起来比较笨重:sweat_smile:

3:其他数据库对应功能 :Mysql支持存储过程和修改字段类型。期望tidb能够兼容下oracle用户群体,能够开发一些抽取oracle数据的组件,抽取Mysql就很完美,加油!:grinning:

4赞
  1. 功能/改进说明 :优化热点和调度算法
  2. 为什么需要这个功能/改进 :大集群(几十T,百亿级)会出现没有热点,但是访问不均衡的情况,dba没有办法只能扩容机器,浪费资源
  3. 其他数据库对应功能 :无
3赞

1: 功能/改进说明 : 分区表功能完善,支持分区合并、分区分裂等等操作;支持复合分区

2:为什么需要这个功能/改进:生产环境中存在不少定期清理数据的需求,仅仅通过 delete from tablename where … limit … 的方式来清理数据效率低,且rocksdb 的写入本身存在较大的放大,数据只有最终 compaction 之后才能释放磁盘空间,清理数据耗费的时间过长,磁盘IO过大。

3:其他数据库对应功能:可以考虑对齐 Oracle/MySQL 的分区功能

4赞

1: 功能/改进说明 : 提供表/ Region 级别副本设置功能,可以单独为表/ Region 设置副本数。

2: 为什么需要这个功能/改进 :提供 Follower Read 之后,可以为小表/热点 Region 设置更多的副本,通过副本分担读取流量,部分解决读热点。

3: 其他数据库对应功能 :OB 提供了表级别的副本数设置。

7赞

功能/改进说明 : 提供 DB、Table、Index 的访问信息统计数据。

为什么需要这个功能/改进 :可以知道哪些对象被使用的更频繁,或者哪些没有使用,如果没有使用就可以进行下线或者优化,避免资源浪费,也可以避免线上误操作清理使用中的表或者索引,引起事故。

其他数据库对应功能 :Percona MySQL 的 user stat 功能。

3赞

1: 功能/改进说明 : sql plan management 通过SQL的 fingerprint 来绑定执行计划,而不是传入通过SQL绑定执行计划

2: 为什么需要这个功能/改进 :简单易操作,提高易用性;线上SQL可能比较复杂或者比较长,操作起来不方面,同时容易可能因为SQL包含的引号或者其他字符导致绑定失败。

3: 其他数据库对应功能 :类似Oracle,通过给 coe_xfr_sql_profile.sql 脚本传入sql_id, cursor 来绑定执行计划

2赞

功能/改进说明 : 优化器和统计信息收集优化

为什么需要这个功能/改进 :让优化器更智能和准确,避免业务写hint。统计信息收集既能够提供相对准确的数据也能明显降低对线上的影响。

其他数据库对应功能 :oracle和mysql的相关功能都比较智能和准确

1赞

黄土豪,感觉在分布式自动分片的机制下,复合分区价值不大啊。

功能/改进说明 :支持数据库触发器。如,执行:

           `create trigger trigger_addUserTime 
before
 insert 
on user_info 
for each row 
insert into usercreatetime(create_time) values(now());`

新建一个before触发器。

1赞

“我的 TiDB 听我的”活动开启:你的需求,就是我们努力的方向 继续讨论:

@duzq 感谢你的建议! 不过这个需求能请再具体描述一下么,比如 MySQL 或者 Oracle 有什么比较好的关于统计信息的功能或者算法实现之类 :smiley:

  1. 功能/改进说明 : 希望在Mysql的兼容方面在继续加强,主要是DDL相关的

  2. 为什么需要这个功能/改进 :降低用户的使用成本

  3. 其他数据库对应功能 :暂无

1.功能/改进说明:希望未来能支持空间数据类型

如,执行:

SELECT id,name FROM `spatial` WHERE ST_Contains(`area`, ST_GeomFromText('POINT(116.361442 40.038691)'))=1

会查找 spatial 表包含 东升科技园坐标 的 area

2.为什么需要这个功能/改进:降低迁移成本

有地理位置需求的系统从Mysql迁移到TiDB,需要做很多额外工作,这提高了中小型创业公司的迁移门槛.如果未来TiDB支持空间数据类型,相信会有更多处于观望的公司选择TiDB.

3.其他数据库对应功能:https://dev.mysql.com/doc/refman/5.7/en/spatial-types.html

功能/改进说明:提供TIDB物理备份

为什么需要这个功能/改进 :提升DB备份效率,缩短备份时间。

其他数据库对应功能 :Oracle rman和 Percona XtraBackup

2赞

感谢建议,Tools 方面的确还有很多需要改进的地方,我们也会投入更多精力。不过本次活动我们更多的还是关注 TIDB/TiKV 相关的优化和改进~

功能/改进说明 :TiDB是否适合存储几十K的小文件

为什么需要这个功能/改进 :我们的使用场景是冷数据存储备份,备份数据拥有海量的大小为几个字节到几十KB的文件。我们目前使用TiDB来存储管理这些小文件,使用blob来存储文件二进制。当数据库并发达到1.7k时,数据库性能开始出现瓶颈,并且偶尔所有KV的CPU使用率直接攀升到800%-900%,一段时间后开始恢复。面对我们当前的使用场景,能否有优化方式。

其他数据库对应功能 :无

我理解:

  1. Range分区解决最大的痛点是数据按照时间周期进行快速清理
  2. Hash分区解决最大的痛点是热点打散

自动分片的场景下,可能同时存在需要快速清理数据和热点打散的需求,这个时候只依赖自动分片,很难同时解决这两个问题;热点region手工split之后默认一个小时还会自动merge region

1: 功能/改进说明 : TiDB Hackathon 上的获奖项目 跨数据中心流量和延遲減半 能够在4.0 体现出来,实现跨数据中心查询性能大幅度提升

2: 为什么需要这个功能/改进 :业务方同时需要高可用和性能。

3: 其他数据库对应功能 : ob 在跨数据中心部署时,性能表现仍然很不错