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

在今天什么都是架构

从招聘网站中还能看到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吗？那么我们在业务系统中能要求，这里只能点查，那里不能聚合吗？不方便的。

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

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