目前的情况：目前每天的数据量其实不大，但是有比较复杂的 SQL 分析需求
预期数据峰值：一天 10000w 条数据（平常一天 1000w ），30 天内的数据分析
需求：希望走一个 OLAP 数据
目前的选择：目前用的 clickhouse （ 2C ，4GB ），但每时每刻都会有不少 mem 和 cpu 消耗
数据场景：偏 web log 相关的分析，没那么多 join 什么的，大宽表
并发：查询有 10 以下并发，且希望查询尽可能快
想问问类似情况下哪些数据库在这个场景比较好呢？
希望

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

可以看看 duckdb ，OLAP 场景的 sqlite

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

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

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

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

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

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

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

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

有这个东西吗？

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

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

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

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

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

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

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

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

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

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