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

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

那为啥不全存在 ck

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

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

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

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

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

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

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

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

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

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

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

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

＃1
索引做好 上亿数据查询也不慢的

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

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

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

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

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

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

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

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

补上你的查询需求

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