不推荐使用 ByteHouse 的场景

在以下场景下，ByteHouse 可能并不适用，建议找寻替代产品：

• OLTP 场景，即必须支持更新（UPDATE）和事务的场景。此场景下，建议使用 MySQL、SQL Server 等传统事务型数据库；
• Key-Value 存储，以及大量使用单行的查询的场景，例如select * from table where user_id in (xxx, xxx, xxx, ...)。此场景下，建议使用 Redis 或其他 KV 数据库；
• Blob 或文档存储。此场景建议使用 Elastic Search。

不推荐使用 ByteHouse 的方式

建表

• 双副本集群，请勿建 MergeTree 引擎表，建议默认创建 HaMergeTree。MergeTree 没有高可用能力，不会用到双副本。建议默认建 ByteHouse 自研的 HaMergeTree 表。
• 建所有本地表时，都建一张 Distributed 表，详情参考：Distributed。不建 Distributed 表的话，无法查询出集群的全量数据。

数据导入

• 避免小批量的数据导入，小批量的数据导入会形成大量小 Part，导致后台 Merge 任务会消耗大量系统资源。涉及到不同导入方式，建议如下：
  • 避免进行单行或几行数据的 Insert into。一般建议插入时同时插 100,000 条，并每次插入一个分区。
  • 如果使用 Flink 对接，flink-connector 的sink.buffer-flush.interval 配置 8000 以上，且配置分区键。
  • 如果使用 Kafka 对接，stream_flush_interval_ms 配置为 8000 以上。

查询

• 避免使用 Select * 进行查询。ByteHouse 为列存数据库，查询所有列的效率远远差于普通行存数据库，查询时指定尽量少的行。
• 避免查询时不加 Limit，或不带分区字段。如果查询时不加此限制，会导致查询要扫描所有行，结果非常慢，阻塞其他查询。