充分认识Mysql

时间:2023-03-10 00:12:34
充分认识Mysql

使用开源产品是一种潮流。在使用之前,我们首先需要对Mysql 有一定的了解,特别是Mysql 的缺点。只有了解其缺点后,我们才知道,能不能真正的应用到我们的业务场景中去。

2.1 Mysql 数据库简介

MySQL是一个小型关系型数据库管理系统,开发者为瑞典MySQL AB公司,现在已经被Sun公司收购,支持FreeBSD、Linux、MAC、Windows等多种操作系统,与其他的大型数据库例如Oracle、DB2、SQL Server等相比功能稍弱一些。

1、可以处理拥有上千万条记录的大型数据

2、支持常见的SQL语句规范

3、可移植行高,安装简单小巧

4、良好的运行效率,有丰富信息的网络支持

5、调试、管理,优化简单(相对其他大型数据库)

2.2 Mysql 优点

  • 普及率高

到2017年,Mysql的市场占有率已达44.3%,整个数据库市场,有近一半的企业 选择了Mysql

  • 开源社区活跃

Mysql 初始时是开源产品,因此得到很多人的技术支持,在Mysql开源社区 中有大量人为其提交补丁,因此Mysql成熟的速度会越来越高。

  • 简单

Mysql 是一个小型 关系型 数据库,其本身结构不复杂,维护技能学习成本 低。而且有大量的资料可以学习。

  • 低成本

使用开源产品,可以免去一笔购买产品或者服务的费用 。

  • 多引擎适用不同场景

Mysql目前有20多个存储引擎,常用的有memory,innodb,MyISAM. 不同的存储引擎适用不同的场景。

  • 开源,可定制

开源产品最大的一个优点,就是可定制。在公司技术人员技术支撑 下开发出最符合本身业务特点的功能、或者是某些插件 。

2.3 Mysql问题说明及建议

1. 对原生JSON格式的支持不足

现代数据存储层通常直接以JSON通信。虽然MySQL和Maria DB现在有能力解析SQL中的JSON部分,但这还远远不够,原生的JSON接口已经被广泛使用于CouchDB、MongoDB,或任何最新的工具中。如果对JSON格式数据处理较多,建议暂时先不用Mysql.

2. join关联性能略低

曾几何时,将数据拆分成多个表代表着计算机科学领域的一大卓越进步。这不仅意味着我们能够显著降低表的大小,同时也为用户带来良好的简化效果。但在JOIN语句当中,这种纪律性与收益开始要求我们为之付出代价。

在SQL当中,还没有哪部分组件能像JOIN这样逼迫开发人员建立一系列复杂语句,并承受由此带来的混乱与绝望。在此之后,存储引擎还需要找到最优方式来高效解压这些JOIN语句。总而言之,这相当于开发人员*建立起复杂的查询表述,而数据库则*对其进行梳理。

正因为如此,很多追求速度表现的开发人员干脆放弃了这一进步,转而采用非规范化方式处理。相较于对条目进行拆分,大家直接将数据对象汇总成一个巨大的表,而这就规避了其复杂性。如此一来,运行速度不仅更快,服务器也不至于(频繁)出现内存溢出状况。

如今磁盘存储空间已经相当廉价。市场上已经出现了单磁盘8 TB产品,而容量更大的方案也即将亮相。所以相信在不久的将来,我们将彻底告别该当活剐的JOIN。

3. 多种引擎

到现在为止,Mysql 的可选引擎已经超过20种,这对于数据库运维人员来说是一件非常头疼的事。不同的存储引擎适用于不同的场景。最常用 的是MyISAM 和innodb。使用MyISAM 存储引擎,却又不支持事务,不能保证数据的一致性。使用innodb,在一定程度是,注意,是一定程度上保证了数据的一致性,却损失了速度。

所以使用Mysql数据库需要清晰明确的了解,哪些业务需要强一致性,需要强一致性的,哪些业务需要高速响应,但是数据不需要处理事务。

建议一般使用innodb 存储引擎,而对事务无要求的数据使用MyISAM 存储引擎,对处理速度要求极高,而且数据本身 并不重要的,可以考虑使用memory 存储引擎 。

这三种引擎,innodb支持璁,但是处理数据速度最慢,MyISAM 不支持事务,处理速度中等,Memory 不会持久化数据,存在数据丢失的问题,速度 最快。

4. 中间件

为了提高执行效率,各个技术大牛们又不得不开发中间件,实现分库分表,垂直拆分和水平拆分等技术。到目前为止,中间件产品已超过10个,但是即使,使用最广泛的Mycat 开源产品,仍存在水平拆分进行分组、聚合查询时出现错误结果的尴尬局面。并且Mycat使用是弱事务(弱事务的问题在于 ,多节点提交时,其中一个节点出现问题无法提交时,其他节点无法回滚)。

所以使用中间件,暂时不建议使用分库分表功能,分库不如直接每个库一个实例。避免因数据量激增而带来的实例拆分 的问题。

  • 水平拆分,就是将原本在一张表里的数据,保存在不同节点的同名表里。水平拆分也有优缺点:

优点:

  1. 不存在单库大数据,高并发的性能瓶颈。

  2. 对应用透明,应用端改造较少。

  3. 按照合理拆分规则拆分,join操作基本避免跨库。

  4. 提高了系统的稳定性跟负载能力。

缺点:

  1. 拆分规则难以抽象

  2. 分片事务一致性难以解决。

  3. 数据多次扩展难度跟维护量极大。

  4. 跨库join性能较差。

  5. 垂直拆分(类似于微服务化),类似于微服务化,将一个功能模块存储在一个库里,这样做有优点也有缺点:

优点:

  1. 拆分后业务清晰,拆分规则明确。

  2. 系统之间整合或扩展容易。

  3. 数据维护简单。

缺点:

  1. 部分业务表无法join,只能通过接口方式解决,提高了系统复杂度。

  2. 受每种业务不同的限制存在单库性能瓶颈,不易数据扩展跟性能提高。

  3. 事务处理复杂。

因此建议:不使用中间件,或者仅使用中间件的读写分离功能。

5. 高可用架构对比

我们常说的Mysql 通常指的是单实例的mysql.而不是高可用集群。官方推出的Mysql 集群有Mysql-cluster,Galera. 其他第三方开发的具有高可用功能的软件有MHA,zookeeper+proxy,共享存储等。下面对其优缺点做下对比:

高可用软件 硬件要求 优点 缺点
MHA 至少3节点 MHA可以进行故障的自动检测和转移;可扩展性较好,可以根据需要扩展MySQL的节点数量和结构;相比于双节点的MySQL复制,三节点/多节点的MySQL发生不可用的概率更低。一主多从可以保证 数据一致性。 1. 至少需要三节点,相对于双节点需要更多的资源; 2. 逻辑较为复杂,发生故障后排查问题,定位问题更加困难; 3. 可能因为网络分区发生脑裂现象;
ZOOKEEPER + PROXY 一般要求,至少2节点。 较好的保证了整个系统的高可用,包括proxy 和Mysql; 扩展性好,可以扩展为大规划集群。 数据一致性依赖于原生地同步复制 。加入zookeeper 后,整个系统与其他高可用架构相比,极为复杂。
MYSQL-CLUSTER 官方推荐3节点以上。一个管理节点,两个数据节点。 属于内存数据库范围,支持物理存储,运行高效,真正的双活高可用。不依赖第三方软件;实现数据的强一致性 配置较复杂。使用NDB存储引擎 ,与常用 的innodb,MyISAM memory 存储引擎略有差异,但是差异 不大。
GALERA 至少3节点 多主写入,无延迟复制,能保证数据强一致性。有成熟的社区 ,有互联网公司在大规模使用,经验丰富,架构成熟。自动故障转移,自动添加,删除节点。 需要 为原生 的Mysql 打wsrep补丁,只支持innodb 存储引擎,
共享存储 一般要求,至少2节点 部署简单,切换逻辑简单。很好的保证数据的强一致性。不会因为 Mysql本身逻辑错误引发不一致的情况。 需要考虑共享存储的高可用价格高昂。

综上,我们选择Galera 架构,实现强一一致性,保证 高可用 ,自动添加删除节点,这些是其他方案所无法比拟的。有大规模应用经验,而其他很多架构的应用不够广泛。因此,从其功能性的完善,保证强数据一致性,运行高效方面 三者合一,是其他方案所无所比拟的。