应用层数据访问

十几二十年前就是单库事务，OLTP和OLAP共用一个数据库，今天还是很多公司在沿用这种应用开发模式， 不是技术没有发展，而是人没有发展，运行规则没有发展。

单库读写+数据分析， 到单库读写分离， 到OLTP和OLAP分离， 到整个数据链路的streamline，经历过的感觉很easy，但是大部分公司的技术演变，却死死的受限于技术团队的人和对应的思维困境中。

数据库的新与旧

大概是三四年前吧，大虫跟我说TiDB的时候， 我还是很不看好这种模式的， 但今天看来，我觉得，可能那时候的我过于自负了。

实际上， 单纯从技术角度去评估， 我倒是更乐意推荐原来的方案， 即应用好业界现有数据库的单库特性（比如mysql， postgres等）， 然后通过外部化的方案整合成集群方案来应对大数据和大规模扩展场景。

但是，当我看到很多公司的应用开发人员和团队“捅”数据库的玩法，以及对数据库集群的基础理解和把控能力之后，我倒是挺推荐他们新方案直接上像TiDB这类新时代的数据库的， 既然现在很多技术团队的核心价值是 快速应用开发 ，那么就别学什么BAT折腾那些中间件啦， 那不是你技术团队的核心竞争力，公司也不愿意在这些上面投入太多， 只要新时代的数据库提供了兼容的接口（比如TiDB的兼容mysql协议的策略），那应用开发团队还是直接像十几二十年前那样直接“捅”数据库吧， 爱怎么折腾怎么折腾， 等真的发现性能瓶颈的时候再调整和优化好了。

所以， 采用新时代的数据库的策略选择不是基于技术牛逼不就逼，而是你是不是可以减轻快速应用开发的认知和使用成本，我觉得从数据库的开发者到很大一批从业人员应该都太会认同我这么说吧~

数据仓库与BI

十几二十年前的报表方案依然在现在中国大地上很多公司里开花结果， 搞个报表还得投入专门的研发搞排期和开发， 基于Hadoop的生态方案在这些公司里都成了新时代的救世主， 很多2B的顾问公司和解决方案供应商也是大数据言必Hadoop，殊不知， 即使是Hadoop也是十几年前的方案，今天，扩展存储和扩展计算早可以有更好的方式，只是80%的人和团队都视而不见罢了。

对于商业智能和数据智能来说， 也早已进入了 self-service时代 ， 不是我不告诉你，而是人的思维和公司运行规则与文化实在根深蒂固， 软件和工具先进不先进真的是其次， 很多时候，你只能依托人， 现有的人和团队， 来完成工作， 这也就是他们熟悉啥就用啥吧，只要拿到结果就好。 管理上不是早就告诉过你嘛： 不要尝试改变任何人！

原文：https://afoo.me/posts/2020-04-08-tech-and-people-paces.html

链接: https://www.fly63.com/article/detial/8522