【TUG 话题探讨001】TiDB 的应用场景有哪些?看看 TUG 的技术专家怎么说

技术话题探讨

8 月 19 日,TUG 群里进行了第一次技术话题探讨会活动,本次探讨会主题为“TiDB 应用场景”,TUG 社群中多位技术专家参与了讨论,以下为讨论分享(为方便大家阅读,顺序有调整):

首先,来自 58 同城的刘春雷分享了 58 对 TiDB 的应用场景

58 同城-刘春雷:

  • MySQL大表:

    • 对于不涉及交易业务的大单表:超过100G的,条数大于1亿的,全部迁移到TiDB。我们使用TiDB的初期,迁移了几十T的数据到TiDB,减轻了MySQL的压力。
  • 监控数据:

    • 监控业务特点是数据正常都比较大,有一定保存时间需求,且流量比较大,连接数可能比较多。
    • 例如DBA的数据库存活监控、性能监控、其他业务的相关监控,我们接入到了TiDB,使用多个TiDB Server支撑流量,多个TiKV保证数据写入速度及数据保留,很好的支撑了业务
  • 数仓:

    • 数仓业务特点是表很多,业务逻辑比较复杂,存在详细数据与分析后的结果数据的需求,一定写入速度的需求,并发查询+分析查询的情况。
    • 例如金融业务数仓,商业某业务的数仓等,使用TiKV+TiFlash,大部分表都加入到TiFlash,升级到最新版本,多TiFlash节点,多个TiKV保证数据写入速度及数据保留,很好的支撑了业务。
  • 报表:

    • 报表业务的特点跟数仓有点像,表多,存在详细数据与分析后的结果数据的需求,一定写入速度的需求,并发查询+分析查询的情况。
    • 例如安居客业务报表、DBA使用的报表、商业报表等等,也是TiKV+TiFlash,5.0版本,按需扩展多个TiFlash
  • 日志、流水:

    • 日志、流水业务的特点:其实就是大单表,有一定的保留日期,写入平稳,分析查询相比不多。
    • 例如安居客相关日志、商业操作日志,操作流水等等,可以建立分区表,方便历史数据清理,只使用TiKV即可
  • 数据归档:

    • 归档业务的特点:定期归档,查询少,但数据重要,不能丢失,接受一定的写入速度慢。
    • 原来归档我们使用TokuDB,但是TokuDB要被官方废弃了,TiDB是个很好的接任者,目前我们部分业务的归档开始使用TiDB了。
    • 例如商业的归档数据等,可以使用普通的大容量的SSD盘,例如多块8T SSD ,提升容量,且配置更高压缩率的压缩参数等
  • 还有个比较好玩的场景:用户画像

    • 有点查和分析查询,每个用户有多个维度的属性,有多字段的需求,TiDB默认限制字段数1024个左右
    • 如果更多,需要修改配置并重启TiDB,算是个需要优化的点.TiKV+TiFlash 可以比较好的支持

京东-田朋:
数据归档 数据汇总

房晓乐-PingCAP:
订单与支付

刚刚结束的 “818 汽车之夜”,TiDB 也发挥了重要作用,大家也都很感兴趣汽车之家是如何使用的:

靳献旗 汽车之家:
论坛业务,车主价格等等等
分库分表,我们论坛回复业务从 SQL Server 1000 张表迁移过来运行两年多了

京东-田朋:
@靳献旗-汽车之家 献旗老师,818 汽车之家的活动,TiDB 应该用了不少场景了吧 ?

靳献旗 汽车之家:
是的,田老师,不少,晚会期间峰值每秒写入应该有几十万

张政俊-中欧基金:
「 靳献旗 汽车之家:是的,田老师,不少,晚会期间峰值每秒写入应该有几十万 」


每秒十几万,下面大概几台 TiDB,几台 TiKV 啊?

靳献旗 汽车之家:
20 个 TiKV 实例,10 台服务器。TiDB 五台,CDC 节点同步每秒峰值 22 万

何傲-神州数码:
「 靳献旗 汽车之家:20 个 TiKV 实例,10 台服务器。TiDB 五台,CDC 节点同步每秒峰值 22 万 」


这个是做的混部吗,怎么分配的呀

靳献旗 汽车之家:
TiDB 和 PD 混合部署了。TiKV 单台服务器部署两个实例。

何傲-神州数码:
是物理机部两个tikv实例吗

靳献旗 汽车之家:
是的

李坤-PingCAP:
「 靳献旗 汽车之家:是的,田老师,不少,晚会期间峰值每秒写入应该有几十万 」


是几十万还是十几万呐,写入呀?献旗老师

靳献旗 汽车之家:
「 李坤-PingCAP:是几十万还是十几万呐,写入呀?献旗老师 」


李老师,不太好统计,正好提一个需求,可以类似查看 innodb 每秒写入的行数。因为业务是批量写,不同表的批还不同,有的 200 行一批,有的 50 行,所以不好统计。

TiDB 的很多老用户都对来自多点的业财一体化场景印象深刻,本次探讨会唐万民也介绍了更多场景:

唐万民-多点:
我补充几个我们的场景:

  • 第一个 TiDB 作为冷库,通过 MySQL 同步至 TiDB,MySQL 存放热数据,通过我们开发的同步工具过滤掉删除操作,保证 TiDB 中为全量数据;
  • 第二个 MySQL 中的分表通过同步至 TiDB 合并为单表,在 TiDB 中进行业务查询,减少分表查询数据复杂度;
  • 其他业务场景和各位老师差不多,就不多描述了。

房晓乐-PingCAP:
「 唐万民-多点: 我补充几个我们的场景 第一个 tidb作为冷库 通过mysql同步至tidb mysql存放热数据 通过我们开发的同步工具过滤掉删除操作 保证tidb中为全量数据 第二个mysql中的分表通过同步至tidb合并为单表 在tidb中进行业务查询 减少分表查询数据复杂度 其他业务场景和各位老师差不多 就不多描述了 」


业务查询,是哪方面? 运营、客服等后台系统?

唐万民-多点:
库存、库凭、物流,还有其他很多场景

房晓乐-PingCAP:
你们的业财一体化啊

深圳昂捷-kongdom:
唐老师的业财一体化

唐万民-多点:
业财一体化也是一个场景,是我们比较重要的一个。让财务数据变为基本准实时,还得靠 TiDB 啊

徐嘉埥-建信金科:
补一个实时交易分析,纯纯的金融场景

深圳昂捷-kongdom:
我们是房老师说的订单与支付,外加用户画像分析,不过还在起步阶段

美团_杜振强:
数据中台场景特别适合

当然,TiDB 并不完美,聊起应用场景,很自然大家也对 TiDB 有更多的期待,我们也进行了收集,大家一起共建,让 TiDB 变得更好!

表妹:
目前应用场景下是否还有新的产品需求,希望 TiDB 团队去实现的吗?

58 同城-刘春雷:

  • 字段数那块给个支持吧,至少4096个字段吧,这样实现用户画像还方便点
  • AP业务增强:
    • Tiflash 独立对外
    • 支持大数据相关接口导入
    • 文档需求:有数据归档,能否给个更高压缩的文档指导,正是替换 tokudb 的好时候,如何提高压缩率

马勇-万博丰:

  • 支持 Hadoop 文件建表
  • PG 这些都可以有插件
  • 支持 Hadoop 文件系统的话

田帅萌-京东数科:
更高压,近期写入的数据,读更快。MySQL 和 tokudb 也是 10 比一吧,压缩比。

All in TiDB?

表妹:
有 all in TiDB 的吗?

Kongdom-深圳昂捷:
某个场景应该是all in 吧

58 同城-刘春雷:
我们是超 100G 大表 all in tidb。。。

联通-张进:
「 58 同城-刘春雷:我们是超100G大表 all in tidb。。。 」


上次压测时我们有张大表快 1t 的数据,表现也不错

58 同城-刘春雷:
嗯,100G 起步,到 TiDB~
太小就放 MySQL

最后,房老师用一张图为本次探讨会做了总结:

房晓乐-PingCAP:

58 同城-刘春雷:
这个图总结的不错

也欢迎你分享 TiDB 应用场景,参与调研即送 100 积分

加入 TUG

如果你也对数据库、大数据感兴趣,想与业界大咖们一起交流最前沿的数据库与大数据知识,欢迎加入 TUG,和 TUG 一起成长!

扫码报名或者点击链接跳转报名

话题征集,参与加分200积分&200经验值

如果你也有话题希望能看到技术专家们的思想碰撞,可以在帖子下面回复你想了解或者感兴趣的话题,被采纳者可以获得200积分&200经验值。

延伸阅读

3赞

像这种单服务器 2个tikv实例应该属于2个不同集群吧

3赞

是同一个集群,为了更好的利用服务器硬件资源,部署了2个tikv实例

3赞

一台宕机了出现多副本失败不就影响系统可用性了,另外磁盘采用什么方式raid,谢谢

1赞

打label了,三副本的话,不会有其中2个同时出现在一台服务器上。磁盘的话,TiKV 的机器使用的是RAID0。

2赞

下面是其中一台服务器tikv的配置,可以参考下
tikv_servers:

  • host: 192.168.1.39
    ssh_port: 30000
    port: 20160
    status_port: 20180
    deploy_dir: /data1/tidb_deploy/tikv-20160
    data_dir: /data1/tidb_data/tikv-20160
    log_dir: /data1/tidb_deploy/tikv-20160/log
    config:
    server.labels:
    dc: dc2
    host: host39
    arch: amd64
    os: linux
  • host: 192.168.1.39
    ssh_port: 30000
    port: 20161
    status_port: 20181
    deploy_dir: /data1/tidb_deploy/tikv-20161
    data_dir: /data1/tidb_data/tikv-20161
    log_dir: /data1/tidb_deploy/tikv-20161/log
    config:
    server.labels:
    dc: dc2
    host: host39
    arch: amd64
    os: linux
2赞

非常感谢

1赞

单机两实例,我目前也这么做,同一个机器上不同的raid挂载不同的tikv 实例。

你们单个实例盘有多大?每个tikv实例region大概多少? 我感觉大于1T-2T的话,单个tikv的region数量就多了,处理起来性能不如1T左右的region数量。

我们线上目前单个实例盘800G左右,做的RAID10,普通SSD
每个tikv实例region数量大概3万左右

官方目前建议是单个tikv实例不超过3万region

2赞