POLARDB背景
POLARDB是阿里云自主研发的，具有里程碑意义的新一代关系型数据库，是与MySQL完全兼容的云托管数据库产品。它秉承Cloud Native的原生设计理念，采用了分布式存储引擎设计，性能最高可达到MySQL的6倍。在提供高吞吐、低延迟OLTP服务的同时，POLARDB以更低的使用成本，为用户提供更好的系统在线扩展服务。
—摘自POLARDB产品介绍文档
架构
架构的设计特点：
- 一写多读
- 计算与存储分离
- 读写分离
- 高速链路互联
- 共享分布式存储
- 数据多副本、支持Parallel-Raft协议
思考：POLARDB是阿里的技术体系演变过程中的一个优秀的产品，它的强大之处在于：将大规模数据的存储、同步和性能等难点，通过POLARDB的架构设计，将这些复杂的问题变得透明，让技术人员专注在业务的开发上。
体验POLARDB
- 依次打开
产品与服务—云数据库 POLARDB
- 选择你所需要的配置
有预付费和按量付费，可以根据你的业务需求来具体选择。如果你的业务场景的用量比较稳定，可以选择预付费，如果有弹性扩容的需求，可以选择按量付费。
- 实例概要
POLARDB采用分布式集群架构，一个集群包含一个主实例和最多15个只读实例（确保高可用）。读写分离数据库接入功能，是POLARDB集群默认免费提供的一个透明、高可用、自适应的负载均衡能力。本次创建包含了一个主实例（负责读写）和一个只读实例（负责读）。
- 实例详细信息
- 集群概要
- 集群详细信息
- 创建账号
POLARDB初始账号只能在集群详情页设置，可用于登录到集群中的任意实例。
- 连接实例
VPC（Virtual Private Cloud）：可以理解成内网，如果是从阿里的ECS连过来的，推荐使用VPC。注意：这个地址是自动生成的，且无法释放。
我们现在演示通过VPC和公网来连接POLARDB实例：
- VPC网络
若使用ECS，推荐该种方式
实例地址：pc-xxxxxxxxx.mysql.polardb.rds.aliyuncs.com:3306（xxxxxxxxx为你的实例配置id）
端口：3306（默认，检查下ECS的防火墙配置是否开放了3306端口）
账号：byronzoz
密码：xxxxxx
通过阿里云的RDS界面登录：
优点：通过阿里云的RDS来登录，这种方式最简单，不需要安装任何客户端。
通过阿里云的ECS直连：
[byron@yanglaomap-prod ~]$ mysql -u byronzoz@pi-xxxxxx-pi-xxxxxx.mysql.polardb.rds.aliyuncs.com:3306
这种方式通过命令来直连，跟mysql操作没啥区别。
- 公网
实例地址：byronzoz-0.mysql.polardb.rds.aliyuncs.com
端口：3306
账号：byronzoz
密码：xxxxxx
本次测试，我们用navicat客户端来连接，当然你可以采用mysql自带的client也是OK的。
提示：公网需要加入到白名单中，不然连接不过去，如我的公网IP为：171.221.xxx.xxx，这也是我踩过的坑~
- 建表玩转业务
各位看官们，这一块该你们发挥了...
总结
通过本文的简单介绍，你对POLARDB有一个初步的认识：
- POLARDB是可以100%兼容mysql
- POLARDB的架构设计
- 如何购买POLARDB产品
- 创建实例
- 创建账号
- 演示两种连接：VPC（通过阿里云RDS页面和ECS服务器）和公网（Navicat客户端）来连接实例
POLARDB作为阿里云体系下的一个新成员，能与阿里云的产品迅速融合起来，包括网络（VPC）、云服务器（ECS）、云数据库（RDS）等，使用起来很方便，如果你是一个mysql老手，那你用POLARDB是可以非常快上手的，如果你是一个新手，按照教程step by step，也可以快速上手。
POLARDB创新的架构设计，拥有很多是mysql数据库所不具备的或者需要花费很大精力才能具备的能力。如POLARDB创建实例后就默认具备了主从的多个实例，这些特性可以让开发人员专注业务上的实现，而不用关注数据库的水平扩展、存储、网络等耗费精力的事情。
当然，也有一些不足的地方：
- 白名单列表，公网连接下，需要设置白名单。这个有点繁琐，期望这个功能能进一步改进。如通过策略组的方式，而不是每个集群都配置一组白名单。
- 不能访问用户表。这个似乎限制了数据库的功能。
- 文档。很多开发者吐槽阿里云的技术文档（orz…）：不规范更新慢，这个跟高大上的阿里云有点不匹配。期待未来的阿里云所有的云产品文档都是统一的格式/模板，这样阅读起来要更加容易些，而且建议要同步上英文文档（English Docs），毕竟已经走到国际化的道路上了。
有人会问了：我购买的ECS上面也能安装mysql，为什么要单独选择POLARDB？
原因很简单，你需要花费很长的时间和精力去做以下事情：
- 数据库网络和节点管理
- 主从配置
- 读写分离
- 数据库扩容
- 性能方面
- 数据容灾
- ……
你花费的这些时间，POLARDB帮你节省掉，你只需要将大部分精力专注在业务开发上。
未来，期待POLARDB带来更多的惊喜~
POLARDB for MySQL 版评测及同类横向对比
摘要： 根据云栖社区《2017中国开发者调查报告》我们可以了解到在全球范围内特别是国内 MySQL 都有着非常高的使用率，有大量的产品和项目是依赖于 MySQL 作为关系型数据库的，因此在 MySQL 上进行进一步的优化和改造是大有可为的，于是便有了 MySQL 的衍生版包括有：MariaDB、Percona、AliSQL、PhxSQL 等等，但 MySQL 本身其实是一款“轻量级”数据库，相较 SQL Server 和 Oracle 等商业数据库其实是有所不足的。
前言
在数据库的选择上, MySQL成为中国开发者的最爱。相比 SQL Server相对保守的数据库特点,中国开发者更喜欢开放性的数据库,同时又考虑到价格问题,那么 Oracle不菲的价格也挡住了很大一批开发者。由于开源、价格等因素,在数据库选择上,要么是低价、开源的 MySQL,要么就是高大上的 Oracle。 —— 云栖社区《2017中国开发者调查报告》
根据云栖社区《2017中国开发者调查报告》我们可以了解到在全球范围内特别是国内 MySQL 都有着非常高的使用率，有大量的产品和项目是依赖于 MySQL 作为关系型数据库的，因此在 MySQL 上进行进一步的优化和改造是大有可为的，于是便有了 MySQL 的衍生版包括有：MariaDB、Percona、AliSQL、PhxSQL 等等，但 MySQL 本身其实是一款“轻量级”数据库，相较 SQL Server 和 Oracle 等商业数据库其实是有所不足的。因此各类兼容 MySQL 生态的新型数据库开始出现。
2017年是各类新型数据库的落地年，各种NewSQL纷纷结束蛰伏期并开始商业化输出，特别是各类基于 MySQL 生态和兼容 MySQL 协议的新数据库产品也开始不断发展并开始商业输出，有包括在 OLTP 上进一步优化的 POLARDB、Aurora、X-DB等等，还有兼容 OLTP 和 OLAP 场景的 HTAP 上优化的 HybridDB、TiDB、BaikalDB 等等。
本文要将的主角是 —— POLARDB ，POLARDB 是在2017年9月发布并进入公测阶段的，并在18年4月结束公测正式进入商业阶段并不断发布新功能完善体验。值得一提的是同样也在17年10月腾讯云联合 PingCAP 发布基于 TiDB 的 HTAP 数据库，但截至发文依旧停留在测试阶段。
介绍
POLARDB 是阿里云自研的全新一代云数据库，与 MySQL 100%兼容，性能最高提升至MySQL的6倍，满足企业级OLTP（在线事务处理）并兼顾结构化数据并发查询场景。既融合了商业数据库稳定可靠、高性能、可扩展的特征，又具有开源数据库简洁开放的优势，而成本只有商用数据库的 1/10。POLARDB采用存储和计算分离架构，能提供存储自动扩容、计算规格弹性升降、故障快速恢复和数据备份容灾服务。
POLARDB 对 MySQL 进行了一定改造，MySQL 其实至发布以来就是基于单机开发的数据库，但是单机单节点势必是会遭遇性能瓶颈。于是乎，对于 MySQL 有了两个方向的改造。
一种是读写分离方案，因为在很多网站常见下其实大家走的读请求更多，就女士逛淘宝，看了非常多的商品可能才下那么一单甚至单都不下就添加了一个收藏。
痛点举例
再介绍 POLARDB 的优越性之前，我们先看看已经是使用体验业内顶尖了的云数据库 MySQL 的一些痛点（友商的其他竞品痛点可能会更多~）：
一、 当数据存储容量足够大的时候，备份成为了一件非常复杂的事情，费时费力。
二、 主备模式下，如果主库不出现问题并不会切换到备库，备库仅仅起到了一个以防万一的作用平时并不能分担压力，但是却不得不承担备库部分的成本。
三、 在读写分离场下，每添加一个只读库基本上就得购买一个一模一样的存储空间，如果是一个1T的主库，那么两个只读库的成本就是2个1T。
四、 还是读写分离场景，一个上TB的数据库容量加个只读副本就需要一到两天时间，非常的麻烦。
五、 传统模式下为了保障数据库不会到达 100% 都会预留10%~20% 的容量作为阈值，到了 80% 就进行升级或者扩容，其实这个时候那个预留的阈值是浪费了的，但是又不得不浪费。
六、 存储容量瓶颈，云计算厂商提供的关系型数据库基本上都有一个问题，那就是存储容量存在瓶颈，当数据量达到 2T 左右的时候就已经是瓶颈了无法进一步上升，而部分数据库应用场景恰恰就是需要大容量大存储的。
七、 性能瓶颈，当使用数据库遭遇性能瓶颈的时候其实是很糟心的，如果是能通过升级配置解决的那倒还行，如果是因为数据库软件本身的问题而更换数据库软件又意味着更高额的成本和风险。
产品特性
那么接下来介绍 POLARDB 的产品特性大家就会觉得舒服的多。
快照式备份
POLARDB 采用快照（Snapshot）形式的备份模式，并不是说将数据完完整整的备份一份，而是把备份数据的负载均分到创建Snapshot之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。
Snapshot是一种流行的基于存储块设备的备份方案。其本质是采用Copy-On-Write的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据的目的。Snapshot是一个典型的基于时间以及写负载模型的后置处理机制。
POLARDB提供基于Snapshot以及Redo log的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合Binlog增量数据的恢复方式更加高效。
实测的话，POLARDB 的备份在分钟级，两三分钟就可以实现备份，相比云数据库小时级的等待可以说是体验非常棒了。在备份恢复的体验上 POLARDB 基本上和云数据库体验一致，按备份集和按时间点或者实例备份都可以
FailOver 多活
POLARDB 默认购买就是一个主实例+只读实例形成 Active-Active 模式，其 FailOver 多活机制 可以在主实例宕机后立马选择一个只读实例“赋予”其读写能力，成为一个新的主实例。这样的模式下每一个只读实例都是“备库”，但是这个备库是参与工作的，并不存在浪费的现象。
得益于数据共享（后面会提到）的模式，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和 Redo log，只需要同步元数据信息，支持基本的 MVCC，保证数据读取的一致性即可。这使得系统在主节点发生故障进行 Failover 时候，切换到只读节点的故障恢复时间能缩短到 30 秒以内。
分布式共享存储架构
POLARDB使用了第三代分布式共享存储架构，实现了计算节点(主要做SQL解析以及存储引擎计算的服务器)与存储节点(主要做数据块存储，数据库快照的服务器)的分离，提供了即时生效的可扩展能力和运维能力。
由上图我们可以看到，POLARDB通过将数据库文件以及 Redolog 等存放在共享存储设备（POLATSTORE）上而不是一个库一个本地存储。由于数据共享，只读实例的添加就再也不需要对数据进行完全复制了，而是共用一份全量数据和 Redo log，只需要同步元数据信息，这使得系统在主节点发生故障进行Failover时候，切换到只读节点的故障恢复时间能缩短到30秒以内（有没有发现这一句话FailOver那边提过）。系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级别。
存储费用按量付费
POLARDB 的存储计费是按量付费的模式，也就是用多少扣多少，而不是预付费的模式。 云计算方法论中很重要的两点就是 弹性和按量 。相对于 ECS 集群的后付费和流量的按量后付费，数据库的按量后付费其实更可控和可预估，并不会出现天价费用，而且在数据库容量的扩容上用户也的确会遇到不好的体验（痛点那里有提到）。
所以用户会很愿意接受 POLARDB 的按量付费模式。再也不需要为那10%的扩容阈值浪费成本了。
大容量存储
POLARDB 支持高达 100TB 的存储容量，是云数据库 2T 容量上限的 50 倍。如果数据库的使用场景中的确需要超大存储再也无须担心了。
超高性能
POLARDB 作为一款 云原生 的数据库，在软件设计、产品架构、基础设施上都是顶尖的（如果用最顶尖的可能会违反广告法~）。 在性能上 POLARDB 远超 MySQL ，在特殊场景下最高可以实现6倍于 MySQL。
软件设计上的删繁就简，仅能更进一步。 下面那张图上门出现过，可以看到传统的MySQL下读写分离其实非常的繁琐，而且要写入大量的逻辑日志。POLARDB 在 MySQL 上进行了大量的修改包括有：使用共享存储物理复制、锁优化、日志提交优化、复制性能优化、读节点性能 等等。 同时 POLARDB 是基于 Docker 来隔离资源的，免去了一次虚拟化带来不必要的性能损耗。
超规格底层硬件提供更高性能。3D Xpoint、NVMe、RDMA网卡这些名词都是在极客玩家中经常有听到的，它们都意味着超高的性能，同时也意味着高昂的价格。前文中有提到的 POLARSTORE 存储，就是基于这些极致的硬件设备而来的，但是阿里云将他们集成到 POLARSTORE 并以云计算的形式普惠输出，让大家可以用低廉的价格享受最前沿的技术和产品。
软硬件一体化设计，但是软件、硬件单方面的提升都无法成就 600% 于 MySQL 的性能表现，POLARDB 将全新的软件针对最酷的硬件进行优化实现软硬件一体，所以也是非常推荐大家可以阅读一下关于 PolarFS VLDB2018 的 Paper。 我是传送门
（猜测）未来的 多主进群（Multi-Master） 机制，这个纯属我瞎猜，但是 POLARDB 大概率是会做的，那就是在多个可用区中创建多个读取主实例。这样一来，应用程序就可以在集群的多个数据库实例中读取和写入数据，极大的扩展分布式写的性能，这简直就是抢 DRDS 的饭碗嘛！ 多主集群还会进一步提高高可用性，如果其中的一个主实例发生故障，集群中的其他实例将立即接替该实例，从而在发生实例故障甚至完全 AZ 故障时保持读写可用性，应该是可以做到将应用程序停机时间降到零。
100% MySQL 兼容
POLARDB 针对 MySQL 生态 100% 兼容。 为什么这个都要拿出来说呢？ 举两个例子：
一是在本文的第一张图中可以看到 Oracle 在中国有不小的份额并占据第二的位置，为什么？根据我对客户上云的一些经验来看，使用 Oracle 的客户大多都是政企客户，系统依赖 Oracle 有历史包袱，贸然迁出要面临不小的工作量而且出问题了势必会背锅，所以尽管有什么高度兼容 Oracle 的方案，95%也好 99% 也好，势必意味着不可预知的风险。
二是像谷歌的 CLOUD SPANNER 就不兼容已有的数据库生态，这就导致用户必须针对其全新开发而且未来势必对GCP有非常强的依赖，难以脱身。
因此 POLARDB 的 100% 兼容 MySQL 生态绝对是一大特性，让客户可以无痛的就使用高性能的数据库产品来解决现有遭遇的数据库性能、功能瓶颈或者说是使用期新特性来提高业务可靠性和稳定性。
混淆OLTP和OLAP
POLARDB 的百TB级的存储和高规格软硬件带来的低延时一定程度上模糊了 OLTP 和 OLAP 的边界，在追求数据量实时性的场景下可以更好的进行 OLAP 分析，而避免要将数据库放到数仓然后再进行 OLAP 分析。
性能测试
这里使用 SysBench 1.0.15 进行小规格版本的测试。
测试准备
ECS 自建： 自建 MariaDB 10.1 （基于 MySQL 5.6）， 底层服务器：计算型C5 2C4G 150G
SSD云盘
RDS 主实例： 云数据库 MySQL 版 5.6 高可用，2C4G 版
RDS 读写分离： 云数据库 MySQL 版 5.6 高可用，2C4G 版，主实例 + 1个 只读实例
POLARDB 主实例： POLARDB 2C4G ，主实例，不使用只读实例
POLARDB 读写分离： POLARDB 2C4G ，主实例 + 1个只读实例
由于 ECS 自建读写分离场景太费时费力了，就不创建了。
测试命令
测试结果
SysBench 读场景结果（越大越好）
SysBench 写场景结果（越大越好）
SysBench 超过95%平均耗时场景结果（越小越好）
