前几年一直再提云数据库会将很大一批DBA 淘汰，想想自己还轮不上，可惜了，经济不景气，大批的企业更换了数据库使用和运维的思路，各种云也是给力，怎么算成本也比你自建机房要强，数据库的一些硬架构，“硬”维护也和部分DBA 说拜拜了。 此时无论是patroni 还是 repmgrd， 是innodb cluster 或MHA 高可用方式，备份和数据恢复的18班武艺，此时此刻都变得虚无了，好像此时你不是被需要的， go home.
换句话说，DBA的从之前的粗放型经济模式，转换到更注重细节，更贴近业务与设计的集约型模式。社会的变迁如此，一个职业的变化也是如此。
以PG 为例，更深层次的理解数据库的原理与数据库的优缺点，在应用设计中对数据库扬长避短，会是工作的另一个亮点，或者称之为新DBA的存活点。
举例：在应用程序使用PG数据库时，业务场景通过数据库表记录业务状态，频繁更新数据，高频次大量的使用update 对同一行数据进行更新。
“粗放型” DB 或许认为这并不是自己的需要注意或关注的，出了问题使用各种技巧将数据库进行vacuum，调整autovacuum ,或是使用插件pg_repack 诸如此类的方式来解决问题。
集约型的在使用各种云的RDS后，发现之前很多事情做不了了，各种参数的调节都不在你的掌控之下了，甚至连autovacuum_worker 这样的参数你都动不了，看着大把的大表不能及时的进行autovacuum， 此时估计就能体会身体有10万马力，但开关不在你手里的赶脚，抢在手里，但扳机不在你手里的意思。
你可以有两个选择 1 换一个没有被云侵入的企业 2 提高自己的软实力，继续用另一种方式和你的职业战斗。
如果选择用你的方式战斗，手里必须添加一些你能掌控的武器
1 基本的开发应用程序的理念或经验
2 数据库原理的深层次掌握与融会贯通，更注重数据库本身功能的细节
3 公司业务的理解与转化，以及公司业务的特性
4 各种云提供的功能以及特性，甚至可以套出一些原理
5 （秘籍不能说）
继续上面的例子，此时你应该怎么办，根据PG的原理，高频度的UPDATE 对于数据库表本身并没有任何的好处，根据原理 UPDATE = INSERT + DELETE
一行更新 N 次会产生 N+ 1 个行，及MVCC 此时查询还会产生多个数据版本，即使autovacuum工作也不见得能及时收拾的了这些问题。
武器1 ，遇到这样的问题，开发中针对数据状态的更新，可以利用程序缓存内部进行数据的提取 + 更新 + 定时更新数据到表的模式，数据表不在是一个状态变化判断的解决方案，而是一个数据存储的方案。当然也可借助redis 的方式来缓存数据，并尽量在REDIS 中归并多次频繁的更新，当数据状态稳定后，在将数据写入到数据库表中，来化解，高频UPDATE 对PG 数据库本身的冲击。
武器2 ， 根据PG的原理，程序设计时我们不操作UPDATE 而是通过查询此行数据后，直接在程序中将需要改变的数据改变后，再次插入整行数据，而原行可以逻辑标记失效，并且通过程序定期的清理这些逻辑过时的行，在业务低峰期进行VACUUM 的操作以及Analyze 的操作。
武器3 ，业务在数据库上的实现可以进行讨论，并发现其中的漏洞，通过业务的手段来不进行UPDATE 操作，或者根据业务的特性，数据仅仅保留短时期的数据，那么频繁的UPDATE 在小表中也并不是一个太大的问题。
武器4， 看看云产品有没有解决此问题的方案，或者云产品改变了PG的某些核心或缺陷也说不定
解决问题的思路从来不是唯一，而解决问题的思路在于你的经验和对事务的理解深度，并将他合并或分解，最达到终解决问题的能力的提升。
社会在改变，职业的方式也会改变，顺应并作出相应的改变，Learn Understand Remember Apply and then live and enjoy your life.
