关于数据库容灾缓存方案的咨询

47 天前
 seedhk

数据库版本

阿里云 RDS SQLSERVER

需求

需求是因为老项目的长 SQL 实在是过于多了,几百行的 SQL 一找一个准,去优化 SQL 工作量非常大。

导致生产环境数据库很不稳定,经常因为 SQL 引起数据库不可用导致被客户投诉罚钱,问了阿里云他们推荐高可用集群,但是阿里云高可用对于小企业来说实在是太贵了。迁移下云又需要比较专业的 DBA 来运维数据库,小企业老板估计也不会同意。

做了什么

已经做了这几步:

  1. 使用了 DTS ,同步主库的数据到从库,基本上实现了读写分离;

  2. 拆分了核心业务,但是核心业务仍然有访问数据库的需求,因此万一数据库不可用时,如何保证核心业务的正常运行,成为了一个大问题;

想做什么:

领导提了一个想法:能否通过在中间加一层缓存层的方式,比如 Redis ,核心业务的增删改查先走 Redis 。一段时间后落库,这样即使数据库挂了,只要能撑住 10 分钟数据库就能恢复。

其他方案:

将数据库和接口都进行拆分,拆成多服务,需要对应数据的,走接口进行查询调用

不知道有没有其他更好的方案,求大佬们指教,谢谢~

4994 次点击
所在节点    程序员
103 条回复
seedhk
47 天前
@bitfly #59 哈哈哈 这不就是 ck 嘛,造成一个大宽表
heiya
47 天前
@seedhk
1.数据修改只能是通过待更新标记再重新同步。
2.但假如你使用 OLAP 数据库,比如 ClickHouse ,就像我之前说过的要注意是否有时不时的数据更新操作,如果有则不推荐。因为更新操作会引起索引重建,严重影响性能。非要更新的话也得是批量更新,数据更新及时性会受影响。我们之前的业务比如广告埋点,发送短信等这些数据插入/查询的业务每天几个亿数据,做数据分析连表查询性能很高,美滋滋。
lvlongxiang199
47 天前
@seedhk 可行. 但 ck 没有 join reorder, 写 join sql 的时候得是大表在左, 小表在右, 否则性能比较差. Doris 优化器做的还可以, 也可以考虑 Doris
bg7lgb
47 天前
没专职的 DBA ,难为 OP 了。

从最简单的做起:
1 、升级服务器配置,加内存,提升数据块缓冲区大小;不知 MSSQL 这个怎么做。Oracle 这样做有奇效。硬盘搞 SSD ,阿里云用本地 SSD ,IOPS 提升不小。
2 、分析慢 SQL ,慢 SQL 一般是多表 JOIN ,查询没利用到索引,导致全表扫描。先识别出来,加索引来提升效率,有奇效。
3 、分表,计算结果缓存,读写分离。
优化顺序 :应用 -- 》数据库 --》系统架构

我的认知就这么多了
bg7lgb
47 天前
大 SQL ,见过几千行的 SQL ,真佩服那哥们能写得出来,反正我是不行。

后来重写,几十行搞定,运行效率还高。
mark2025
47 天前
没人没钱就让哥们你来解决? 可以准备跑路了。
rockyliang
47 天前
@seedhk #2 ,有个疑问,按照你们领导“先写 redis ,再落地数据库”的想法,怎么知道 redis 里的哪些数据需要落地数据库?通过读取 AOF 日志文件吗
mark2025
47 天前
@seedhk ck 不用考虑了,应用场景很狭窄,尤其是带条件多字段索引根本没法用。
mark2025
47 天前
@mark2025 是 尤其是带条件多字段”查询“根本没法用
mark2025
47 天前
@rockyliang 这是挖坑的方案
mark2025
47 天前
@seedhk 不建议 ES:
1. ES 需要同步。如果数据源修改增加了字段,ES 还得折腾一番
2. ES 运维成本相当高
mark2025
47 天前
@wxw752 以我公司的场景,分析类查询从 RDS-mysql 迁移到 ADB 的提升也没多少……
seedhk
47 天前
@heiya #62 ,@lvlongxiang199 #63 明白了,谢谢大佬们
@bg7lgb #64 谢谢,数据库这块我也不精通,优化 SQL 什么的没问题,再深入点就两眼一抹黑了,应用和架构层面我能做的都做了,现在就差数据库
@mark2025 #66 是的,Redis 这方案已经否了,最多拿 Redis 做个缓存,ES 做不了太复杂的聚合查询,也不适用
@rockyliang #67 原先项目是指定几个接口或者几张表的数据,都走 Redis

目前来看最适合的还是 OLAP 型数据库
mark2025
47 天前
ES 还得单独学习它的一套查询语法,没意义。
有钱:加配置;用独立主机(包括下云部署到 IDC )
有时间:数据库分表、分库;应用拆分适当微服务化;数据库迁移为 PG
https://pigsty.io/zh/blog/db/7-week-7-db/
v2orz
47 天前
加 redis 不太行,改动大工作量大,见效慢,经典的面试问题:缓存和数据库一致性

把 TOP3 or TOP5 的复杂查询针对性优化一下先缓解,然后通过 DTS 到 ck 或者 doris ,建成一个单独的 OLAP 库感觉比较合适(不太适合高并发场景,看你业务)
dengtongcai
47 天前
短期:先加 RDS 配置,解决紧急投诉问题。
长期:还得慢慢把 SQL 、业务逻辑优化了。
不到万不得已不建议引入新的中间件,引入新的环节也是一种不可控和增加成本。
Meld
47 天前
一堆 Join 还是 doris 吧,CH 需要你对各个引擎以及业务数据库具体设计都要有很深的理解
Meld
47 天前
业务瓶颈在读,肯定要从读这侧下手吧,既然读写分离了,就把读的数据导入到适合业务场景的数据库里呗?
zhoujinjing09
47 天前
据说 doris/starrocks 对 join 支持比较好,建议试一下。这东西都要试了才知道,建议先从简单的开始,AnalyticDB + 弹性扩容,如果不能满足你们需求再看看别的方案。复杂的 SQL 很多时候避免不了全表扫描,唯一解决方案就是用一个弹性的方案
wxw752
47 天前
@mark2025 #72 以我公司那复杂的 sql 体验来看,迁移到 ADB 的提升是巨大的,实测

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/1098113

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX