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

2024 年 12 月 17 日
 seedhk

数据库版本

阿里云 RDS SQLSERVER

需求

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

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

做了什么

已经做了这几步:

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

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

想做什么:

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

其他方案:

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

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

9318 次点击
所在节点    程序员
103 条回复
baibaibaibai
2024 年 12 月 17 日
@seedhk 是的,我们是这样做的
LoNeZ
2024 年 12 月 17 日
要么改代码, 要么加机器...
baibaibaibai
2024 年 12 月 17 日
@seedhk 根据业务复杂查询扩展 es ,单行复杂数据横向扩展进 es ,损耗一点增删改的接口效率,但是基本也忽略不计
adoal
2024 年 12 月 17 日
你那些大 SQL 是什么类型的,事务型还是分析型,如果是前者,没啥好办法,只能硬着头皮一点一点改了。后者的话,可以考虑同步到数仓里做分析,但是结果可能不会跟事务库完全实时一致。
seedhk
2024 年 12 月 17 日
@baibaibaibai #43 那么如果数据发生变动了,也要同步更新 ES 的数据吗,因为是查询后的数据同步到 ES ,更新逻辑也会很麻烦把?
adoal
2024 年 12 月 17 日
至于换数据库,千万不要幻想 PG 比 MSSQL 性能好……至于 MySQL 想都别想了。
adoal
2024 年 12 月 17 日
@heiya 人家用的 MSSQL 你讲 MySQL 满足不了复杂的查询业务……
rockddd
2024 年 12 月 17 日
你这题我会,我们公司用到了大量各类阿里的云服务。

对于你们来说,不要动 SQL ,最好的解决方案确实是读写分离,但读不要再用 RDS 了,用 DTS 将主库的数据同步到 AnalyticDB 中,这个阿里云的数仓和 mysql 的语法完全一样,SQL 查询效率直接拉满,一行代码不改,JDBC 直接连 ADB 读就完事了。
lvlongxiang199
2024 年 12 月 17 日
复杂查询估计是 AP 类型的, 建议上 clickhouse/Doris

救急的话, 与其上 redis 不如考虑拆分实例, 核心服务读/写单独的实例, 通过 DTS 把数据同步到复杂 sql 读的实例, 这样开发的工作量小些
rockddd
2024 年 12 月 17 日
@wxw752 #48 至于 ES ,只有在需要全文检索这种特定场景的表才会存 ES 。

所有数据全部存入 ES ,对于你们现阶段绝对绝对不是一个可选项。
baibaibaibai
2024 年 12 月 17 日
@seedhk 是的,更新逻辑放到原有修改或者走消息都行吧。
mark2025
2024 年 12 月 17 日
自己购买服务器,存储上固态,放 IDC 机房。性能会比云高得多。
seedhk
2024 年 12 月 17 日
@adoal #44 是后者 @lvlongxiang199 #49 。同时请问下二位大佬,clickhouse 我不太熟。翻了下文档好像 ck 对 join 的支持不太好? 那我如果将部分大 SQL 涉及到的表 以关系型数据库的原表数据导入到 ck ,并在 ck 中进行 join 关联查询等是否可行? 谢谢
seedhk
2024 年 12 月 17 日
@wxw752 #48 ,谢谢,我去咨询一下客服

@baibaibaibai #51 ,谢谢。我去看看怎么做
@mark2025 没有专职的 DBA ,这样做风险太大了
heiya
2024 年 12 月 17 日
@adoal 别盯着笔误挑毛病,我写成 abc 他那不还是不行?最烦你这种人,啥方案提供不了就知道挑别人毛病。你觉得你行就给人家一个方案,觉得我说的方案不行就指出哪里不行。逼逼赖赖显你有嘴了。
zhoujinjing09
2024 年 12 月 17 日
DTS 到 OLAP 数据库,ES/Redis 纯属歪门邪道
seedhk
2024 年 12 月 17 日
@zhoujinjing09 #56 谢谢回复,请问 ck 中多表关联查询的性能怎么样,也在考虑将慢查询迁移到 CK
adoal
2024 年 12 月 17 日
@seedhk Clickhouse 之类数仓的玩法是把复杂查询“预处理”生成宽表,这样查起来在宽表上就快了,所以,结果可能不会跟事务库完全实时一致,你要先想明白这是不是你要的目标。
bitfly
2024 年 12 月 17 日
我也遇到過這種問題
用用了一个简单有效的极速无脑一把鑠的办法
就是监控出最吃 CPU 的语句 可能查询超时那种

提前把他查出来存一表里 等用户来查询的时候 直接 select *from 就好了
然后后台在不定期看数据时效性来自动跟新这个表就行了
是不是很无脑
seedhk
2024 年 12 月 17 日
@adoal #58 这样也没 OK ,唯一的问题是如果数据发生变动了,那宽表的数据不是得跟着变

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

https://study.congcong.us/t/1098113

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

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

© 2021 V2EX