关于数据库,程序员应该了解的那些事

共 2344字,需浏览 5分钟

 ·

2020-10-20 05:34

数据库的选型

对于很多程序员来说,公司选择什么样的数据库,基本不需要你来决定。当你加入一个公司的时候,公司的大部分技术选型已经确认,特别是数据库选型,因为数据库一旦选择,后期迁移的代价还是很大的。

随着大数据时代的来临,涌现出了很多新型数据库,在公司遇到数据性能瓶颈,喊去IOE口号或者是想尝鲜时,都会慢慢的使用新型数据库。但是无论是技术选型还是转型,你都不能忽略一个因素:你选的数据库技术你能驾驭吗?

我们知道,现在有很多开源数据库可以让我们选择,但是我们有相关的技术人员精通这些数据库吗?比如GreenPlum这款数据,有开源版本,也有商业公司在运作,我们看到官方宣传的案例很好,查询效率很高。在一些大数据量查询聚合也比Oracle快一点。但是作为生产数据库使用,随着数据量的增加,你会发现各种你之前没有了解到的问题,对于开发人员来说,比之前的Oracle难用多了。这时候你可能会寻求商业公司的帮助,r派来高级工程师对数据库进行巡检后,提出了很多优化方案、使用规范和管理策略,这些都是你之前不曾了解的。

很多人看到了BAT用的很好,自己就去尝试,并很快用于生产。你可以看看BAT有多少研究员,可能你的公司一个都没有。很多人会问,postgreSQL宣传的很好,我们替换掉MySQL吧。一个公司的数据库如果从来不出现问题,那一定是没有业务量,一旦业务量上来,就会遇到各种问题,这时候什么最重要?救火!所以在数据库出现问题时,公司是否有足够专业的工程师去解决问题是很重要的。所以,对很多想要去O的公司来说,你要想好如何选型新技术。看着开源的免费,贸然使用会付出更多代价。

技术更新很快,还是希望大家在测试开发时候使用新技术,逐步精通的过程中,缓慢过度生产,如果公司有预算,可以请商业公司进行指导半年到一年,自己人学到精髓后再开展独立运维。

数据库如何避坑

再好的数据库,如果使用姿势不对也是枉然,更何况很多程序员并不怎么懂数据库。在数据库使用中,我们常会碰到很多问题。

  • 人为失误

人为失误一般分两类,一种是DBA操作失误,一种是程序员开人员程序里使用不当。DBA一般我们认为是数据库管理的专家了,出错的概率比较小,但是一旦出错,危险是做大的。比如我们经常调侃的“删库跑路”,虽然是依据调侃,但是我是真真的见到过两次,生产环境出现一次,就会在你的工作生涯上记上“光辉”一笔,所以说DBA算是一个高危工作了吧。另一种是开发人员使用不当。常见的比如在使用大表时候,不考虑是否有索引,进行了全表扫描,导致整个数据库被拖垮。

  • 数据库的访问瓶颈

只要是数据库,就会有并发量的限制。以前使用MySQL,我们经常看到互联网公司并发上万的压测。但是对于很多新型的MPP数据库,他们的并发并不是你想的那样,MPP一般由集群CPU物理核数有关。比如以前开发程序查询的MySQL,迁移到GP,那么你的数据库连接池要改一改了。特别是对于一些面向互联网的网站,数据库管理层也要做访问策略,不然,一个外挂可能就会把你的库搞死。

  • 索引

我们都知道索引在传统的关系型数据库中使用的很多,效果也很明显。但是你要知道索引是拿存储换时间的操作。曾遇到过开发人员动不动就让建索引,搞的好像不要钱一样。还有像Vertica(适用OLAP场景)这个数据库就比较友好了,不需要建立索引,只需要在建表时候预排序分布即可提高查询效率,同时列存储的数据还是压缩的,降低了存储,还提高了查询效率。
  • HA(高可用)

数据库作为存储查询引擎的同时,支撑着大型网站的后台服务,一定要考虑高可用。对于一些天然不支持高可用或者高可用不友好的选型一定要小心。再来安利一下Vertica,无Master MPP架构,集群中只要不超过一半机器宕机(物理位置不相邻),集群就处于可用状态。
  • 标准SQL

SQL就是针对数据库查询产生的语言。随着新型数据库的出现,很多数据库不支持标准SQL或者支持很弱。比如HBase。这对于很多以前的开发人员还是有一定学习门槛的,还有就是后期如果出现业务迁移还是很困难的。
Oracle支持标准SQL,但是存储过程并不是每个数据库都有的,这也是阿里为何禁用存储过程的吧,你无法想象一个上万行存储过程的迁移要耗费多少资源。对标准SQL的支持,降低了开发人员的使用门槛,也降低了以后业务迁移的风险。
数据库发展期望
我们会发现传统的MySQL数据库对于并发联机事务处理持很好,但是随着互联网和物联网发展,很多场景下无法单独使用MySQL做支撑,我们通常选引入大数据技术比如HBase辅助,或者搜索引擎。在分析领域我们选择Hadoop和MPP数据库作为支撑,效果也很好,但是越多的技术栈意味着越多的学习成本和风险。
听过PingCAP提出的HTAP架构。数据是系统架构的中心,但过去的系统通常都只能解决一部分场景的问题,在 OLTP,OLAP,数据仓库方面各有侧重,现在终于走向更全能的 HTAP 架构,在一致性、可用性、可扩展性上取得平衡,充分利用云的弹性供给能力和动态调度能力,并且降低运维成本和系统复杂性。
如果出现了一款数据库能够两者兼顾,那必然是美好的。也许还会其他更好的方案,不管怎样,我们会逐步看到更多以数据为中心的架构,更好应对业务和环境的复杂性,响应需求的变化,数据库领域的未来还有许多探索空间~
历史好文推荐
  1. 聊聊数据库

  2. 数据湖vs数据仓库vs数据集市

  3. 浅谈数据中台

  4. 数据中台设计方法论


你点的每个在看,我都认真当成了喜欢
浏览 31
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报