https://baijiahao.baidu.com/s?id=1610828839695075926&wfr=spider&for=pc
序文
データベースの選択では、MySQLは好きな中国の開発者になっています。口座に代金を取って、そしてお金オラクルの価格も多くの開発者をブロックしながら、中国の開発者の特性に比べて比較的保守的SQLServerデータベースは、開いているデータベースを好みます。オープンソース、価格やその他の要因、データベース選択で、低コスト、オープンソースのMySQL、Oracleまたは背が高い上にあるためか。 - Yunqiコミュニティ「2017中国の開発者が報告します」
Yunqiコミュニティによるので、我々は国内のMySQLが非常に高い利用率、製品やプロジェクトの多くは、リレーショナルデータベースとしてMySQLに依存しているがあり、特に中に、地球規模で学ぶことができる「2017年中国の開発者が報告します」 MariaDB、Percona、AliSQL、PhxSQLをなどが、MySQL自体はSQLに比べ、実際には「軽量」データベースです：さらなる最適化と変換は、MySQL上で期待されているので、MySQLのの派生バージョンがあるでしょうが含まServerとOracleのデータベース事業は、実際にはやや不十分です。だから、新しいエコ互換のMySQLデータベースのすべての種類が始まりました。
2017年には、新しいデータベースの様々なタイプの着陸は、様々なNewSQLは休眠期間を終了し、新製品開発のMySQLのベースエコ互換とMySQLデータベースプロトコルの商用出力、特に様々なタイプを始めとも含め、商用出力を開始し始めてきていますようにさらに等OLTP POLARDB、オーロラ、X-DB、に最適化、ならびに上の互換OLTP及びOLAPシーンHTAP HybridDB、TiDB、BaikalDBの最適化。
この記事の主人公に - POLARDB、POLARDBは正式に商用段階に入って体験を改善するための新機能をリリースし続けて2017年9月にリリースし、ベータ版の段階に入って、ベータ版では4月18日に終了しました。同じことが10月17日HTAPデータベースの共同テンセントクラウドベースTiDB PingCAPリリースにもあることを言及する価値があるが、投稿のようまだテスト段階にとどまります。
入門
MySQLの100％、最大6倍のMySQL、エンタープライズクラスのOLTP（オンライントランザクション処理）構造化データと同時クエリシーンの両方の最高のパフォーマンスと互換性のあるクラウドデータベースの新世代のPOLARDBアリクラウド自己啓発、。これは、両方の商用データベース安定性と信頼性、高性能、拡張性の高い機能を組み合わせた、だけでなく、シンプルなオープン、オープンソースデータベースの利点を持っている、とだけ1/10商用データベースのコストです。自動ストレージ拡張、リフトを計算するための弾性仕様、高速な障害復旧やデータのバックアップ、ディザスタリカバリサービスを提供して別のストレージおよびコンピューティングアーキテクチャを使用してPOLARDB。
MySQLののPOLARDBは、実際には、その打ち上げにMySQLデータベースをスタンドアロンの開発に基づいており、特定の変換されていますが、スタンドアローンの単一ノードは、パフォーマンスのボトルネックが発生したためにバインドされています。以来、両方の方向に転換してMySQLの。
実際の多くの一般的なサイトでは、我々は氏淘宝網のショッピングの詳細を行くための要求を読んでいるので一つは、分離スキームを読み書きすることで、商品の多くはそうではないとしても、単一の場合は、コレクションを追加しますつだけの場合もありました。
例の痛みポイントの場合
前POLARDB再導入の利点に、我々は業界トップのクラウドデータベースのMySQLの経験、いくつかの痛みの点で最初に見て（痛みのポイント他の競合製品は、より多くのメーカーの〜かもしれません）：
データ記憶容量が十分に大きい場合まず、バックアップは非常に複雑な問題で、時間と労力になります。
第二に、スタンバイモードでは、何の問題は、プライマリ・データベースがスタンバイ・データベースに切り替えない場合、ライブラリは通常、圧力を共有していない場合の役割を果たしただけに調製発生しませんが、ライブラリによって一部の費用を負担しなければなりません。
それは、一次ライブラリーの1Tである2つの読み取り専用ライブラリのコストは2 1Tであれば三、別々の読み取りおよびフィールドで書くには、読み取り専用のライブラリーは、それぞれが、実質的に同一の後の収納スペースを持って追加します。
四、またはTBデータベースの容量に加えて、読み取り専用のコピーで、分離シーンを読み書きするには非常に面倒、1〜2日かかります。
第五に、実際には、この時間は、予約のしきい値が浪費され、アップグレードまたは拡張の80％を閾値としてはさておき、10％〜20％の容量を設定します100％に到達しないだろう、データベースを保護するために、伝統的なモード、それを私は無駄にしました。
第六に、ストレージ容量のボトルネック、リレーショナルデータベースのクラウドコンピューティングベンダーは、いくつかのデータベースアプリケーションのシナリオは、それがさらに増加することができないボトルネックがすでにあるときにデータが2T程度に達したときに、記憶容量のボトルネックは、基本的な問題であり、正確には大きなマスストレージを必要とします。
七、パフォーマンスのボトルネック問題は、データベースソフトウェア自体ためであれば、それは、ラインに来てアップグレード構成によって解決されている場合、実際に、それは、悪い心である場合に遭遇するデータベースのパフォーマンスのボトルネックを使用して、順番にデータベースソフトウェアを交換することは、より高い意味コストとリスクの量。
製品の特徴
その後、次の導入POLARDB製品は、誰もがより快適になりますます。
スナップショットバックアップ
バックアップモードの形でスナップショット（スナップショット）を使用してPOLARDBは、そのデータそのままバックアップコピーを意味するものではありませんが、バックアップを実現するために、ウィンドウのスナップショットの作成が発生した書き込み時間後に実際のデータへの負荷のバックアップデータを共有します、迅速な対応を回復。
スナップショットは、ブロックに基づいた人気のバックアッププログラム記憶装置です。その本質は、機構の使用は、コピー・オン・ライトのメタデータの変更記録ブロックデバイスにより、書き込みブロックデバイスの書き込み動作に敬意をコピーする場合に発生し、新しく回復を達成するために出てコピーされたブロックデバイスへのコンテンツの変更の書き込み動作データの目的の時のスナップショットでポイントに。スナップショットは、典型的な時間ベースとポスト処理機構は、負荷モデルを書いています。スナップショットとはPOLARDB結合データの従来の全容積よりも増分データ復元BINLOGより効率的なスケジュール機能、に応じて復元されたユーザデータにREDOログ・ベースの機構を提供します。
クラウドデータベース時間待ちのレベルと比較して測定した言葉、レベルのPOLARDBバックアップ分のバックアップに二、三分は、素晴らしい経験であると言うことができます。バックアップおよびリカバリ経験POLARDBクラウドデータベース経験実質的に均一に、およびバックアップによっては、スケジュール又はバックアップインスタンスに応じて設定することができます
フェールオーバーの多活
POLARDBは、フェールオーバーがすぐに「与えられた」インスタンス下で読み取り専用のプライマリインスタンスを選択生きることができるメカニズムアクティブ - アクティブモードに形成され、後に読み取り専用インスタンス+たとえば、デフォルトのマスターで読み、新しいプライマリインスタンスになるための能力を記述します。各インスタンスは、読み取り専用、このようなモデルの下で、「ライブラリにより調製」されますが、ライブラリが作業に参加する用意がある、無駄現象はありません。
得益于数据共享（后面会提到）的模式，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和 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%平均耗时场景结果（越小越好）
无论是 POLARDB 还是 RDS 都是配置越高实例越多性能越好的，这里测试的都是入门款，所以评测效果并不是怪兽级的。
不过我们依然可以看到这是 POLARDB 的碾压局，同配置下 POLARDB 较 RDS 有近一倍的性能提升，和自建 ECS 并且是我的“弱鸡”调参比几乎是碾压。
值得一提的是，我貌似读写场景都没有把读写分离和单主实例的性能差异测出来，如果有测试方式有问题欢迎大家斧正。
横向“云评测”
在科技产品界有一种说法较“云评测”，那就是明明某小编产品实际没摸过，但是小编还是能一本正经的能来波横向测评。 这次我也来一波云测评~
目前阿里云平台上的 MySQL 兼容产品就有： 云数据库 MySQL 版（RDS）、分布式关系型数据库（DRDS）、云数据库POLARDB、HybridDB for MySQL (原PetaData)。 那么有人就会问，四款 MySQL 怎么选怎么用呢？
首先，我们可以看一下一张加入了 POLARDB 的阿里云数据库家族上云指导图：
大致的我们就可以知道，HybridDB for MySQL (原PetaData) 是专门用于 HTAP 场景的，有强 OLAP 需求还是得考虑 HybridDB，不过其为了 OLAP 兼容还是丧失了一些 MySQL 特性的，比如说不支持约束和一些高级特性。
接下来三个数据库当中，都是常见的 MySQL OLTP 场景，而且都可以添加只读实例，同质化很严重。
云数据库 MySQL 版依旧是最简单的 MySQL 目前支持的功能最多，但是性能略有不足，而且所有升级操作都是小时级的操作体验相对不太好。未来的话我认为更适合小规格数据库的入门级使用。
DRDS 和 POLARDB 都有分布式的属性，DRDS 的分布式是实例级的，POLARDB 是共享分布式存储。
DRDS 是集合多台 RDS 的性能来提升性能避免单台数据库的性能瓶颈，适合非常大规模的业务，但是分库分表等操作对操作人员要求较高，必须得需要有一定的数据库功底，要对数据库进行更改，对使用者来说有一定学习成本。DRDS 本身是一款中间件产品（尽管已经划分到数据库分类下了），底层还是依赖于 RDS 实例的，所以 DRDS 离不开 RDS，因此在大规模存储的情况下，我觉得超过2T的存储，DRDS 也吃力，其亮点还是分布式的性能表现优异。
POLARDB 则是一款全新的类型，对 MySQL 有了内核级的改造，在读的能力上大大提升并且性能优异，但是相对来说 写 还是依赖于主实例，DRDS 的分布式可以提升写的能力。 如果 POLARDB 完成了 多主进群（Multi-Master） 的支持的话，写的能力也会大大提升。 并且 POLARDB 不需要修改数据库，使用者可以无痛的切换，而且先进的分布式存储可以让其实现百T级的存储能力。 所以未来 POLARDB 和 DRDS 的竞争也是大有看头。
展望
POLARDB 的特性使得 MySQL 性能有了极大的提高，POLARDB 是一个分布式的理念，POLARDB 的 POLARSOTRE 架构其实是可以延伸到其他开源数据库上的。
未来 POLARDB for PostgreSQL、POLARDB for MongoDB、POLARDB for PPAS 都是非常可期的，未来更高性能的 PG、MongoDB 也是令人向往。