lighting 中 import mode和normal mode的区别

🪐 TiDB 技术问题 备份&数据迁移
1

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

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

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

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

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

3

目前可以限制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
4

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

如果对 Lightning 有需求或者合作开发意向，可以通过 GitHub issue 和我们建立联系，研发同学可以直接对接一些技术需求。
https://github.com/pingcap/tidb-lightning/issues