PostgreSQL 参与某沙龙的演讲稿与回顾

PostgreSQL 参与某沙龙的演讲稿与回顾

最近参与了一个沙龙的知识分享，以下是这次沙龙中我的演讲稿。

正文：

————————————————————————————

这里主要从四个角度来分析和探讨，我想此时已经有同学就产生一个疑问，为什么不从技术的角度来聊，怎么选数据库，尤其相互比较更好。我想解释一下，为什么不用技术来开始比较，因为技术本身是有其适用的场景的，脱离了场景来讨论一个技术问题本身就是伪命题。没有一个技术是千金方，所以如果一上来就比较的话，就会产生一个问题，我说A，大家不熟悉A场景，所以大家从B场景来理解，那我说的大概率都是不对的。举一个最简单的例子，MYSQL好还是PostgreSQL好，其实这个问题本身没有太大的意义，因为各有各的好。

任何一个技术都是有对应的需求，没有需求的技术，很可能他就灭绝了，所以脱离需求来讲我怎么选择哪项技术，或者那种数据库，就有点盲人摸象了。

从需求的角度来分析，我们要从不同的角度来分析这个需求中，到底哪些是真的必要，哪些是非必要的选项，哪些是我们要坚持的，那些是可以妥协的，从这么多年的工作经验来说，一个项目选择的技术方向，例如一个数据库的被选择是有，天时地利人和的，例如 这个项目的架构师，投资商，舆论等等都可能影响你的数据库最终的选型， 这个项目的预算是多少，这个项目的开发周期，项目的人员精通什么技术，等等这些都是问题，都会造成你最后选择的数据库技术的不同，来满足上面的问题。

从cost的角度来看得话，其实我们需要考虑以下成本，人力成本，这非常重要，举例使用PostgreSQL 数据库作为我们目前的某个项目的数据库，但需要我们找到熟练通过JAVA 来操作PG，或有这方面经验的开发人员，目前需要培养，很难找到现成的人员，并且项目的时间短，PG的DBA 也比较难找，此时大概率我们就不会选择PG作为此次项目的主要数据库选择。

一项技术的易用性也是要考虑的问题，或者比如在解决一些开发方面的问题，是否通过数据库的技术能方便的化解，更便捷的实施和部署，这都是一个数据库是否能成为项目中使用数据库的一个维度点。

从学习的成本角度，最简单的事情，如果我是一个生手，想掌握一项技术，官方的文档以及其解决方案是否能容易的被找到，并确认，知识圈是否能轻易的获得，周围掌握这项技术的人是否容易找到并请教，或者我们的线上或者线下的课程能否满足我们的需求等等。

其实说到这里，大家可能就更能理解，今天为什么没有从技术的角度来进行相关的数据库方面的对比和解读。

为什么是COST 优先，不光是软件的项目，各种的项目都要有产出比，所以这是成本的问题。那怎么在一个项目中节省成本，是非常重要的，一个项目或企业在使用一项技术的时候，时刻都要想到成本，大部分以技术为导向的技术工作者，容易忽略这个问题，或者接触不到这个层次上面的问题。

一个数据库的使用和选择与很多情况有关，例如数据库厂商的某些问题，国与国之间的关系问题，企业与国家之间的冲突问题，大家可以关注最近华为大量招聘，ORACLE 和 PG 双料的DBA，因为公司开始启动了去ORACLE的项目，这就是一个上面的案例。公司的体量不大，那就需要考虑成本，一个公司的体量太大，那就更要考虑成本。一套ORACLE 加符合他的服务器的成本可能就需要几十万,或更贵，这就对企业产生了经济压力，尤其最近几年经济比较低缓的情况下，更明显。

另外，还有一个种认为，开源数据库不稳定，功能差，这可能都是早期使用过MYSQL 后的架构师和开发人员留下的刻板印象。实际上开源数据库不仅仅有MYSQL，比如POSTGRESQL , MONGODB ,REDIS, Cassandra,并且MYSQL 也在进步, 不能用刻舟求剑的方式来看问题。

还有一种观点，开源的数据库的人才不好找，这个不是没有道理，他可能不如ORACLE来培养的人才流水线化的方式更快速，导致开源数据库的人才比较难找，并且生长的也慢，怎么认证更是一个问题，尤其商业集团里面他们也是要一些证书之类的东西，证明你有这项技能。

淘宝曾经有全亚洲最大的ORACLE数据库集群，再有钱的公司也要核算成本，商人算计的都是利益，那作为高级打工仔要体现价值，并不是收费的数据库不好，是因为免费的已经达到了我们要的功能需求，降低成本，体现价值，何乐不为，如果还能顺便来将这项技术作为一种架构推广，并赚取利益不是更好。

下面从架构的角度来看数据库的选型，早期大量的银行，电信，传统企业里面大部分都是购买的商业的系统，或整体的商业解决方案，比如小型机+BD2，或者ORACLE 的数据库，从成本的角度来，刚才已经讲过了，如果开源数据库能满足需求，并降低成本何乐而不为。

从开发的角度，现今的业务的变化速度，要比之前业务变化的速度快的多，这也就导致新的开发系统的方式的转变，微服务方式的兴起，来应对多变复杂的业务环境。从架构的角度来说，ORACLE 和 DB2 也越来越不适合当前的软件的开发潮流和趋势。

从上图看，这样的设计对于现在的企业的需求满足是有问题的，从数据库的角度，如果ORACLE DOWN掉，我们的所有的业务模块全部DOWN掉，如果我们把每个业务模块都分别连接到单个的ORACLE的数据库上，成本又不允许，或者随着业务的扩展，以后的扩展的瓶颈可能都在数据库上，因为都在一个数据库，没有解耦，将这些模块的信息交换都在数据库内部做了。以后的问题就会越来越多。

所以不再使用ORACLE 的原因也很多，从架构的方面考虑我们没有必要再在每个环节要使用这么重的数据库。

这里的扩展指的是横向思维，还是纵向思维的模式来进行扩展，早些年间我们大部分都是通过纵向的手段来进行问题的解决因为简单，奏效，而横向的方式来解决问题，则需要的技术水平是不一样的，他的思维模式复杂，需要软件架构，硬件架构，数据库架构，全方面的做出努力，数据库为了应对横向扩展，引入例如分布式的数据库等等。

从运维的角度，从原来的一台大型机，或几台数据库的服务器，变成现在很多企业动辄成百上千的数据库服务器群组。应对性能和业务的扩展。所以现在的运维在监控，管理，备份等等面对的需求也都变化了，自动化管理的方式需求越来越多。

程序的复杂度，程序的复杂度与业务，和底层的架构都有关，实际上选择了不同的数据库后，数据库的使用的方式就有所改变，例如某些开源的数据库，造成数据库本身功能的弱化，程序承担原有数据库方面的可以做的工作，导致数据库承载能力的简单化和容器化。

为什么这样说，不是每个业务面对的都是，简单的，高并发，的业务逻辑，例如秒杀，点餐，叫车，实际上大面积的企业，需要的不是高并发，而是复杂逻辑的处理，复杂事务的处理，这也是为什么至今还有大量的企业，在使用ORACLE的原因，因为他能在可控的成本下，满足这些需求。并且传统企业很难快速提高目前的软件开发水平，以及解决复杂逻辑方面，去使用MYSQL 数据库达到理想的或同等与原来的水平。

例如：并行化处理SQL ， 多种复杂的JOIN的处理， 高密度的存储过程的需求，主外键关系处理，在程序还是数据库的问题，如果延续传统企业不动原有架构的方式下，和开发软件的方式的情况下，则分布式和MYSQL 解决此类问题比较困难。

那这就提出一个问题了，ORACLE 直接数据迁移，不需要再系统架构上做推翻性的变化，或彻底抛弃现有架构，那数据库的选择的范围可能就不如我们想象的那样多。

从实际问题的角度来看数据库的选型，我们可以通过实际的几个例子来看

1 应用开发中，需要进行模糊查询，%值%的方式。

面对不同的数据库的解决方式

1 postgresql 对需要进行查询的字段添加 GIST 或者 GIN 索引，然后直接使用我们最熟悉的语句去查询

2 其他数据库，开启全文索引的功能，或者引入ES的方式来处理需求，同事程序上也需要进行特殊的处理，合并结果。

从各种角度考虑，开发成本，复杂度，运维成本等等，我想大家应该可以进行相关的比较。

2 一家传统企业，开发人员的水平一般，目前开发的财务系统由于要求的开发速度快，业务逻辑也比较复杂，其中开发人员需要在数据库端建立部分存储过程，简化程序设计进行一些批操作，或者一些复杂事务的需求。

在这样的情况下，如果坚持使用某种流行的开源数据库，则存储过程的需求可能就不能再数据库端来实现业务逻辑，需要将其在程序端来实现，所以会将事务打散，并且部分使用2段式提交的方式来解决复杂的问题，系统和数据库的交互次数会直线升高，并且还要注意某些语句的写法，否则很可能性能低下。

那从开发者和老板的角度，这样的方式可能就不会满意，开发人员也会怨声载道，那我们就一种和ORACLE 类似解决方案的匹配的开源数据库。来满足我们上面提到的 成本，架构方面的满足，并降低复杂度。

3 某软件开发企业，开发定制化的软件，提供给甲方的时候，需要打包整体运维部分一并提供给甲方，甲方是一家跨国外资企业，法务部门对合同进行审核，发现软件开发企业提供数据库虽然是开源产品，但其中的开源协议不适于商业化，对软件公司提供的产品提出了异议

最后这个案例，其实和我们的软件开发商是有关的，因为软件开发商除了开发系统也提供包含运维等等一整套的服务和软件的维护安装等等服务，如果此时我们的开发商将软件产品与MYSQL数据库一并提供给企业，则这样是不符合相关法律的，有人可能说那让甲方自己装MYSQL 数据库不就行了，其实我们是知道一些企业，尤其是外企对于法律文书方面是非常在意的，尤其是合同，很可能就因为一个你认为不是问题的问题，和你解除合同。PG 遵循的是BSD 协议，在法律上面临的风险会比较小。

最后一个问题，可能会跟我们自身从业者的自身利益有关，也就是职业规划，现在我们从JD上招聘架构或者DBA 的时候，尤其DBA的时候，很少会看到只会一种数据库就可以的，基本上2-3种，即使知识招一种，则大概率是这家公司不止一种数据库，但需要专人来管理某种数据库。

这就会涉及我们的职业的发展的宽度的问题，如果公司从ORACLE转型到其他数据库，你在开始学，那公司是不是要考虑你职位存在的必要性。

我经常听到一些DB的朋友说，别学PG，没有发展，首先先不说PG有没有发展，这样的话其实10年前我就听到过，不过主角是MYSQL ，说别学MYSQL 没有发展。

从学习的角度来看，掌握的数据库种类越多，你的思路就越开阔，处理问题的角度和思路都会不一样。，在面临不同的项目中，能过提供的处理方法不会只有一种，并时常会有一种无力感。

那么我们目前的头部的公司对数据库的态度来看，也是从未偏爱过一家的，腾讯的TDSQL ,TBASE 就是腾讯对数据库的态度，MYSQL + POSTGRESQL 的混合方式，其他公司也是一样，这里不再举例了。所以一库走天下的时代已经过去了，我们为什么不充实自己，提高自己的附加值，俗话说的好，多条后路多条命，尤其在当下竞争激烈的环境。