今日这一讲，我会把视角切换到产品方向，为你做一次全体介绍。当然关于具体特性，这儿我不再重复，而是会给出前面课程的索引。所以，你也能够将这一讲当作一个产品版的课程索引，让你在二刷这门课程时有一个簇新的视角。

  分布式数据库产品，从架构风格上能够分为PGXC和NewSQL这两个大类，以及别的一些小众些的产品。

  已然要说分布式数据库产品，第一个有必要是Google的Spanner。严厉来说，是Spanner和F1一同创始了NewSQL风格，它是这一门户名副其实的开山鼻祖。

  其间F1首要作为SQL引擎，而业务一致性、仿制机制、可扩展存储等特性都是由Spanner完结的，所以咱们有时会疏忽F1，而更多地说到Spanner。

  Spanner架构中的中心处理模块是Spanserver，下面是它的架构图。

  在第5和解第12讲，咱们还介绍了根据大局时钟的数据一致性办理机制和处理时刻误差的“写等候机制”。

  咱们都知道，软件架构会跟着业务开展而演进，2017年，Google又宣布了两篇新论文，介绍了Spanner和F1的最新改变。它们从本来的“金牌组合”走向了“单飞”形式。

  这篇论文用许多篇幅介绍了SQL处理机制，一起在系统定位上比较2012版有一个大的改变，着重了兼容OLTP和OLAP，也便是HTAP。

  对应的，Spanner在存储层的规划也从2012版中的CFS切换到了Ressi。Ressi是类似PAX的队伍混合数据布局（Data Layout），咱们在第18讲专门谈了对HTAP未来开展的观点，并对各种不同的数据布局进行了剖析。

  这个架构中还有一个咱们很感兴趣的点，便是F1经过UDF Server来完成存储进程的支撑。咱们在第16讲中对此进行了简略的讨论。

  尤其是CockroachDB和TiDB，常常会被咱们拿来比较。可是，从系统架构上看，这两个产品有十分大的不同。让咱们先从CockroachDB视点来总结下。

  最大的不同来自架构的全体风格。CockroachDB选用了规范的P2P架构，这是一个十分极客的规划。只需P2P架构能够做到肯定的无中心，这意味着只需损坏的节点不超越总数一半，那么集群就依然能够正常作业。因而，CockroachDB具有超强的生存能力，而这也很契合产品名称的语义。

  第二个重要差异是全球化布置。CockroachDB选用了混合逻辑时钟（HLC），所以能够在全球物理范围下做到数据一致性。这一点对标了Spanner的特性，不同之处是Spanner的TrueTime是依靠硬件的，而HLC机制彻底根据软件完成。

  第三个点则是分片办理机制的不同。由于全体架构的差异，CockroachDB在分片办理上也跟TiDB有显着的差异。

  别的，我还在第10讲介绍了CockroachDB的2PC优化，第11讲介绍了CockroachDB的读写阻隔战略，第12讲介绍了如何用读等候方法处理时刻误差问题。

  TiDB也是对标Spanner的NewSQL数据库，由于开源的运转方法和杰出的社区运营，它在工程师集体中具有很高的人气。

  不同于CockroachDB的P2P架构，TiDB选用了分层架构，由TiDB、TiKV和PD三类人物节点构成，TiKV作为底层分布式键值存储，TiDB作为SQL引擎，PD承当元数据办理和大局时钟的责任。

  与Spanner不同的是，底层存储TiKV并不能独立支撑业务，而是经过TiDB和谐完成，业务操控模型选用了Percolator。咱们在第9和解第13讲介绍了TiDB的业务模型。

  作为与CockroachDB的另一个显着差异，TiDB愈加坚决的走向HTAP，在原有架构上拓宽TiSpark和TiFlash，在第18讲咱们介绍了这部分的规划。

  一起，TiDB关于周边生态东西建造投入了许多资源，由此诞生了一些衍生项目：

  - Ti-Binlog和Ti-CDC能够将数据导出，构建逃生通道或许完成数据剖析。

  第25、26和27讲的内容与上述项目具有直接对应联系。这些项目的创建，丰厚了TiDB的服务交给方法，也使TiDB的产品线变得更长。但它们是否都有很好的开展前景，还有待调查。

  当然，TiDB架构也存在一些显着的缺点，比方不支撑全球化布置，这为跨地域大规划集群运用TiDB设置了妨碍。

  SIGMOD和VLDB是数据库范畴公认的两大顶会，而TiDB和CockroachDB先后宣布产品论文，颇有一时瑜亮的感觉。

  YugabyteDB是较晚推出的NewSQL数据库，在架构上和CockroachDB有许多类似之处，比方支撑全球化布置，选用混合逻辑时钟（HLC），根据Percolator的业务模型，兼容PostgreSQL协议。所以，课程中对CockroachDB的介绍会协助你快速了解YugabyteDB。

  为数不多的差异是，YugabyteDB挑选直接复用PostgreSQL的部分代码，所以它的语法兼容性更好。可能是由于高度的类似性，YugabyteDB与CockroachDB的竞赛体现得愈加剧烈。

  YugabyteDB首先抛出了产品比对测验，证明自己处理功用全面抢先，这引发了CockroachDB的反击，随后两边不断回应。咱们在第17讲引用了这场论争中的部分内容。假如你想了解更多内容能够检查相关博客。

  从历史沿革看，OceanBase诞生的时刻能够追溯到2010年，可是那时产品形状是KV存储，直到在1.0版别后才确立了现在的产品架构。OceanBase大体上也是P2P架构，但会多出一个Proxy层。

  由于OceanBase是一款商业软件，所以对外宣布的信息比较有限，咱们的课程中在并行履行结构、查询引擎和存储模型三部分对OceanBase做了一些介绍，别离对应第20讲、第21和解第22讲。等待OceanBase团队能够放出更多有价值的材料。

  PGXC运用单体数据库作为数据节点，在架构上的立异远少于NewSQL，所以咱们在课程内容上所占篇幅也较少，而且是作为一个全体风格进行介绍。

  在第3讲，咱们从单体数据库的阻隔等级引申到PGXC的阻隔性协议。第4讲，咱们具体拆解了PGXC的架构，也便是和谐节点、数据节点、大局时钟和元数据办理等四个部分。第6讲，咱们介绍了PGXC的分片机制。

  还有一些特性，例如数据仿制是承继自单体数据库。事实上，有关单体数据库完成的阐明都对了解PGXC有所协助。

  TBase是最规范的PGXC，选用PostgreSQL作为数据节点。但TBase推出的时刻较晚，运用事例也相对较少。

  从一些宣扬材料看，TBase愈加着重HTAP的特色。但考虑到TBase与TDSQL都是腾讯出品，我以为这或许是出于商业战略的考虑，究竟从架构自身看，TBase与TDSQL的差异是比较有限的。

  TDSQL是腾讯公司内部最早的分布式数据库，它的数据节点挑选了MySQL。我从前说到过，TDSQL现在的主推版别并没有完成大局时钟，这意味着它在数据一致性上是存在缺失的。

  所以严厉含义上说，它并不是分布式数据库，当然咱们也能够经过一些揭露信息了解到TDSQL在一致性方面的尽力，信任完善这部分功用应该仅仅时刻问题。

  GoldenDB几乎是国内银行业运用规划最大的分布式数据库，和TDSQL同样在数据节点上挑选了MySQL，但大局时钟节点的添加使它称为一个规范的PGXC架构。

  GoldenDB对业务模型进行了改造，咱们第9讲介绍了它的分布式业务模型“一阶段提交”。

  分库分表计划是一个长时间盛行的计划，有各种同质化产品，所以进一步演化出多少种PGXC风格的数据库很难历数清楚。

  凭借单体数据库的优势，无疑会开展的愈加方便，但一直存在一个危险。那便是单体数据库的许可证问题，尤其是那些挑选MySQL作为数据节点的商业数据库。

  MySQL选用的GPL协议，这意味着不允许修改后和衍生的代码作为商业化软件发布和出售，乃至是只需选用了开源软件的接口和库都有必要敞开源码，否则将面临很大的法令危险。

  除了以上两种干流分布式数据库外，还有一些小众产品。尽管它们的运用不那么广泛也，但也很有特色。

  VoltDB一度也是开源数据库，但在2019年正式闭源，变为纯商业化产品。而一起，VoltDB在国内也没有树立齐备的服务支撑系统，这在很大程度上影响到它的推行。

  别的，VoltDB尽管支撑OLTP场景，但在国内的落地项目中多用于实时剖析场景，例如金融反诈骗等。

  VoltDB的首要特色是彻底根据内存的分布式数据库，运用存储进程封装业务逻辑，选用单线程方法简化了业务模型。咱们在第16讲对VoltDB做了简略介绍。

  巨杉数据库（SquoiadDB）在前期并不支撑完好业务，所以运用场景首要是归档数据和印象数据存储，然后从3.0版别开端逐步过渡到完好的OLTP分布式数据库。咱们在第4讲介绍了巨杉的大局时钟完成方法，便是它在完善业务一致性方面的重大进展。

  巨杉的架构其实跟MySQL架构十分类似，也分为SQL引擎和存储引擎上下两层。巨杉在上层直接复用了MySQL的SQL引擎，基层则运用自己的分布式存储引擎替换了InnoDB。

  这种架构规划意味着巨杉能够十分好地兼容MySQL语法，就像YugabyteDB兼容PostgreSQL那样。

  巨杉支撑的还不只MySQL，事实上它现已逐步开展为一款多模数据库，一起兼容MySQL、PostgreSQL、SparkSQL，并支撑Json类型数据部分兼容MongoDB，和S3目标存储等。

  1. 2012年Google宣布的两篇论文奠定了Spanner/F1作为NewSQL数据库开山鼻祖的位置。由于其间存储引擎、仿制机制、分布式业务都在Spanner中完成，所以咱们有时会省略F1。然后，Spanner演进为一个自带SQL引擎的完好数据库，而且一起统筹OLAP和OLTP场景。

  2. CockroachDB与TiDB都是Github上十分抢手的项目，规划创意均来自Spanner。尽管两者在部分规划上选用了相同的战略，例如引进RocksDB、支撑Raft协议等，但在许多重要特性上仍有很大距离，例如全球化布置、时钟机制、分片办理、HTAP支撑程度等。

  3. YugabyteDB与CockroachDB具有更大的类似性，导致两者间的竞赛愈加剧烈。OceanBase作为阿里的一款自研软件，全体风格上接近于NewSQL，所以许多规划在原理上彻底相同的。但由于商用软件的联系，敞开的材料上远少于其他NewSQL数据库。

  4. PGXC数据库是从分库分表计划上开展而来，而这一步跨过的要害便是经过大局时钟支撑更严厉的数据一致性和业务一致性。PGXC具有架构安稳的优势，往往被视为更保险的计划，但单体数据库的软件许可证一直是PGXC架构商业数据库一个很大的法令危险。

  5. VoltDB和巨杉数据库是小众一些的数据库，在规划上选用了较为共同的方法，然后也带来了差异化的特性。

  假如你身边的朋友想快速了解分布式数据库都有哪些产品，也能够把这篇内容共享给他，信任会帮他更高效地确定产品。