需求评估-不同数据量和场景的技术选型

评估一个需求时，一定要搞清楚数据量和业务场景。

不同的数据量，不同的业务场景，使用的技术是不一样的。

数据常用的中间件

• mysql

数据量：百万级别

事务：支持事务

并发：不支持高并发

• mysql分库分表

数据量：千万级别

事务：支持事务。

并发：支持高并发

全文检索：不支持，左模糊不走索引，性能较差。

• es

数据量：亿万级别

全文检索：es尤其擅长。需要搜索时，基本会用es。

事务：es 不支持事务。

并发：es支持高并发。

聚合：多重聚合时，性能较差。7.0 以下版本做多重聚合，非常糟糕。

存储：es不是数据库，不适合存储数据。可以把数据存储在mysql，再同步到 es。

关联查询：es做关联查询时，性能较差，需要做成宽表，从宽表中把多个字段查询出来。

• clickHouse：

特点：列式存储。

数据量：亿万级别

聚合：clickHouse支持多重聚合

并发：不支持高并发

事务：不支持事务

关联查询：不支持Join，需要做成宽表，从宽表中把多个字段查询出来。

更新：不支持数据更新，需要更新数据时，可以 通过插入新数据，根据时间取最新的数据，达到"更新"的目的。

其他：传统的数据库，瓶颈一般是在 IO, 而 clickHouse 非常吃 CPU, CPU是 clickHouse 非常关键的指标。

• doris：

数据量：亿万级别

并发：支持高并发

更新：支持数据更新

关联查询：支持关联查询

技术选型，需要考虑的：

• 数据量

不同数据量，采用的技术不一样。

• 业务场景

不同业务场景，采用的技术也不一样。

• 功能模块：

一般来说，同一个功能模块，尽可能使用同样的技术。
比如订单模块，分为A、B、C多个子模块。如果订单A模块使用es，订单B模块使用clickHouse，后续一旦需要做数据整合，或者关联，就会比较麻烦。

• 伸缩性：

比如，数据量是千万级别，简单一点的逻辑，mysql单表加上索引后，单表还是能用的。

但是如果数据再增长一些，逻辑再复杂一些，单表就扛不住了。

技术选型，必须考虑伸缩性。

• 拓展性：

比如，当前业务仅需要 增删改查，未来的业务发展，有没有可能会需要 高并发、事务、搜索等。

假设业务一直发展，选择的技术，能否适应业务的发展，是否方便拓展？