import mode和normal mode的区别

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0.3
  • 【问题描述】:import mode和normal mode具体有什么区别?
  1. import mode除了优化写入和禁止自动压缩以外,还有什么区别?
  2. 文档有提到import mode不适合生产环境,这个的原因是?
  3. 如果在业务低谷时开启import mode导入数据,是否可行?

主要区别就是文档中描述的点

集群性能,高资源都在 lightning 使用,业务可能没有充足的 CPU 和 Memory 以及 I/O 资源可用,导致业务失败。

不建议在线使用,严格按照文档要求使用,如果在线使用,风险和可控性需要自行评估好。

目前可以限制sst文件上传速率,如果可以更精确的控制集群,限制用于import的资源,这样就可以在业务低谷安全地使用import了。我描述下我们公司的使用场景,应该是常见的痛点,希望可以增加import时的精确资源控制。

背景

我们用tidb来存在个性化推荐的画像数据,画像数据需要在每天早高峰之前更新到数据库当中。 画像数据有一些字段(例如:上一次到访距今天数)是全量每天都会变化的,因此每天都要更新全量的数据。读取时一般只只用主键插件,不需要其他索引

方案

参考了滴滴的方案

  1. spark集群计算画像
  2. tidb集群切import模型,限制集群用于import的资源消耗
  3. 画像并发导入新的表
  4. 新表和旧表交换名字

技术指标

  1. 全量画像写入时间<1H
  2. 非导入时QPS>3000,95%耗时 < 10ms
  3. 导入时QPS > 500, 95%耗时 < 50ms

建议从实际业务触发来优化这个业务需求,之前也有类似用户在 Lightning 导入过程中,其他业务也可以正常的运行。只要业务操作的 table 和 Lightning 导入的 table 不是同一个,Lightning 本身是低线程处理 import 任务,本质上不会对集群有影响。但是还是优先结合业务和规模触发。进行实际的测试后才能得到可控计划。

如果对 Lightning 有需求或者合作开发意向,可以通过 GitHub issue 和我们建立联系,研发同学可以直接对接一些技术需求。