这是一个创建于 32 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在有个 Java 服务每天要抓取十几万的数据，这个数据量太大了，查询速度也慢。现在方案的是，第一次 Mysql 抓取全量数据同步到 CLickhouse 中，clickhouse 存储历史数据，Mysql 就存储当天抓取的数据然后同步到 clickhouse 中。这样就解决了 Mysql 中表的数据量过大的问题。 想问一下大佬们，我这解决方案有啥问题。期间也想过用 monodb 存储，但是 monodb 不是太好用就放弃了
28 条回复 • 2024-11-27 16:24:08 +08:00
 |
1
zsj1029 32 天前
有点感觉没必要，你担心的 mysql 数据量大，应该是表大，每天创建一个新表，可以解决你说的问题
分库分表也是为了解决查询慢，其实索引做好，几百万数据应该也不慢的 |
 |
2
vacuitym 32 天前
那为啥不全存在 ck
|
 |
3
Ico945 32 天前
没啥问题吧，还得有个定时任务来清理 mysql 的数据？
|
 |
8
jfds 32 天前
查询复杂的话这个方案没啥问题。如果查询场景简单，这个数据量只用 mysql 也行，建好索引和分表用个几年问题不大。
|
 |
9
bthulu 32 天前
一天十几万也大吗? 我这厂里设备上报的实时数据, 每秒中几百个设备上报一次, 一天近一千万条数据, 也没见 mysql 不能用啊
|
 |
11
000sitereg 32 天前 via Android
cdc 抓取增量数据到 ck ，历史数据用 java 等方案插入 ck
|
 |
12
wwwyt 32 天前
每天十几万数据也不多，中间加一层 ES 做索引就可以解决查询慢的问题
|
 |
13
venglide 32 天前
建议 mysql 和 ck 都不要用了，直接 starrocks 吧，mysql 协议，实时能力不错，分析效率和 ck 相近，关键是运维比 ck 方便太多。
|
 |
14
li746224 32 天前
问题不大，我们也是这样处理的，每天几十万数据先进 mysql 表，然后 cdc 到 clickhouse 。最后在 clickhouse 做其他汇总处理
|
 |
16
singkingcho 32 天前
如果不怎么更新的话，可以用 doris ，然后做按天的分区。
|
 |
18
Frankcox 32 天前
每天更新的数据是一次新增还是会有大量更新？只是每天新增十几万数据，感觉可以直接都放在 clickhouse 。我们现在部分需要分析的重要日志也是存 clickhouse ，每天几百万，写入没什么问题。
|
 |
19
z1829909 32 天前 via Android
直接每天数据都往 ck 存，查询也是走 ck 。或者只用 mysql ，做好分表就行。
你说的要更新 ck 是指数据爬到新的需要更新吗？可以加个版本号，ck 不擅长做数据更新删除，想更新的时候用不同的版本号新增一次，查询条件带上版本号。不用担心数据量太大，ck 就是干这个的，按时间做个分区几百亿都没事。 |
 |
20
codingmiao 32 天前
话说为什么你们简称 ck 不是 ch
|
 |
21
allstarvrgo 32 天前
[这个数据量太大了，查询速度也慢] 考虑这个问题 ，如果查询条件是某天的数据，可以使用 mysql 的分区表，按天分区。
如果查询条件可能是历史的所有数据，则需要根据查询条件设置好 ck 主键，直接使用 ck 查询。 |
 |
22
sxt10240000 32 天前
@LiJavaT mysql 一亿数据量的普通查询时间在毫秒级，当然你没搞索引当我没说
|
 |
23
maichael 32 天前  5
@codingmiao 关于这个，CH 官方文档甚至有说明： https://clickhouse.com/docs/en/faq/general/dbms-naming
|
 |
24
Meld 32 天前
补上你的查询需求
|
 |
25
8355 32 天前
我们现在单表 117 亿的 clickhouse 做报表统计 没啥问题啊。。。你这点量 mysql 都跑的动吧。
|
 |
26
heiya 31 天前
埋点数据放 ch ，从 ch 中定时统计出来的数据放 mysql 方便查询，美滋滋。
|
 |
27
keshawnvan 31 天前
换个 HTAP 数据库，比如 PolarDB ，TiDB 之类的。
|
 |
28
ACCI 31 天前
这种数据可以用 doris 或者 hudi 之类的数据库吧, 按天动态分区.
也是 mysql 协议, 这种数据量轻轻松松吧. 而且 ck 也是可以分区的吧. ck 的查询强得很 |
Select Language