小机器（4C 或 2C）OLAP 数据库需求，技术选型

[annoygaga]

目前的情况：目前每天的数据量其实不大，但是有比较复杂的 SQL 分析需求

预期数据峰值：一天 10000w 条数据（平常一天 1000w ），30 天内的数据分析

需求：希望走一个 OLAP 数据

目前的选择：目前用的 clickhouse （ 2C ，4GB ），但每时每刻都会有不少 mem 和 cpu 消耗

数据场景：偏 web log 相关的分析，没那么多 join 什么的，大宽表

并发：查询有 10 以下并发，且希望查询尽可能快

想问问类似情况下哪些数据库在这个场景比较好呢？

希望

• 维护成本尽可能低
• 消耗成本也尽可能低

[anubu]

可以看看 duckdb ，OLAP 场景的 sqlite

[aispring]

这成本已经很低了吧，再低只能说这么多的数据价值太低了

[annoygaga]

@anubu duckdb 走 embed 的，我希望一个单独进程的，可以分配资源

[annoygaga]

@aispring 其实就是数据价值不算高，或者说需求刚起步，不想花那么大机器

[XyIsMy]

这个配置用那个数据库都够呛。不能升级配置的话，把数据分层吧，定时任务进行统计到统计表上，业务查统计表

[annoygaga]

@XyIsMy 主要是查询也没固定，这个貌似不好搞

[815979670]

你这个配置 只能选型 duckdb 了，看有没有什么开源项目把 duckdb 封装成服务的

[yh7gdiaYW]

这个数据量，这个配置，还要并发，我感觉不太行啊

[XyIsMy]

@annoygaga 查询的最细维度可以确定么。这个能业务方能确认就可以处理

[annoygaga]

@815979670 有这个东西吗？

[annoygaga]

@XyIsMy 估计有点难，毕竟新需求，其实主要就先试一下

[annoygaga]

@yh7gdiaYW 并发也不大，也就 5 这样吧

[ZiTong]

不知这款是否符合你的需求，不过你可以先试试。pg_duckdb: Official Postgres extension for DuckDB

[815979670]

@annoygaga #10 自己封装一下？对外暴露一个 query 接口 要啥数据自己查

[yh7gdiaYW]

@annoygaga 主要是 OLAP 肯定吃 CPU ，你的核心数太少了，还要并发有点难抗

[annoygaga]

@ZiTong 这个原理是？额外搞个 duckdb 的缓存什么的进行分析么？那这样还是需要 pg 来扛？

[annoygaga]

@815979670 这就太花人力了，希望就是类似 clickhouse 这样部署后直接可用

[annoygaga]

@yh7gdiaYW 我数据量倒是不大，并发很低，我指的是会有一些尖刺而已，写到是一直写，读的话每个报表一个请求，才来的并发

[815979670]

@annoygaga #17 其实还好吧，如果只是本地访问的话，不用考虑鉴权什么的，只是相当于中转一下，一个接口就能搞定：获取请求参数（ SQL ），返回数据（ SQL 执行结果），快一点的话 可能十分钟二十分钟就写完了

[annoygaga]

@815979670 是这样的，只是还需要维护额外的代码什么的