2017优秀网站设计欣赏,自己创建网站怎么做电商,网站开发绩效考核,网站推广 营销作者 | 张秋剑#xff0c;天云数据上海副总经理责编 | 唐小引头图 | CSDN 下载自东方 IC出品 | CSDN#xff08;ID#xff1a;CSDNnews#xff09;近日#xff0c;有传闻 PostgreSQL 会发布 13 版本#xff0c;这是去年 9 月发布 12 版本之后#xff0c;PG 社区紧锣密鼓… 作者 | 张秋剑天云数据上海副总经理责编 | 唐小引头图 | CSDN 下载自东方 IC出品 | CSDNIDCSDNnews近日有传闻 PostgreSQL 会发布 13 版本这是去年 9 月发布 12 版本之后PG 社区紧锣密鼓的又一大动作包括提升查询性能特别是对大数据集总的空间利用率等方面。同时国内以华为 GaussDB 200 从 PostgreSQL 9 中继承而来PostgreSQL 在中国的生态变得空前火热。这与近两年来以 Google F1 理论为代表的 NewSQL 数据库一起形成了数据库在这个时代的两支牛角气势如虹地改变着 TI 数据中心架构的新世界。我们今天就来“庖丁解牛”一把看看两种技术路线的不同之处。PostgreSQL 的前世今生PostgreSQL 是一个功能强大的开源对象关系型数据库系统它使用和扩展了 SQL 语言并结合了许多安全存储和扩展最复杂数据工作负载的功能。PostgreSQL 的起源可以追溯到 1986 年作为加州大学伯克利分校 POSTGRES 项目的一部分并且在核心平台上进行了 30 多年的积极开发。直到 2019 年 9 月已经正式发布到了 12 版本。图片来源维基百科Michael Stonebraker2014 图灵奖获得者PostgreSQL 数据库创始人。目前数据库领域一共有四位获得图灵奖1973 年 Bachman数据库与网状数据库1981 年 Codd关系数据库1998 年 Gray数据库与事务处理伯克利分校是 Postgres 的摇篮图伯克利分校著名地标萨瑟门CSDN 下载自东方 ICPostgreSQL 的特点可以用以下这张图来概括PostgreSQL 的架构最合适做企业级数据库。基于 PostgreSQL 的开源项目分支述说完了 PostgreSQL 的历史我们来聊聊 PostgreSQL 在开源社区世界的发展我们知道数据库近 40 年来的发展基本上是从 RDBMS 到 OLTP/OLAP 分离再到分布式数据库发展的这样一个历程。PostgreSQL 的历程也是如此从 PostgreSQL 内核开始也经历了 OLTP 分支、OLAP 分支再到大势所趋两者重新融合往混合 OLA/TP 的分布式数据库方向演进。分布式 PostgreSQL-X2 架构介绍既然 PostgreSQL 已经发展到了混布阶段那么我们就直接从本文主旨开讲看一看 X2 架构的特点。首先X2 是基于 PostgreSQL 源代码改造成的分布式数据库所以几乎拥有与单机数据库的所有功能支持复杂的 SQL 和跨节点 JOIN全局事务的强一致性支持 Read commited 事务隔离级别几乎支持所有单机数据库的 DDL 语句支持跨节点的视图支持跨节点的存储过程。其次X2 主要目的实现数据是水平分片也就是说需要基于分库分表来解决数据线性扩展的问题。再次X2 针对 OLAP 是 shared-nothing 架构所以是一种 MPP 的技术原理可以实现 ETL 的数仓加工。最后API 完全兼容外部应用程序可以透明的访问 Postgres-X2原先的 jdbc 等不同编程语言的驱动也基本不需要修改就可以访问 Postgres-X2。从上图的 X2 架构我们可以看到X2 主要由三个部分组成GTM全局事务管理提供全局事务的服务Coordinator存储全局的元数据接受用户请求负责生成并执行全局查询计划全局查询计划由若干局部查询计划组成执行时将局部查询计划分发给 datanodeDatanode存储本地的元数据接受并执行 coordinator 的局部查询计划局部查询计划也是 SQL。分布式 PostgreSQL-X2 的 CAP 分析我们知道 CAP 原理是考量一个数据库标高的评价标准在 RDBMS 时代Oracle、MS SQLServer 都能较好地接近 CAP。在分布式数据库时代CAP 理论依然是我们评价的主要工具。AP 原则又称 CAP 定理指的是在一个分布式系统中一致性Consistency、可用性Availability、分区容错性Partition tolerance。CAP 原则指的是这三个要素最多只能同时实现两点不可能三者兼顾。首先在一致性上PostgreSQL-X2 采用 GTM 来实现GTM 对事务强一致的保护是比肩传统 RDBMS 的这一点上具备生产级。与 2PC 和 MVCC 相比有先进之处。然而总体开销会比较大如果是巨大的互联网应用场景动作上亿的并发访问性能难于优于 MySQL。2PC 又称两阶段提交two-phase commit protocol,2pc 是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点一个是中心化协调者节点coordinator和 N 个参与者节点partcipant。MVCC 英文全称为 Multi-Version Concurrency Control,翻译为中文即多版本并发控制。MVCC 的实现通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。客观上我们认为它就是乐观锁的一整个实现方式就是每行都有版本号保存时根据版本号决定是否成功。在可扩展性方面Postgres-X2 的扩容可以在 Coordinator 和 Datanode 两个方面同时进行扩容。Postgres-X2 符合分布式数据库线性扩展的标准在 x86 横行的时代通过横向对机器的方式扩展计算资源和存储资源是分布式的核心理念在这一点上Postgres-X2 也是这么做的。但是Postgres 本身的问题是数据量不能支持很大数据量在 40 个 TB~200TB做大型数仓仓库性能随数据量增大节点数增多而出现衰减不能够完全跟随线性扩展做线性性能叠加。这是容易被诟病的一点。再一个不能够很好地支持在线热插拔热添加。如果新增节点需要做停机重启这样的话实时 ODS 这一类的应用就不能够在 Postgres-X2 构建的 OLAP 上应用。分区容错性不是 PostgresSQL 主要考虑的问题。因为多数分布式系统都分布在多个子网络。每个子网络就叫做一个区partition。分区容错的意思是区间通信可能失败。比如一台服务器放在中国另一台服务器放在美国这就是两个区它们之间可能无法通信。上图中G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息G2 可能无法收到。系统设计的时候必须考虑到这种情况。这种情况目前主要是大型云厂商如Amazon QWS S3、Google Spanner 和阿里云的 OceanBase 去着重打造。Postgres-X2 我们只从数据中心的高可用性上探讨高可用方面GTM 不像 Greenplum 只有一个 master 节点不适合 OLTP 业务。虽然 Postgres-X2 本身也没有自动的高可用性但可以通过 SPOFsingle point of failure分析根据不同的业务情况进行高可用建设例如上图是采用 Primary–Standby 的方式来构建高可用架构。另外原来的 Postgres-XC 的 D-Node 间不能传数据数据需要汇聚到 C 节点进行处理 Postgres-X2 之后允许 D-Node 间进行数据传输。以上我们算是比较全面的了解了 PostgresSQL 和他的分布式项目 Postgres-X2我们可以总结一下在“从数据库技术的 40 年发展历程看新征程”一文中我们通过回顾数据库的发展史重新理解了数据库的定义——数据库就是一个存放数据的仓库这个仓库按照一定的数据结构数据结构是指数据的组织形式或数据之间的联系来组织存储的我们可以通过数据库提供的多种方法来管理数据库里的数据。我们的程序都是在内存中运行的一旦程序运行结束或者计算机断电程序运行中的数据都会丢失,所以我们就需要将一些程序运行的数据持久化到硬盘之中以确保数据的安全性。说白了数据库就是存储数据的仓库。我们已经提到数据库已经可以分为几类有数据库经过 40 年的发展经过从 RDBMS 到 MPP 再到 NoSQL 数库如今我们开始关注 NewSQL 数据库。每个阶段的特点是怎样的呢RDBMS——关系型数据库的优点是事务、索引、关联、强一致性其缺点是有限的扩展能力、有限的可用性、数据结构取决于表空间MPP——大规模并行计算数据库的优点为扩展性强、事务、索引、关联、可调一致性缺点应用级切分、数据结构取决于表空间NoSQL——超越关系型数据库数据库其优点在于扩展性强、可调一致性、灵活的数据结构而缺点是事务支持差、索引支持差、SQL 支持差。最经典的是传统关系型 OLTP 数据库其主要用于事务处理的结构化数据库典型例子是企业的转账记账、订单以及商品库存管理等。其面临的核心挑战是高并发、高可用以及高性能下的数据正确性和一致性。其次是 NoSQL 数据库及专用型数据库其主要用于存储和处理非结构化或半结构化数据如文档图时序、时空K-V不强制数据的一致性以此换来系统的水平拓展、吞吐能力的提升。再者是分析型数据库(On-Line Analytic ProcessingOLAP)其应用场景就是海量的数据、数据类型复杂以及分析条件复杂的情况能够支持深度智能化分析。其面临的挑战主要是高性能、分析深度、与 TP 数据库的联动以及与 NoSQL 数据库的联动。除了数据的核心引擎之外还有数据库外围的服务和管理类工具比如数据传输、数据备份以及数据管理等。NoSQL 数据库解决了扩展性高并发访问但还有很多未尽如人意之处比如索引无法有效使用索引 —Ad Hoc Query协处理器无法分散计算任务 —大表的 Join 查询SQL 以外的分析查询 —Data Science / Machine Learning访问其他数据源 —和现有 Hadoop 数据联合查询多源异构交互式分析—复杂 SQL 查询的性能问题。于是 NewSQL 呼之欲出。要说 NewSQL 数据库我们要先从 Google 的 F1/Spanner 大规模分布式数据库说起。一、Google F1/Spanner和众多互联网公司一样在早期 Google 大量使用了 Mysql。Mysql 是单机的可以用 Master-Slave 来容错分区来扩展。但是需要大量的手工运维工作有很多的限制。因此 Google 开发了一个可容错可扩展的 RDBMS——F1。和一般的分布式数据库不同F1 对应 RDMS 应有的功能毫不妥协。起初 F1 是基于 MySQL 的不过会逐渐迁移到 Spanner。F1 有如下特点7×24 高可用。哪怕某一个数据中心停止运转仍然可用可以同时提供强一致性和弱一致可扩展支持 SQL事务提交延迟 50-100ms读延迟 5-10ms高吞吐。Spanner 是 Google 的全球级的分布式数据库(Globally-Distributed Database)。Spanner 的扩展性达到了令人咋舌的全球级可以扩展到数百万的机器数以百计的数据中心上万亿的行。更给力的是除了夸张的扩展性之外他还能同时通过同步复制和多版本来满足外部一致性可用性也是很好的。冲破 CAP 的枷锁在三者之间完美平衡。Spanner 是个可扩展、多版本、全球分布式还支持同步复制的数据库。他是 Google 的第一个可以全球扩展并且支持外部一致的事务。Spanner 能做到这些离不开一个用 GPS 和原子钟实现的时间 API。这个 API 能将数据中心之间的时间同步精确到 10ms 以内。因此有几个核心的功能无锁读事务原子 schema 修改读历史数据无 block。由于 F1/Spanner 并不开源通过现有公开资料仅仅只能窥得 F1/Spanner 的沧海一粟所以我们主要通过 Google 的公开资料的学习和发展自身这比拿来主义的 PostgreSQL 要难能可贵的多。二、F1 Query 对于 NewSQL 的奠基2018 年Google 发表了论文“F1 QueryDeclarative Querying at Scale”意味着对 F1/Spanner 架构的升级。解决了如下几个核心问题一是多种异构的存储平台Bigtable,Spanner,Google Spreadsheets 等共存二是不同存储平台上的计算不统一三是复杂的商业逻辑开始需要实时的分析和数据处理HTAP。于是 F1 数据库延伸成了这样一种数据库第一它是独立计算层底层对接了不同的数据源第二它试图统一 OLTP、OLAP 和 ETL 的 Workload第三它也是一个完整的 ETL 平台第四它推出了几种访问数据的新形式UDF、UDA 和 TVF SQL第五Shading-nothing这个之后会详细介绍。一种数据在完美融合 CAP 原理之后又破天荒的解决了同时支持 OLTP、OLAP、ETL 三种场景的数据库使用。可以说给我们带来了一片“新”天地因为开创了数据库的“新”纪元。这个“新”被 451 Group 的分析师 Matthew Aslett 命名为“NewSQL”。三、NoSQL 谢幕NewSQL 登场NewSQL 一词是由 451 Group 的分析师 Matthew Aslett 在研究论文中提出的。它代指对老牌数据库厂商做出挑战的一类新型数据库系统。NewSQL 是对各种新的可扩展/高性能数据库的简称这类数据库不仅具有 NoSQL 对海量数据的存储管理能力还保持了传统数据库支持 ACID 和 SQL 等特性。NewSQL 是指这样一类新式的关系型数据库管理系统针对 OLTP读-写工作负载追求提供和 NoSQL 系统相同的扩展性能且仍然保持 ACID 和 SQL 等特性scalable and ACID and (relational and/or sql -access)。NewSQL 一经问世发展至今已经形成一个庞大的技术 family 了通过上文我们可以知道NewSQL 的优势在于 SQL 的支持能力、扩展性、实时性和事务的处理能力。在 NewSQL 蓬勃发展的前提下许多新兴技术公司开始打造自己的新一代分布式数据库其设计理念一、分布式架构通过主节点下发任务的模式每个节点都可以提供服务在扩展性上Master 不会是瓶颈。客户端通过不同的接口访问形式直接访问主服务节点服务主服务节点收到服务请求进行分析处理分配到不同的分配服务节点执行分片服务节点收到执行请求进行 SQL 解析处理并执行 SQL 计划SQL 执行服务底层存储数据进行处理访问并反回处理结果通过 Raft 协议确保服务之间数据同步存储根据 AP、TP 分为共享存储和非共享存储。而与之相比较PostgreSQL 现在的分布式都是 MPP 的架构share nothing存在增加、减少节点数据重新分配的问题。二、从分库分表走向 Sharding 与 Partition分片与分区通过我们前面对 PostgreSQL 的解读数据分库分表是一种被迫的选择无奈之举如果能够不做分库分表就尽量不要做这方面的设计因为会对业务提出要求或者改动业务。所以我们在 NewSQL 的设计上要多做 Sharding 与 Partition分片与分区的设计。数据分区分区就是把一张表的数据分成 N 个区块在逻辑上看最终只是一张表但底层是由 N 个物理区块组成的。什么时候考虑使用分区呢当一张表的查询速度已经慢到影响使用的时候数据量大SQL 经过优化表中的数据是分段的或者对数据的操作往往只涉及一部分数据而不是所有的数据。分区解决的问题主要是可以提升查询效率。数据分片在分布式存储系统中数据需要分散存储在多台设备上数据分片Sharding就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的分布均匀即每台设备上的数据量要尽可能相近负载均衡即每台设备上的请求量要尽可能相近扩缩容时产生的数据迁移尽可能少。三、数据同步与一致性 —— Raft/Paxos目前主流的 NewSQL 数据库的数据同步是基于 Raft 协议的。在 Raft 中三种角色Leader负责接收客户端的请求将日志复制到其他节点并告知其他节点何时应用这些日志是安全的Candidate用于选举 Leader 的一种角色Follower负责响应来自 Leader 或者 Candidate 的请求。所有节点初始状态都是 Follower 角色超时时间内没有收到 Leader 的请求则转换为 Candidate 进行选举Candidate 收到大多数节点的选票则转换为 Leader发现 Leader 或者收到更高任期的请求则转换为 FollowerLeader 在收到更高任期的请求后转换为 Follower。Raft 状态机所有一致性算法都会涉及到状态机而状态机保证系统从一个一致的状态开始以相同的顺序执行一些列指令最终会达到另一个一致的状态。所有的节点以相同的顺序处理日志那么最终 x、y、z 的值在多个节点中都是一致的。在这一点上PostgreSQL-X2 的架构是以主备的模式来确定的。四、分布式事务事务开始记录事务唯一 ID执行操作记录修改的 shard执行预提交动作提交或回滚写入时当前采用锁机制读取使用快照读取存储层每次写入都是追加写入通过覆盖机制进行数据变更。这样的好处是数据的鲜活性可以实时保证数据更新插入和分析可以一起完成像实时数仓、实时统计汇总计算就能够实现了。而在 PostgreSQL 的 OLAP 虽然可以通过批量或者插入的方式实现更新但要人工做优化持续投入人力干预性能被动式保证。五、存储层——KV 存储在存储方面我们有两种选择堆存数据可以通过 key 获取同时可以直接读取数据非堆存数据只能通过 key 来获取无法直接读取到数据。非堆存储只能通过 key 来获取数据会导致不断的离散的读取所以不能适应于 AP 的场景。客户端通过不同的接口访问形式直接访问主服务节点服务主服务节点收到服务请求进行分析处理分配到不同的分配服务节点执行分片服务节点收到执行请求进行 sql 解析处理并执行 SQL 计划SQL 执行服务底层存储数据进行处理访问并反回处理结果Zookeeper 保证相关服务应用的高可用HDFS 持久化底层存储数据并利用三副本技术保证数据不丢失。与之相比较PostgreSQL 是本地化存储存储也可以分为列存和行存等。六、多源异构与数据邦联NewSQL 的数据多源异构要兼顾考虑对过去数据库的全面支持尤其是 NoSQL 和 Hadoop 生态体系因为毕竟这两者已经非常普及。在多源异构方面PostgreSQL 是通过 FDW 支持多源异构可访问 Oracle、PG、MySQL、MongoDB 等对 Hadoop 体系和 NoSQL 支持力度低效率和性能也较难做到极致。七、基于 NewSQL 的分布式数据库实践综合以上六点通过对 NewSQL 的分布式架构数据的分区分片数据同步与一致性分布式事务存储层KV 存储设计数据库多源异构。我们综合设计研发推出了一款自主可控的国产分布式数据库 —— Hubble。Hubble 同时支持 OLTP 和 OLAP 场景即在同一份数据上实现事务型处理的同时支持实时分析省去了费时的 ETL 过程。最后将 Hubble 作为代表与 PsostgreSQL-X2 做一个横向分析能够帮助我们更好地理解本文开篇所言 —— 分布式数据库的两支牛角各自的技术路线。作者简介张秋剑天云数据上海分公司副总经理资深金融行业大数据技术架构专家。计算机科学技术硕士学位后曾就职于 IBM 等公司九三学社金融委员会委员。目前主要为银行、证券和保险等金融行业客户提供大数据平台及人工智能平台的规划和方案设计工作。曾在 IEEE 等期刊发表多篇论文。推荐阅读一文带你认识keepalived再带你通关LVSKeepalived那个分分钟处理 10 亿节点图计算的 Plato现在怎么样了“谷歌杀手”发明者科学天才 Wolfram数据库激荡 40 年深入解析 PostgreSQL、NewSQL 演进历程超详细一文告诉你 SparkStreaming 如何整合 Kafka 附代码可实践5分钟就能学会以太坊 JSON API 基础知识真香朕在看了
