首页
学习
活动
专区
圈层
工具
发布
30 篇文章
1
迁移到MySQL的业务架构演进实战
2
如何优化MySQL千万级大表,我写了6000字的解读
3
MySQL中的SQL优化建议那么多,该如何有的放矢
4
说几点关于数据库的见解
5
迁移至MySQL的数据流转流程优化
6
引入TiDB方案的一些思考
7
MySQL数据克隆的用户权限设计
8
MySQL逻辑数据恢复体系的设计
9
MySQL随机恢复的设计思路
10
从Oracle到MySQL,金融核心场景在线换库落地实战
11
基于Maxwell的MySQL数据传输服务整体设计
12
MySQL数据库升级的一些坑
13
数据架构选型必读:4月数据库产品技术解析
14
基于数据库中间件配置的几类问题
15
关于中间件服务的配置管理,分为5个阶段
16
MySQL中10多张表关联要做优化,怎么理解逻辑幂等
17
关于MySQL拓扑关系的梳理
18
对于新技术栈落地和架构思维的建议
19
MyCAT让人诟病的配置文件,说说破局的思路
20
MySQL多活数据消费服务设计方案
21
数据双向复制中的6个数据冲突场景和解决思路
22
MySQL双主模式下是如何避免数据回环冲突的
23
一个MySQL服务CPU 100%的优化案例反思
24
MySQL表添加了一个字段,竟然导致数据无法写入,反思
25
MySQL周期表管理太繁琐,通过Python自定义工具方法优雅解决
26
MySQL业务双活的初步设计方案
27
数据库修改密码风险高,如何保证业务持续,这几种密码双活方案可以参考
28
一道经典的MySQL面试题,答案出现三次反转
29
​业务双活的数据切换思路设计(下)
30
基于Consul的MySQL高可用服务,健康检查怎么做?这里有一个完整脚本

引入TiDB方案的一些思考

在MySQL技术体系建设上,能够实现资源水平扩展,满足现在和未来的基础存储需求是一个基本目标,从中长期来说,基于关系型的数据库分布式方案存在明显瓶颈。

1) 分布式事务测试。基于中间件的方案更多是做了事务降维,或者说在分布式事务方面还有待验证,在基于MySQL的分布式事务方向的支持深度和力度方面有限

2) 中间件的分库分表模式存在限制。分库分表的模式在集群管理中复杂度较高,存在难以适配的情况

3)在扩缩容方面,可以实现等量扩展,比如2个扩展为4个,4个扩展为8个,目前无法实现真正意义上的弹性

4)在高可用方面,依赖于分片层的高可用机制,会导致整个服务集群有明显的卡顿,不可用现象

5)对于DDL变更较为敏感的业务,在数据实时性和准确性可以作为一种缓冲方案

6)MySQL侧在部分业务即时查询需求支持方面存在性能瓶颈,目前暂有infobright列式存储方案补充,但是对业务接入存在瓶颈(前端业务无法写入),基于TiFlash的方案可以作为一种较好的弥补策略。

7)4.0版本中已支持悲观锁,在使用模式方便和MySQL侧兼容性更好,后期的预研和迭代会相对快一些。

下一篇
举报
领券