数据库 频道

数据库真的是能够决定架构的

  在今天什么都是架构

  从招聘网站中还能看到Java架构师、PHP架构师.NET架构师等等。我不否认每个都有自己的架构,但是我觉得这些都应该是应用架构。

  我接触到不少架构师是Java出身,然后也懂操作系统,也知道一点数据库,也懂中间件。只是喜欢简单问题复杂化,动不动就是Redis、Mongodb、Kafka、RabbitMQ、NGINX等等。再就是DataX的数据同步。确实全面覆盖了。

  但是没有从数据库–数据架构的角度去考虑

  举一个例子,我和开发说你这个报表写的不太好,要么你到从库执行? 这时候开发说,我这个查出来以后要做数据的更新,也就是说要有写的动作。这个怎么解决?在开发思维中从库是不可以写的。

  从库是不是不可以写?未必。

  举例来书Oracle的ADG从库是不可以写入的。但是严谨一点的话,在19C的版本中DML重定向以后是可以写入的。而且可以保证数据一致性。当我说到这里,开发不明白,问到你能识别哪个是select那个是update吗?

  我回答没必要知道,你所有请求都到从库上,数据库给你解决。

  开发依然不明白,那么架构呢?我说数据库都给你做了。

  开发依然不明白,不是读写分离是架构的事情吗?我说数据架构也是架构。

  其实不仅仅是Oracle。那么MySQL的Innodb CLuster 就是Router+MGR这样,也没有需要应用架构师做什么工作。数据库自己的组件全解决了。这里更加不要说RAC这种对应用全透明的架构。

  也许有些人不喜欢这样的,因为数据库全做了,他就没什么可做的。无法凸显。但是我觉得好的数据库就是提供了友好的功能让大家架构简单。

  其他的数据库也是有类似的,我就不一一点名其他的数据库了。

  数据库趋势之一-HTAP

  天下苦Hadoop久已,凡是运维过Hadoop的都有自己的苦楚。至少我没听到过说运维Hadoop一个字:爽。没有,从来没有。但是我听过运维ExaData的人说,爽。

  OLTP到OLAP就一个实时性和准确性就能要了运维的半条命。而如果几乎头部的数据库公司都有自己的HTAP解决方案。

  这是什么?这就是架构,再也不用Kafka、DataX、CDC、以及哪怕宣称最稳定的OGG了。

  Hadoop全家桶也是架构,但是不友好。

  就像前面开发人员说的,你能分得清select那个是update吗?那么我们在业务系统中能要求,这里只能点查,那里不能聚合吗?不方便的。

  如果从数据库角度出发,整个架构就会很清楚

  试想当你系统的数据库缩减到几套的时候,架构就会很简单。用数学的思维看,当只有一套时候。那就没什么架构了。大道至简!

0
相关文章