乐趣区

关于mysql:聊聊我是怎么用MySQL的

明天想跟大家聊聊数据库层面上的事

:明天聊的数据库都特指关系型数据库

01、数据库抉择

之前发了一张我可能要在 austin 我的项目上引入哪些技术栈的图,好多人问我分布式配置核心为什么不抉择 Nacos,而是用 Apollo。却没人问我为什么数据库抉择 MySQL。

说起来 MySQL,在网上看到的各类 Java 教程,简直都是应用 MySQL 作为数据库。日常在群里聊各种数据库上的问题,也差不多都是 MySQL,只有个别的可能用 PostgreSQL 和 Oracle 或其余

就连我在面试的时候,我也没被面试官问过:“你的数据库为什么抉择 MySQL 啊?这块技术选型是怎么样的”

看到这里,是不是感觉我有答案了?其实我也没有。写到一半的时候发现我也说不出啥比拟好的理由 … 既然我不晓得,于是我就去看看人家是怎么说的。

总结起因可能是:

  • 后期 MySQL 收费开源易用,从泛滥厂商中硬生生搞出了生态。有了生态,很难就被干掉了。(最次要的
  • 互联网用 MySQL 就是用来存数据“低成本疾速的数据存储插入计划”,要求也绝对没那么高(这条我前面会具体聊聊
  • 很多时候对某技术选型并非是技术起因

而我,我只会 MySQL。我在生产环境下只用过 MySQL,当年我还是小白的时候接触过 Oracle,但当初也根本忘得差不多了。

很多时候对某技术选型并非是技术起因(我是懒狗,我抵赖了)。近几年 PostgreSQL 很火,据说很多中央都比 MySQL 要好,感兴趣的小伙伴能够把 austin 我的项目的 MySQL 替换为 PostgreSQL

对数据库选型感兴趣的大哥们也能够找点材料持续查阅材料,也很欢送在评论区输入下本人的教训,这种话题探讨我感觉还是蛮有意思的。

跟着我一起做 austin 我的项目的小伙伴应该对关系型数据库都有所理解了,这里的根底我就不开展讲述了。对 MySQL 感兴趣或者筹备要面试的同学,能够看看我《对线面试官》系列的 MySQL 章节(在各大博客平台中受到了不错的反馈)

02、ORM 框架抉择

记得几年前我刚接触数据库和 Java 的时候,那时候要用 JDBC 连贯数据库来操作数据,我就很不解:明明我能够通过各种的数据库客户端就能对数据进行操作,为啥我要用 JDBC,好麻烦啊!

至于为什么会有这种疑难,我也不了解我过后是怎么想的(哈哈哈哈)。起初想通了当前,也学习了很多在程序上“简化 JDBC 模板”的姿态(DBUtils/Hibernate/Spring JDBC/Mybatis/SpringData JPA)

我在生产环境中接触过的都是 Mybatis,但这一次我在 asutin 我的项目中决定应用SpringData JPA 作为 ORM 框架。

03、应用数据库的教训

这两年我是呆在互联网公司下班的,我就来聊下我集体所接触到的货色,分享下我的认识。

一般来说,每个业务团队保护着本人的数据库(一个业务团队可能就有好几个库),当咱们须要某一个团队的相干数据时,团队会提供对应的 RPC 接口给公司外部业务应用。

这意味着 数据逻辑对调用业务方而言,是通明的(调用业务方不须要关注其余团队数据库的任何信息,无论是数据库表设计还是具体的字段)。

这个益处是显然地:要某团队的业务数据,只有找到他们提供的接口就完事了。作为需求方,只须要调个接口就能拿到本人想要的数据。

回到数据库外部存储自身,咱们会尽可能将表结构设计得更简略:在很多状况下,都会 放弃数据库三大范式 来设计表。

举个很简略又可能不太失当的场景:一个作者可能会写多篇文章(意味着多篇文章会属于同一个作者)author:content(1:N)

那在初学的时候,可能有的教程会这样设计:author 表content 表autor_content_mapping 表

然而,咱们在理论中生产环境中 很有可能 是不设计这种关联表,而是间接把相干字段 冗余 在一张表里。这样在查问的时候,就能间接通过一张表查到对应的信息了,不必进行 多层关联

如果按下面的构造进行查问:比方我要查到某一篇文章的作者根本信息,那我此时的动作是:

  1. 关联 author_content 表 查到文章的authorId
  2. 通过 authorIdauthor 表 查到作者的根本信息

如果我把 authorId 间接存到 content 表 中,那就意味着少了去 author_content 表查问了。

:这里我不是说让你们把所有的信息都存在一张表里,一张表里有上百个字段,千万不要误会我的意思!

说起关联,又有一个能聊的话题:是否 join(这个话题我已经在我的交换群中聊过,不过也是各抒所见吧)。我在以前公司接触到的我的项目,在mapper.xml 中都看不到 join 的身影,我写 join 只在 hive 写统计脚本的时候用到。

【强制】超过三个表禁止 join。须要 join 的字段,数据类型必须相对统一;多表关联查问时,保障被关联的字段须要有索引。

阐明:即便双表 join 也要留神表索引、SQL 性能。

我总结了一份:mysql 性能优化和高可用架构实战,点此收费下载

喜爱用 join 的会通知你:我写 join 会让代码变得更简略。查数据太麻烦了,要查的数据会存到多张表里,间接在用 join开发效率 是最快的!

而我,我是反对 在代码里写业务逻辑 的。所有都是单表查问,在程序代码中对数据进行关联(数据库的 JOIN 无能到的事,在程序上肯定无能失去)。这样的益处就在于:SQL 简略,SQL 易复用,SQL 易优化

在绝大数状况下,咱们的 接口瓶颈都是来源于「数据库」,而非应用服务器。多 JOIN 且简单的 SQL 是不好优化的,而简略的 SQL 是比拟好优化的,并且我认为 程序逻辑往往都要比 SQL 更容易保护

在我这两年在互联网公司中,关系型数据库在我的认知里,它就是作为一个 反对事务 的存储。如果咱们存储的数据对事务没有要求的,可能压根就不须要存储至关系型数据库中。

当初数据源 可抉择的太多了,咱们能够把数据存储到 Redis(内存数据库)、Elasticsearch(搜索引擎)、HBase(分布式、可伸缩的大数据存储)、HDFS(分布式文件系统)、clickhouse(OLAP 存储系统)等等等

基于下面这些背景下,我的查问 SQL 就不会简单,那么 Spring Data JPA 不就很适宜我了么?

04、开发之外的数据库

去到有肯定规模的公司,都会有数据库相干的根底建设,上面提下常见的根底建设吧

、DDL 和 DML 都须要走工单

生产环境的数据库实践都不能通过本人编写接口在程序中批改(高危动作),须要修数据或者建表都须要通过工单零碎审核(个别是数据库负责人 +DBA)

比方你提交建表申请,DBA 会看你的表设计是否正当(是否有加索引等等)

、DQL 查问线上数据须要权限

咱们要查问线上的数据,个别都得申请库的权限,有了权限之后在公司内网特定的页面进行数据查问(咱们个别只须要查团队内的数据,所以其实也还好,其余团队的数据库权限是不凋谢的,要数据个别只能通过接口获取)

、程序上个别不直连数据库(会有代理层)

个别只有线下数据库能够通过 ip 直连,线上数据库都会通过代理层(代理层能够做很多货色,包含监控鉴权分库分表等等)

、齐备的监控告警

数据库作为一个很重要的存储之一(如果挂了是真的影响很大),会有齐备的监控和告警。比如说执行 SQL 失败的告警、执行慢 SQL 的告警等等,对数据库的各种指标进行实时监控

05、austin 建表 DDL

如果有提前预习的同学,应该就晓得在 austin.sql 下我放了两张表的 DDL。为了让大家了解我在做什么,我来解释下这两张表的 DDL 具体是什么含意(为什么我要建这两张表)

message_template 这张表开始解释吧,所有的字段我都增加了正文,应该还是比拟容易看得懂的。

:如果程序因为扩大导致数据库正文有落后,还是有必要更新下(造福前人)

咱们须要让所有的音讯都有一个「载体」,这个载体说白了就是 模板,模板是 austin 零碎的基石(有了模板,能力做业务解决,能力溯源,能力数据统计,能力扩大出一整套的建设 …)

上面聊下几个可能大家有疑难的几个字段吧:

  • audit_statusflow_id:模板在发送之前须要通过 审核(这在发送音讯里十分重要,这会很大水平上能避免对音讯的误发(置信大家也能看到各大公司都有过发错音讯的报道)
  • msg_type音讯类型:分隔不同的音讯类型,能够在下发时让 不同的类型走不同的通道 进行实现音讯隔离(营销类的音讯即使堵住了,也不会影响到告诉类的音讯)
  • send_account发送账号:一个渠道内可能会有多个账号发送(比方,邮件渠道能够抉择不同的邮件组进行发送、短信渠道能够抉择不同的短信类型账号进行发送)
  • deduplication_timeis_ngiht_shield 平台规定:作为发送类型的组件 (平台),须要有 通用 的规定。而去重和夜间屏蔽下发这种就很适宜在平台内做
  • msg_conteng:这个字段是作为音讯内容发送的 外围 ,不同的渠道对应下发的格局都不一样,我前面会间接将 JSON 存储进去。反对 占位符 的形式进行替换

有可能后续还会扩大字段(毕竟在初期思考设计表的时候,不会尽全尽美)。这种作为模板或者了解为配置的表,从应用上就注定它不会有很大的数据量。

上面来看下 sms_record 表吧,其实这表能说的不多(就是要把短信发送的记录以及短信的回执存储进去)。它的作用一方面是能追踪到为何发送给某个用户的短信失败了,另一方面是将这些记录进行关联做对账应用。

06、总结

这篇文章其实想我聊的是:数据库是一个很重要的角色,如果它挂了会影响很大很大。但同时,咱们很多时候都是“轻量级 ”地去应用它(通过简略的 SQL),它的存在很多时候是因 它能很好地反对事务(数据强一致性)。

咱们最可能信赖的数据就是存储在数据库的,其余的存储咱们可能放心会丢、会多、会不实时等等(这是数据库比其余存储的最大的劣势)

我说得不对肯定,不要以我的为准,咱们能够在评论区聊

退出移动版