Doris 能胜任业务生产数据库角色吗，是否有事务？

在大部分 TP 场景下，Doris 是满足不了的，因为 TP 主打事务和毫秒插入频次，高频次的 INSERT 操作会导致在存储层产生大量的小文件，会严重影响系统性能。对于一个 AP 库而言，这种操作是非常吃亏的，这里主要是因为 AP 库在本身设计的阶段，就是采用了数据版本做数据可见性控制，一批数据导入以后，可以根据数据批次进行打版本号，在默认的 MOR 的策略下，根据高版本号进行展示。
同时 Doris 的数据导入是事务性的，那么如果是 INSERT INTO VALUES 这样的方式的话，很容易导致数据版本堆积，大量的数据版本会导致后台自动运行的 Compaction 进程压力增大，导致整个集群负载变高，所以从这个角度而言是不能兼任 TP 库的。
但是在一些延迟非敏的场景下，比如前端的数据要求后端处理以后展示的整体时效性在秒级，那么 Doris 是可以胜任的，Doris 可以将数据插入批次最小压缩到 0.5-1s 左右，再利用 Unique 模型的 Replace 算子和 Agg 模型的 Replace_if_not_null 算子进行更新，即可完成 TP 任务。