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

37 天前
 seedhk

数据库版本

阿里云 RDS SQLSERVER

需求

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

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

做了什么

已经做了这几步:

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

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

想做什么:

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

其他方案:

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

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

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

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

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

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

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

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

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

https://tanronggui.xyz/t/1098113

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

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

© 2021 V2EX