阿里云分布式数据库大数据量处理

大数据量处理导入数据

如果有UniqueKey并且业务端可以保证数据中没有冲突,可以在Session内打开这个开关:

SET@@session.tidb_skip_constraint_check=1;

另外为了提高写入性能,可以对TiKV的参数进行调优。请特别注意这个参数:

[raftstore]#默认为true,表示强制将数据刷到磁盘上。如果是非金融安全级别的业务场景,建议设置成false,#以便获得更高的性能。sync-log=true写入数据

上面提到了阿里云分布式数据库对单个事务的大小有限制,这层限制是在KV层面,反映在SQL层面的话,简单来说一行数据会映射为一个KVentry,每多一个索引,也会增加一个KVentry,所以这个限制反映在SQL层面是:

  • 单行数据不大于6MB
  • 总的行数(1+索引个数)30w
  • 一次提交的全部数据小于100MB

另外注意,无论是大小限制还是行数限制,还要考虑阿里云分布式数据库做编码以及事务额外Key的开销,在使用的时候,建议每个事务的行数不要超过1w行,否则有可能会超过限制,或者是性能不佳。

建议无论是Insert,Update还是Delete语句,都通过分Batch或者是加Limit的方式限制。

在删除大量数据的时候,建议使用Deletefromtwherexxlimit5000;这样的方案,通过循环来删除,用AffectedRows==0作为循环结束条件,这样避免遇到事务大小的限制。

如果一次删除的数据量非常大,这种循环的方式会越来越慢,因为每次删除都是从前向后遍历,前面的删除之后,短时间内会残留不少删除标记(后续会被gc掉),影响后面的Delete语句。如果有可能,建议把Where条件细化。举个例子,假设要删除2017-05-26当天的所有数据,那么可以这样做:

forifrom0to23:whileaffected_rows0:deletefromtwhereinsert_time=i:00:00andinsert_time(i+1):00:00limit5000;affected_rows=selectaffected_rows()

上面是一段伪代码,意思就是要把大块的数据拆成小块删除,以避免删除过程中前面的Delete语句影响后面的Delete语句。