分析性业务,100 个 SQL 产生 400 个标签,但是其实 100 个 SQL 使用的只有 20 张表,并且 WHERE 后的查询条件大多一致,根据 uid ,并且这 400 个标签在高 QPS 的接口中,所以为了减少 DB 压力,现有执行计划是先执行 20 个表的 SELECT ... WHERE ,并且把数据存储在内存中,在内存中使用 pandas 进行之后的 join 、aggregate 等操作。现在的问题是把 SQL 转 pandas 的操作非常痛苦,并且很容易出错。 所以希望能在内存中通过 SQL 直接做计算逻辑,golang 或者 rust 有没有类似可以在内存中通过原生 SQL 做计算的库?
1
thinkershare 2023-11-20 16:45:33 +08:00
直接上存储过程不行吗?为什么一定要在 go&rust 中做?
|
2
wenhuacode 2023-11-20 16:50:59 +08:00
你的数据是直接抓的生产库?我觉得搭建一个备数据库然后从这个专用的数据库去执行 sql 吧。
|
3
leonshaw 2023-11-20 16:59:47 +08:00
sqlite?
|
4
yellowmarlboro OP @wenhuacode 的确是在备库中查的,但是没有把所有 sql 都直接查 db
|
5
baihekong 2023-11-20 17:04:03 +08:00
加个从库
|
6
sujin190 2023-11-20 17:32:13 +08:00
@yellowmarlboro #4 其实既然都是备库了,sql 库无论 sql 执行效率和内存效率都是最高的了吧,你自己搞个内存计算的既不如数据库高效也不如数据库稳定,性能不够多搞几个备库节点就是了呗,网络消耗的其实无所谓了吧
更进一步其实可以直接在应用节点搞个备库就是了呗,或者用 sqlite 也行呗,没必要非要搞个内存执行 sql 吧 |
7
sujin190 2023-11-20 17:35:59 +08:00
@yellowmarlboro #4 数据库也是可以当作普通软件用的吧,mysql 什么针对特定场景优化配置其实内存消耗可以非常低的,容错了简单,本地库查挂了就再查一次主库就是了,再搞个监控解决了
|
8
yellowmarlboro OP 谢谢大家 我其实也在想这样是不是多此一举,脱裤子放屁又要造轮子的做法,但是要验证的确需要理论支持实验测试才知道。感谢大家的意见
|
9
misoomang 2023-11-21 00:06:45 +08:00
是否可以采用 MySQL 临时表的方案解决该问题
所有的表数据查询后都汇总到临时表中,然后在临时表进行 join 、aggregate 的操作,断开数据库连接后临时表也会自动回收掉 |
10
dayeye2006199 2023-11-21 01:37:20 +08:00 via Android
saline in memory
|
11
dayeye2006199 2023-11-21 01:37:41 +08:00 via Android
Sqlite in memory
|
12
qieqie 2023-11-21 11:11:50 +08:00
存本地数据库,duckdb 比 sqlite 更适合分析型任务。
|