Doris在生产环境中的一些最佳实践

大家好，一些经验和教训，总结一下，大家直接领走。

前缀索引

不同于传统的数据库设计，Doris 不支持在任意列上创建索引。Doris 这类 MPP 架构的 OLAP 数据库，通常都是通过提高并发，来处理大量数据的。

本质上，Doris 的数据存储在类似 SSTable（Sorted String Table）的数据结构中。该结构是一种有序的数据结构，可以按照指定的列进行排序存储。在这种数据结构上，以排序列作为条件进行查找，会非常的高效。

在 Aggregate、Uniq 和 Duplicate 三种数据模型中。底层的数据存储，是按照各自建表语句中，AGGREGATE KEY、UNIQ KEY 和 DUPLICATE KEY 中指定的列进行排序存储的。而前缀索引，即在排序的基础上，实现的一种根据给定前缀列，快速查询数据的索引方式。

所以：当where条件中包含Key的前缀列时，能够触发前缀索引，加速过滤。

例如：你的key的顺序是(k1,k2,k3,v1,v2)

那么：

where k1 = and k2,能够命中前缀索引 where k1 = and k3,只有k1能够命中前缀索引 where k3,不能够命中前缀索引

一般来说线上的数据规模较大，尽量采用分区。Doris的数据导入是分区粒度的，一次导入会更新同一分区下所有Tablet，分区能够减少数据导入完成后Compaction的压力。而且而且，分区列一般我们都是用时间列，当where条件包含对时间列的筛选时候，能够触发分区裁剪，这个是非常重要的优化手段。

三个基本结论：分桶数量不宜过多，64个就够了；单个分桶数据量不宜过大，官方推荐1G-10G，但是实际情况有所不同，大家可以测一测，建议1G；单个分桶的数据规模不宜多大，百万级别最佳；

Flink写入Doris有一个场景需要大家特别注意，因为Flink写Doris是批次写入，同一个批次的数据理论上是无法保证顺序的。也就是说如果在极短的时间内更新同一列的某一个字段，在一个批次内提交到Doris，会有乱序风险。

为了解决这个问题，Doris支持了sequence列，通过用户在导入时指定sequence列，相同key列下，REPLACE聚合类型的列将按照sequence列的值进行替换，较大值可以替换较小值，反之则无法替换。该方法将顺序的确定交给了用户，由用户控制替换顺序。

但是，Sequence列只能在Uniq数据模型下使用。