大数据 架构 PostgreSQL Oceanbase Oracle 日志 高可用 数据库 集群 同步 逻辑复制 高性能 存储 海量数据
摘要: 在 2017 年的 DB-Engine 的年度数据库榜单上, PostgreSQL 以其超过其他 341 个受监控数据库管理系统的受欢迎程度居于榜首, 被评为年度 DBMS. 其总体排名也超过 MongoDB, 在其流行程度上排名第四.
在 2017 年的 DB-Engine 的年度数据库榜单上, PostgreSQL 以其超过其他 341 个受监控数据库管理系统的受欢迎程度居于榜首, 被评为 年度 DBMS . 其总体排名也超过 MongoDB, 在其流行程度上排名第四.
PostgreSQL 是 DB 领域的一匹黑马, 之前一直默默活在 MySQL 的阴影之下, 今年随着 10.0 版本的发布, Declarative Partitioning 的引入, 改进的查询并行性, 逻辑复制和同步复制的 Quorum Commit ,PostgreSQL 10 的影响力在不断的增强.
今天我们有幸邀请到了 PostgreSQL 的专家朱贤文老师, 为我们分享 PostgreSQL 的核心技术, 发展现状及未来方向.
DB 舞台谁是王者之 PostgreSQL 专访遇见未来
自我介绍, 团队介绍
我是朱贤文, 是成都文武信息技术有限公司的总经理, 创始人. 我入 IT 行业接近 20 年, 主要熟悉数据库, 存储和集群这些 IT 基础架构比较底层的技术; 在这之前, 曾在 Oracle,Veritas,IBM 等公司工作, 做研发的经验主要在 Oracle RAC 和 Storage 和集群, 涉及的技术比较底层.
我们是一个创业团队, 现阶段不到 20 人, 我们专注在 PostgreSQL 数据库的商业解决方案及和技术服务, 产品和方案; 比如集群, 容灾, 备份, 咨询等.
我们有一套自研的专门用于数据库的高性能私有云系统, 支持 PostgreSQL 和 Oracle 数据库高效可靠地运行.
作为 PostgreSQL 领域资深的专家, 请您简单介绍下 PostgreSQL 技术的发展历程
实在不敢当专家的称号, 我只是对 PostgreSQL 熟悉一点罢了.
PostgreSQL 是一个非常先进的, 有很多高级特征, 企业级功能非常丰富的开源数据库, 在金融, 银行, 电信, 生产制造等行业有非常多的成功案例.
PostgreSQL 的发展历程
PostgreSQL 的前身是美国国防部与 UC Berkeley 大学合作的一个研究项目, 叫 Ingres, 起源于 1973 年; 1985 年研究项目终止, 随后开源, 并且命名叫 Postgre, 随后又改名为 Postgre95;1996 年因为加入了完整的 SQL92 标准支持, 为了强调对 SQL 的支持, 所以更名为 PostgreSQL, 这个名字一直沿用到现在. 到目前为止, 其连续活跃的开发历史已超过 32 年, 算上 Ingres 时期的开发历史, 项目实际上接近 45 年连续开发.
PostgreSQL 的发展, 经历了几个重要的版本
从 8.0 开始, 逐渐增加了众多的企业功能, 包括写日志, 表分区, 物理同步复制, 物理异步复制, 逻辑复制, 在线热备份, 并行查询.
目前最新版本为 10.1, 完善了表分区和 hash 表功能.
PostgreSQL 的特点
PostgreSQL 数据库的跨平台特性非常强, 支持几乎所有的操作系统和 CPU 硬件平台, 如 AIX,HPUX,Linux,BSD,Windows 等.
PostgreSQL 的开发是由社区驱动的, 各种高级先进的特性主要来自于用户的反馈和需求; 社区的成员来自于全球的商业公司, 高校, 研究机构等, 开发和发行过程非常严谨, 产品代码质量非常高. 目前国内有很多公司基于 PostgreSQL 数据库开发自己的商业产品.
还有一些明显的特点包括: 比如非常丰富的数据类型, 丰富的开发接口和编程语言的支持, 丰富的索引类型, 很多的企业级高级特性等等, 都能够满足绝大多数企业级应用的要求.
PostgreSQL 的发展
PostgreSQL 数据库的支持跟商业数据库一样, 从 6.3 开始, 每一个发行版本社区都会支持 5 年, 这个传统从 1998 年开始, 马上也进行了 20 年了.
从国内使用情况来看, 现在 PostgreSQL 的影响力越来越强, 越来越多的专业用户将 PostgreSQL 用在他们的业务系统中, 比如中国平安, 中国移动, 联通, 互联网包括去哪儿, 腾讯, 阿里.
从生态区和支持这个方面来说是越来越完善, 现在有华为, 腾讯, 阿里以及我们成都文武信息在内的专业公司, 对其提供商业支持和服务, 并且基于它开发自己的高性能数据库.
在 PostgreSQL 10 版本中, 您最关注的新特性和技术点包含哪些? 或者您认为最重要的变化?
PostgreSQL 10 版本中, 新的特性比较多, 下面只列出部分, 详细的部分可以参考官方 Wiki:https://wiki.postgresql.org/wiki/New_in_postgres_10
大数据处理: 原生分区, 并行执行, FDW 下发 / push-down, 更快的查询支持;
复制和很横向扩张: 逻辑复制, 同步复制实现 Quorum Commit - 类 Raft 的部分功能, 临时复制 slots 支持, 连接层的 failover 和 routing, 加强的物理复制;
系统管理: pg_receivewal 支持压缩, pg_stat_activity 有了专门的后台处理进程等;
SQL 功能: Identity Columns,Crash Safe,Replicable HashIndexes,Transition Tables for Triggers;
XML 和 JSON: 支持 XMLTable,JSON 和 JSONB 的全文搜索
PostgreSQL 的最佳应用场景是什么? 有哪些比较成功的案例实践? 目前市场需求如何?
个人认为 PostgreSQL 适合对性能, 可靠性, 业务连续性要求非常高的企业级 OLTP 应用, 以及小规模 OLAP 应用, 比如数据量小于 50T 的 OLAP 系统.
现在国内可以参考的案例还是非常多, 比如平安集团有 1500 多个实例部署; 乐友母婴用品店, 核心的数据库系统是一个接近 10T 的 PostgreSQL 在线数据库支撑全国的业务; 除此外, 还有探探, 去哪儿网, 百度地图等, 都有很大的 PostgreSQL 部署量, 高效可靠地支撑业务系统; 还有一些传统行业, 如浙江移动, 湖北移动, 中国联通等.
根据我知道的信息, 市场对 PostgreSQL 数据库的需求一直都是高速增长的, 增长的量主要集中在两个方面:
一方面是新建的对可靠性, 业务连续性要求高的 OLTP 系统, 越来越多的用户将 PostgreSQL 作为优先选择的数据库;
另一方面是数据量小于 50T 的小型 OLAP 业务系统, 很多用于会优先选择 PostgreSQL 作为分析引擎.
这种需求最近一两年表现尤为明显.
您是否可以简单介绍下互联网模式下, PostgreSQL 数据库的高可用架构有哪几种模式?
第一种跟其它数据库的高可用架构基本上一样, 就是采用共享存储模式, 数据库存放在共享存储上; 一台主机, 一台备机; 正常情况下, 主机连接存储启动数据库对外提供服务; 当主机故障, 备机接管存储, 并且启动数据库, 继续对外提供服务; 这种架构的好处就是数据是专门的存储提供保护, 不用担心丢失, 切换服务的时间需要集群管理软件决定, 一般来说基本中就可以完成切换;
第二种是基于流复制的高可用架构, 这里面有几个发展的阶段,
(1)第一个阶段是基于对 PostgreSQL WAL 日志文件的复制, 这个方式目前基本上很少用了; 大致的工作原理是集群内一个主库一个备库, 当 WAL 日志归档后, 这个文件同时拷贝到备库; 备库始终处于恢复状态, 接收到主机拷贝过来的 WAL 日志文件, 立即恢复到备机; 当主机宕机, 备库立即切换模式, 恢复成主库对外服务;
(2)第二个阶段是物理复制 --- 流复制, 主库正常工作, 所有提交的事务除了写在本地的 WAL 日志文件, 同时还会将数据通过网络传输到备库. 通过控制对网络上数据传输时间的确认, 可以分为异步复制和同步复制, 这两种复制方式会涉及 SLA 定义的 RTO 和 RPO 等指标, 同时也涉及到系统性能.
(3)目前的阶段是物理流复制方式比较丰富的阶段. 在以前的复制方式上, 对同步复制的控制手段很少; 现阶段不仅可以控制集群内有多少台同步复制, 而且可以控制数据提交成功的确认方式, 例如在多少个同步复制节点提交成功, 以什么样的方式在同步节点上提交成功, first n, any n 等比较细粒度的控制复制成功时确认信息的行为; 同时也可以比较细粒度地控制复制过程中的性能, 比如发送到备库的 buffer 确认, 还是备库写入 wal 确认, 还是备库需要 replay 确认等......
第三种是逻辑复制. 逻辑复制的好处比较多, 比如可以跨平台跨操作系统, 可以控制需要复制的表而不是整个库进行部分数据的复制, 比如用于 OLAP 分析系统的数据同步; 也可以用于做不停机的业务系统升级.
另外说一点就是 PostgreSQL 可用的高可用方案比较丰富, 有开源的方案比如 pgpool, 也有一些商业的解决方案, 比如我们公司的 ECOX 系统. 客户在设计和选用高可用方案的时候, 严谨的生产系统最好要购买专业的服务. 我们是国内比较好的服务团队并且能提供完整的解决方案跟相关技术.
请您介绍一下 PostgreSQL 中目前比较成熟并且流行的存储引擎和他们的使用场景吗?
PostgreSQL 不像 MySQL 数据库那样有很多存储引擎. PostgreSQL 只有一种存储引擎, 对事务处理非常严谨严肃, 主要用于高性能的 OLTP 业务场景. 同时也可以用于小型的 OLAP 分析型业务场景.
PostgreSQL 数据库在向着自动化运维的方向发展的过程中, 面临的最大的挑战是什么? 如何克服?
PostgreSQL 数据库, 不像我们常用的 Oracle 数据库, 如果参数设置得当, 应用设计也比较好, 这种情况下其实不需要太多的维护;
对于 PostgreSQL 来说, 反而是需要将精力放在存储子系统的可靠性, 备份等方面.
存储子系统的可靠性需要仔细地设计, 因为它不仅关乎系统性能, 也关乎数据本身存放的可靠性. 如果是严谨的商业应用, 建议优先选用可靠的存储系统和文件系统; 我们作为有丰富实施经验的专业厂商, 我们会推荐用户优先选用 ZFS, 特别是原生的 ZFS, 这个领域我们有完整的方案.
PostgreSQL 数据库与其他开源数据库相比较的优势
相对于其它数据库而言, PostgreSQL 的优势是非常明显的, 比如:
有庞大的潜在的开发群体, 运维群体和完整的生态; 因为 Oracle 的生态系统非常完善和成熟, 熟悉 Oracle 技能的人迁移到 PostgreSQL 数据库上的学习曲线非常平滑, 成本非常低. 根据我自己的经验, 基本上 2 周时间可成.
有大量的银行, 电信, 保险, 政府等行业的关键业务应用案例和知名客户.
有丰富的开发接口和开发语言支持, 丰富的数据类型, 支持传统的关系型数据和非关系型数据. 对 GIS 非常好, 对 JSON,JSONB,XMLTable 支持非常好.
非常丰富的 fdw 扩展, 几乎可以支持所有的外部数据源和数据库.
非常先进的企业级特性, 比如复制, 分区, 在线热备份, 非常丰富的索引, 函数等.
非常优秀的跨平台, 跨操作系统支持. 支持几乎所有的硬件平台和操作系统. 大到 mainframe, 小到嵌入式系统.
高品质的代码, 优雅的设计, 非常长时间的, 持续活跃的开发历史.
每个发行版本都能获得为期 5 年的产品支持.
当然也有需要完善的地方, 比如:
宣传不到位, 现在还有很多用户不清楚, 甚至不知道 PostgreSQL 是一个生么样的数据库.(这一点会导致用户选用技术线路失误, 从而导致后面的应用系统开发和维护成本很高.)所以应该加强 PostgreSQL 数据库的培训和宣传.
国内从事 PostgreSQL 的服务商比较少, 高质量的专业服务商更少.
技术上目前还不支持块级别的增量备份和恢复(这个功能已经在线路图上, 很快会有)
可以请您谈一下对 OceanBase 数据库的认识和看法吗?
OceanBase 是一个非常有特点的数据库, 全新的设计, 也在高性能, 高可靠性方面有比较好的表现, 17 年双 11 表现的每秒处理 26 万多笔交易的威力 (性能) 大家也见识过了.
OceanBase 的主从数据库
在传统的数据库主从架构中, 比如(Active)DataGuard, 主库对外提供全功能的读写服务, 从库对外提供只读服务, 主库到从库通过流复制技术使数据保持同步;
在 OceanBase 中, 也有主和从的概念, 复制也是主到从, 与传统数据库不一样的是这个数据库的主, 从概念是建立在分区表的分区上, 每个表有多个分区, 所有节点都可以有全部或者部分分区, 分区有多个副本, 分布在集群内的其它节点上, 副本可以看作是是从, 只接收主上面的日志, 并且回放到内存里, 一个可以读写的分区就是一个主; 一个主可以有多从, 确保数据有多份拷贝, 主到从的日志传输通过 Paxos 协议完成, 确保数据可以正确传输到其它节点;
整个集群对外来看, 所有节点都是读写的, 全功能的, 比传统数据库优势明显, 因为多活, 负载均衡可以实现比较好, 可以用低廉的硬件实现高性能, 高可靠的系统;
仔细观察集群内部, 由很多表的不同分区及它们的副本构成非常多的主从复制, 所有的日志数据复制基于 Paxso 协议, 能够保证任何节点损坏都不会有数据丢失的危险(当然节点坏掉的个数不能大于节点总数的一半).
OceanBase 另外一个比较有意思的设计就是类似于传统数据库中的 check_point 的处理, 传统数据库的 check_point 时间根据负载和 SLA 的一些要求, 一般保持在几分钟到半个小时之间, 数据库要做一次 check_point, 以确保数据库的数据一致性; 而 OceanBase 数据库把传统数据库类似 check_point 功能的操作周期做得非常长, 比如一天做一次数据整合(类似于传统数据库的 check_point 操作); 这样做有好处, 就是对 SSD 这种新型电子磁盘的寿命有帮助, 因为对 SSD 的操作都是大片大片的, 整块地删除, 写入, 尽量避免 SSD 内部的写放大, 这个设计的前提是基于服务器有非常大的内存配置, 比如 256G, 甚至 1T, 现在的机器内存配置都比较大, 很容易配置大内存的集群, 那么把数据库的 data buffer 做到足够大, 数据库所有的操作都在内存里, 相当于一个准内存数据库, 比操作磁盘的 IO 要快很多; 通过这些设计, 非常合理地避免了全分布式, 高可靠, 高性能并发和 mvcc 之间的矛盾.
OceanBase 的设计非常聪明, 它的出现的确给了我耳目一新的感觉, 不管是技术上的创新, 架构上的创新, 技术来源, 都是值得大大地给一个赞, 说到技术创新, 架构创新, 我们的鸿鹄彩云系统就是为高性能数据库业务设计的, 里面也有很多可以让人感觉耳目一新的技术创新的点, 希望更多的人可以尝试试用;
当然一个新事物的出现需要一个时间完善和成长 / 成熟的过程, 对于 OceanBase 来说目前也需要有完善的地方, 比如技术上与现有的用的广泛的 Oracle 的兼容性, 跨库交易等, 关键行业的成功的应用案例等, 让我们多给它一些时间, 多给一些耐心;(当然我对 OceanBase 的了解也比较有限, 可能有很多技术特点没有讲到, 请包涵)
近几年随着大数据时代的到来, NoSQL 数据库在处理海量数据上表现出越来越多的优势, 请问您如何看待数据库的未来, 会朝着什么样的方向发展?
从数据本身来说, 真实世界里生产的 95% 以上的数据都是关系型的, 只有很少的数据是非关系型的.
所谓的 NoSQL 是 Google 在很多年提出来的处理大数据的一个技术方案, 主要使用的思想就是 Map/Reduce, 学过数据库的人都应该了解, 这项技术实际上在上个世纪 60 年代, 在大型机上处理大量计算常用的技术思想.
Google 最终推出了自己的 Spanner 数据库, 结果是非常明显的, Google 自己都不用 NoSQL, 而回到传统的 SQL 这个线路上面来, 所以未来还会向 SQL 这个方向走.
PostgreSQL 数据库未来将会如何演变, 如何应对海量数据的实时处理需求?
PostgreSQL 未来还是会持续, 活跃地开发高品质的软件, 并且根据市场需要提供满足市场的技术特性; 国内的市场也会普及和成熟, 用户也会接纳并且广泛地使用 PostgreSQL 数据库, 并且从中受益.
应对海量数据的实施处理, 可以选用高性能硬件, MPP 架构的技术; 以后也会有基于内存的 MPP, 甚至用 GPU 加速运算的数据库; 但是最终还是需要看用户本身的需求和业务特点, 根据这些进行有针对性的设计和实施, 以满足这类需求.
来源: https://yq.aliyun.com/articles/409422