POSTGRESQL 学习有感,向左灵活多变,向右容器化

2021-01-09 00:00:00 数据 数据库 模式 默认 概念



近学习POSTGRESQL 看完某本书,突然有所顿悟,数据库到底应该是功能多,能减低开发的难度,还是功能缺乏,通过第三方的元素来给自己加持。


之前我是MYSQL 狂热的拥护者,分库分表, 中间件,各种开源组件,数据融合的手段,怎么针对24小时的系统,大表安全添加索引 字段,觉得很高大上,SQL SERVER 和 ORACLE 都是渣渣辉。


这就样引入了一个问题数据库到底是容器化好,还是功能特多,满足各种应用和开发的需求好。可能会有人问,你说POSTGRESQL 这个好那个好,到底有多少公司在用,为什么MYSQL 还是那么多公司在用。


我其实想问一个问题,糖很好吃,人人都爱吃甜的(至少说爱吃苦的,会被视为不正常),那糖就一定是好的?


或许三个字,习惯了,随大流,能解释,为什么很多传统公司,在去O的道路上,并不太愉快,或许即使因为这三个字,而忽略了自己真实的需求。人家行,未必你行,原因也很简单,因为技术投入比,人家花5万请一个的DB 架构,你花8000请一个MYSQL 的DBA ,那能一样吗? 


话题扯远了,回到近的学习


这里引入一段书中的文字


模式:schema


模式是数据库领域的一个基本概念,有些数据库把模式和用户合二为一,POSTGRESQL 不同,POSTGRESQL 是具有清晰的模式定义。模式可以理解为一个命名的空间或目录,不同的模式下可以有相同的名称的表,函数等对象而不产生冲突,提供模式这个概念是为了便于管理。


MYSQL 数据库没有schema

ORACLE 有schema 

SQL SERVER 有schema

POSTGRESQL 有schema


即使是有,PG 的schema 是建立在数据库概念上的, 画一个图来总结一下这些数据库的schema  (SQL SERVER 类似 PG,就不在画图了)


从管理的角度来说, PG 的对于database 的概念和 schema 的概念是融合了ORACLE 和 MYSQL 两种数据库的概念。


那么如果一个MYSQL 的INSTANCE 下有多个MYSQL 的DATABASE 到PG 应该使用PG 的schema 的概念, 建立一个数据库,然后通过schema 的概念来管理表。这样避免PG 中多个数据库不能直接访问的问题。


那么说到另外一个问题,schema 哪个是默认的schema PG 默认的schema是public ,哪个用户都有权利在public建立任何的OBJECT, 这点类似SQL SERVER DBO的 schema。但后面对于模式的搜索路径的解决方法里面,PG 是可以设置相关的相关数据库哪个schema 是默认被应用的,也就是你输入表名,默认去搜寻哪个schema。这点SQL SERVER 是没有相关的选择性的。


另外对于一些表关于性能的问题,PG 考虑的也是比较多,例如如果我的一个表只是存储临时的数据,但速度需要很快,对于这些临时数据,如果数据库系统出现问题,丢失在内存还未刷入到磁盘的情况我也能接受,这样的情况下,PG 也提供了 unlogged 表,这个表天生不需要写入 WAL LOG ,数据会直接写入数据文件,损失了一些数据的安全性,成全了性能。


如果这点在MYSQL上,是很难实现的,因为MYSQL是针对整个数据库的表,我可以设置 binlog = 0 ,此时不记录任何的BINLOG ,但对于整体表这样操作,意义不大,那如果我希望MYSQL的性能超级高,不需要写入BINLOG ,那我能做的是建立一个MYSQL数据库并且对于这个数据库不记录BINLOG 的设置,但这样操作显然对于需求有点太大了,并且也直接影响到这个数据库的复制,或者高可用,这就有点大题小做了。


所以随着深入学习PG,发现PG的灵活性的确是很高,并且管理方面也有自己融合各家数据库的方式。对比就是MYSQL的容器化的问题,很多事情都需要在数据库外成型,这点的确对于某些传统行业的数据库使用带来了麻烦。


这里并没有要说MYSQL 的容器化不好,如同糖和盐,都是必不可少的东西,数据库本身没有错,错的是不懂的人,在错误的时间,错误的环境,选择了错误的数据库,导致一系列问题。



相关文章