Mysql 和 Clickhouse 使用

[LiJavaT]

现在有个 Java 服务每天要抓取十几万的数据，这个数据量太大了，查询速度也慢。现在方案的是，第一次 Mysql 抓取全量数据同步到 CLickhouse 中，clickhouse 存储历史数据，Mysql 就存储当天抓取的数据然后同步到 clickhouse 中。这样就解决了 Mysql 中表的数据量过大的问题。 想问一下大佬们，我这解决方案有啥问题。期间也想过用 monodb 存储，但是 monodb 不是太好用就放弃了

[zsj1029]

有点感觉没必要，你担心的 mysql 数据量大，应该是表大，每天创建一个新表，可以解决你说的问题
分库分表也是为了解决查询慢，其实索引做好，几百万数据应该也不慢的

[vacuitym]

那为啥不全存在 ck

[Ico945]

没啥问题吧，还得有个定时任务来清理 mysql 的数据？

[LiJavaT]

@vacuitym 因为实时更新当天数据，ck 处理更新不太好吧

[LiJavaT]

@Ico945 对对 还得在跑个定时任务清理一下

[vacuitym]

@LiJavaT 看你频率，如果频率不高触发下合并就行

[LiJavaT]

@zsj1029 主要是每天创建一个新表，后面做一下数据分析还有查询比较麻烦

[jfds]

查询复杂的话这个方案没啥问题。如果查询场景简单，这个数据量只用 mysql 也行，建好索引和分表用个几年问题不大。

[bthulu]

一天十几万也大吗? 我这厂里设备上报的实时数据, 每秒中几百个设备上报一次, 一天近一千万条数据, 也没见 mysql 不能用啊

[LiJavaT]

@bthulu 数据不需要经常查询吗，这样查询挺慢的吧

[000sitereg]

cdc 抓取增量数据到 ck ，历史数据用 java 等方案插入 ck

[wwwyt]

每天十几万数据也不多，中间加一层 ES 做索引就可以解决查询慢的问题

[venglide]

建议 mysql 和 ck 都不要用了，直接 starrocks 吧，mysql 协议，实时能力不错，分析效率和 ck 相近，关键是运维比 ck 方便太多。

[li746224]

问题不大，我们也是这样处理的，每天几十万数据先进 mysql 表，然后 cdc 到 clickhouse 。最后在 clickhouse 做其他汇总处理

[realpg]

@zsj1029 #1
索引做好 上亿数据查询也不慢的

[singkingcho]

如果不怎么更新的话，可以用 doris ，然后做按天的分区。

[bthulu]

@LiJavaT 那是, 绝大部分情况下都不会查的

[Frankcox]

每天更新的数据是一次新增还是会有大量更新？只是每天新增十几万数据，感觉可以直接都放在 clickhouse 。我们现在部分需要分析的重要日志也是存 clickhouse ，每天几百万，写入没什么问题。

[z1829909]

直接每天数据都往 ck 存，查询也是走 ck 。或者只用 mysql ，做好分表就行。
你说的要更新 ck 是指数据爬到新的需要更新吗？可以加个版本号，ck 不擅长做数据更新删除，想更新的时候用不同的版本号新增一次，查询条件带上版本号。不用担心数据量太大，ck 就是干这个的，按时间做个分区几百亿都没事。

[codingmiao]

话说为什么你们简称 ck 不是 ch

[allstarvrgo]

[这个数据量太大了，查询速度也慢] 考虑这个问题 ，如果查询条件是某天的数据，可以使用 mysql 的分区表，按天分区。
如果查询条件可能是历史的所有数据，则需要根据查询条件设置好 ck 主键，直接使用 ck 查询。

[sxt10240000]

@LiJavaT mysql 一亿数据量的普通查询时间在毫秒级，当然你没搞索引当我没说

[maichael]

@codingmiao 关于这个，CH 官方文档甚至有说明： https://clickhouse.com/docs/en/faq/general/dbms-naming

[Meld]

补上你的查询需求

[8355]

我们现在单表 117 亿的 clickhouse 做报表统计 没啥问题啊。。。你这点量 mysql 都跑的动吧。