因为考虑到后续查询效率对比的公平性，对于入库到 CK 跟 Doris 的这两张表，我用到了尽可能一致的表引擎、索引字段、和字段类型。

同时，为了检验当前这种维表设计的可行性，咱再把之前同样是用这份数据，基于 Redis 跳表的存储方式，一起做个关联查询对比。

看这份维度数据分别在 CK、Doris、Redis 这 3 个不同的 DB 中，对于上游业务数据(Kafka)的关联效率，各自表现怎么样？

先来个无奖竞猜：你觉得谁的表现会最好，谁最拉？

这份维度数据的查询方式，不能基于普通的 join 关联查询，而只能基于 where 条件的「大于等于起始值，小于等于终止值」的范围查询方式。

而且，考虑到这份维度数据后续还会一直更新，所以综合这两点，它的业务查询方式就只能是「来一条查一条」。

为了比较清晰的测试出这份维度数据，在 3 种不同 DB 的「查询效率表现」，决定设计下面这样一个流式任务。

就像这样：

该任务「一式三份」，分别为：

任务1：Flink 读 Kafka 查询 Doris ，结果写 CK；

任务2：Flink 读 Kafka 查询 CK ，结果写 CK；

任务3：Flink 读 Kafka 查询 Redis ，结果写 CK。

为了比较清晰的看到这 3 个任务测试后的结果对比，需要设计一张字段比较牛逼的结果表才行。

思来想去，我决定把这张结果表放到 CK 身上，并且，表结构长这样：

ip：需要查询的 ipv4 字符串；

ip_and_address: 对 ip 查询到的，地理位置跟运营商信息字符串；

hit_source: 当前的查询方式( Doris、CK、还是 Redis)；

data_time: Flink 拿到 ip 数据时取的当前时间；

insert_time：Flink 查询到地理位置跟运营商数据后，取的当前时间；

time_gap：insert_time 跟 data_time 的时间差，单位为毫秒，即单条数据的查询时间。

毫无疑问，用 jdbc，这个在之前的多个项目案例中，已经验证过很多次了。

目前看来，也只能用基于 MySQL 协议的 jdbc。

基于 Jedis 的实现框架，已经被我封装好。

这 3 种实现都不难，唯一需要注意的，是它们在 Flink 分布式框架的 DB 连接管理问题。

PS：关于这部分的编码，暂时不公开，仅供内部学员使用。

根据以往的经验，不同流量的数据源，流式任务的处理效率，会表现的很不一样。

所以这次测试，咱们会设定多个「不同流量等级」的 Kafka 数据源，挨个来看它们三者之间的效率区别。

Doris 的查询效率随时间差异：

平均时间差为：

CK 的查询效率随时间差异：

平均时间差为：

Redis 的查询效率随时间差异：

平均时间差为：

Doris 的查询效率随时间差异：

平均时间差为：

CK 的查询效率随时间差异：

平均时间差为：

Redis 的查询效率随时间差异：

平均时间差为：

Doris：

平均时间差为：

CK：

平均时间差为：

Redis：

平均时间差为：

Doris 的查询效率随时间差异：

平均时间差：

CK 的查询效率随时间差异：

平均时间差：

Redis 的查询效率随时间差异：

平均时间差：

从这次对上游 Kafka 事实数据，进行 3 个不同 DB 的维度数据关联测试，可以得出如下结论：

1）对于关联效率来说，Redis 的速度最快(都在 1- 2 毫秒左右)，且表现最稳定(时间差波动最小)；

2）CK 的关联效率次之，查询时间基本都在 6-7 毫秒左右，表现没有 Redis 稳定，查询时间差会有一定波动；

3）Doris 的关联效率最差，但也不至于差到想骂人，比 CK 要更逊色一点，查询时间基本维持在 10 毫秒左右，而且波动要比 CK 稍差一点。

而且，还有个值得说的事情——当我把上游 Kafka 流量调得比较大时，经过一晚上的长续航测试后发现，Doris 的那条线半夜就挂了(CK 跟 Redis 的线没事)。

所以由此说明，基于当前场景的维表关联，基于 Redis 的方案最优，CK 次之，Doris 的最不推荐。

对于这次的测试，你觉得符合你的预期吗？