レビューPOLARDB 1.0
主な改良点は、単離されたコンピューティング・ストレージ・アーキテクチャを使用することを含む1.0は完全な互換性MYSQLベース、ネイティブのMySQLの6倍の性能であるPOLARDB。ユーザクラスタは、16分のクラス弾力性の計算ノード、ビジネスコンピューティングとストレージ完全に透過分離剤、ライブラリーからのみミリ秒の遅延に拡張することができます。分散ストレージ用のメモリブロックは、弾性100TBのサイズに拡張することができます。マルチレベルのストレージ技術をコピーし、0 RPOデータベースがした作り、データを失う危険性はありません。
POLARDB 1.0従来のデータベースの以下の痛みのポイントに最適なソリューション：
1、サイクルが長いアップグレード、データを移行するためのハードウェアの必要性をアップグレードし、簡単に予想外のトラフィックピークに対処することはできません。
（いつでも分のPOLARDB計算ノードよい膨張は、急速な拡大トラフィックの変異ことがわかります。）
2、金融信頼度RPO = 0、同時多層コピー、大きな性能損失を用いた従来のアーキテクチャの一例。
（POLARDBは6回をアップグレードする伝統的な建築様式より下RDMA、パラレルいかだ、最新のハードウェアおよびソフトウェア技術の3D Xpoint、最高のパフォーマンスを使用して、複数のコピーとして保存します。）
3、コピー層HAアーキテクチャ、長い時間のためのマスタースイッチとしては、例えば、連続要件金融レベルを満たすことができません。
（1つの層は、エージェントとビジネス層の計算の間に設けられているPOLARDBは、共有メモリを使用して、マスター・スレーブの切り替えは、数秒で行うことができ、剤層は、ユーザーが異常なコンピューティング・ノードを識別するのに役立ち、自動的にビジネスを知覚しない、ほとんどの時間を切り替えますサービスの継続性を確保するために、ノード演算を切り替えます）。
図4に示すように、従来のマスタ-スレーブ・アーキテクチャHA非同期複製は、ハンドオーバがライブラリから再構築する必要があるかもしれない、リソースを大量に消費する、より長い再構成時間、長い時間のために単一障害点が存在します。
（POLARDB共有メモリアーキテクチャを使用して、マスタは、ハンドオーバからデータを再構築する必要はありません。）
図5は、各ノードが全く同じ、高コストのマスターコピーの読み取り専用コピーを必要とします。
（POLARDB共有メモリアーキテクチャを使用して、全体的なコストが従来のアーキテクチャと比較してはるかに低くなるように、メモリコピーの数を増加させることなく、計算ノードの増加）。
図6に示すように、高遅延から別読み取りおよび書き込みロジックREDO複製マスターを使用。
（POLARDBデータストレージ共有ストレージ、データ同期がREDO、ミリ秒単位で同期、マスタ-スレーブ遅延のみREDO部位を必要としません。）
7、シャーディング・アーキテクチャは、ビジネスは巨大な侵略（より制限のSQLを）持っている、良い、機能的去勢を想像していませんでした。
（POLARDB MYSQLベースは完全に互換性、サービスのない侵入は、ユーザがPOLARDBを使用することができるコードの行を変更する必要はありませんがありません。）
8、TBは、上記の例では、ゆっくりと時間の多くの場合、数十をバックアップします。
（POLARDBスナップショットバックアップ技術に関係なく、どのように大きな第二レベルのバックアップのデータ量）
POLARDB 1.0は、2年にリリースされた、私たちは、企業顧客の多くを獲得しました。POLARDB 1.0は完璧だった、なぜ我々はそれ2.0開発すべき？
なぜR＆D 2.0
1、Oに対するユーザーの要求が、繰り返しは維持しよう
なぜOに非常に多くのユーザーがそれを繰り返し続けるしようとするのですか？
1、企業は非常に深刻な歴史的な負担を持っています
1.1 Oracleテクノロジ・スタック（チーム）のために、企業は多くの場合、テクノロジー・スタック、他の製品の長期間に適応するため、ハードUターン
1.2、それは、コード変換、長い期間、ハイリスク、低リターンの多くが含まれている場合、移行
1.3、Oracleデータベースエンジンは一般的に非常に悪いの互換性をターゲット、ユーザーが改装の多くを必要とします
2、効果的な移行方法の欠如、ツール
2.1、ワークロードの移行改革は、評価が困難である移行サイクルを評価することは困難である、サイクルは通常、非常に長いです（他人の成功にOの経験をコピーすることはできません）
2.2、有効なデータ移行、データ検証、シミュレーションツールはありません。Oリスクに私たちの脳をラッキングすることは非常に大きいです。
3、ターゲット・データベース・エンジンの数、難しい選択
3.1、離れて行くためには、いくつかの企業がO O、何のビジネス価値、企業が力を持っていません。
3.2、信頼性、セキュリティ、スケーラビリティ、互換性、安定性、パフォーマンス、可用性、および他の指標目標エンジンは、ユーザのニーズを満たしていないかもしれ
2、ビジネス要件のデータベースは、それが再び、に必要なのか？
企業データベースはSQLの汎用性だけでなく、NoSQLの拡張性だけでなく、マルチモードのデータ処理の利便性の両方を必要とします。高い同時実行するだけでなく、リアルタイムに複雑な分析で両方。しかし、従来のデータベースはまた、両方のニーズを満たすためにすることはできません。従来のデータベースは、多くの場合、異なる製品・ソリューションを使用して、さまざまなシナリオを（蜘蛛の巣のような）複数のデータ同期を使用して。悲惨な非常に大規模なユーザーによって引き起こされる問題：
1、软硬件成本高，同步延迟，同步数据不一致，
2、开发成本高，排错复杂等头痛的问题阻碍企业业务发展！
3、企业的历史数据象五指山一样压得喘不过气。
企业的数据库通常生命周期非常的长，在整个生命周期的过程中，会产生很多被遗忘的“临时”数据(例如业务的历史数据库，开发或DBA在数据库中操作或产生过的临时数据，这些临时数据历经数年，可能已经无法分辨是属于什么业务的，还要不要被用到，还能不能删除等等。）慢慢就像“鸡肋”一样食之无味、弃之不行。大量“鸡肋”一样的冷数据占用大量空间，又不能删。逐渐成为数据库沉重的包袱。
(数据库存储价格昂贵、备份消耗大、大量占空间、恢复慢)。
4、专业的GIS处理场景，使用开源版本性能、功能无法满足？
随着物联网、智能终端、移动互联网的发展，越来越多的移动数据接入，应用对GIS数据的处理需求会越来越旺盛，据分析GIS已经是千亿级的市场规模，然而开源的GIS产品可能无法满足日渐丰满的需求。
5、高级DBA太难找、且价格昂贵
高级DBA是大型企业才会设置的职位，价格昂贵、人才缺失。他们的日常可能是喝喝茶、聊聊人生，一切尽在掌握中，问题已经防范于未然。而且这种DBA通常可遇不可求。
大多数的企业通常是SA或开发兼职DBA的工作，他们的日常可能是既要又要还要了。往往是数据库出了事情再来处理，所谓术业有专攻，SA或开发人员处理数据库问题（不管是性能问题还是管理问题），通常时间也可能很久。
2.0 重磅发布新特性
POLARDB 2.0 完全继承了1.0的架构体系，同时兼容了另外两个流行数据库Oracle与PostgreSQL
POLARDB for PostgreSQL
完全兼容PostgreSQL，支持计算与存储分离、独立伸缩，存储按量付费。适合中大型企业核心业务。
【OLTP+OLAP混合负载】
支持混合负载业务，支持百万级高并发，支持并行计算，支持会话级资源隔离。
一个实例，一份数据，同时支持在线业务、实时分析混合业务。
原来用户需要将数据从在线数据库同步到数仓，问题非常多，POLARDB v2.0解决了跨产品数据同步带来的延迟、一致性、成本、使用习惯等问题。
1、技术指标：
最多支持16个计算节点，每个阶段节点88核；
每计算节点可提供百万级QPS；
支持对业务完全透明的并行计算，平均提速20倍以上，无惧复杂SQL；
【多模计算】
多模计算全面覆盖GIS、时空、时序、全文检索、图像识别、多维查询、向量相似、机器学习。
原来用户需要诸多产品来解决以上不同业务场景遇到的问题，数据需要在各个产品之间同步，异构同步带来延迟、一致性、成本、使用习惯等问题。
POLARDB v2.0新增引擎解决了以上问题。
1、技术指标：
ganos专业级时空组件，兼容GIS标准，MOD模型比PostGIS 50-100倍性能提升；
内置全文检索、图像识别、多维查询、向量计算、工业时序等多模组件；
内置schemaless、KV等nosql特性；
支持多达8种索引接口(btree,hash,gin倒排索引,GiST空间索引,SP-GiST空间分区索引,BRIN时序索引,rum全文索引,bloom布隆索引)，满足
各种多模数据的高速检索需求；
POLARDB for Oracle
高度兼容Oracle，降低Oracle迁移风险、缩短迁移周期，助力企业快速替换Oracle，进入云智能时代。
【深度Oracle兼容】
大幅降低用户去O风险、缩短去O周期。用户去O从数年降低到数周。
1、技术指标：
- SQL语法、类型、函数、PL/SQL、包、系统视图、OCI、PRO*C等全方位兼容Oracle；
- 兼容Oracle分区表、异构查询、HINT等高级功能；
- 支持3155个函数，26个包，317种包内方法，88个系统视图；
【智能驾驶】
POLARDB v2.0 for Oracle版，内置SQL防火墙。可以防SQL注入与SQL误操作。解决企业的数据库安全问题。
POLARDB v2.0 for Oracle版，内置索引推荐功能。是企业数据库优化的好帮手，一键解决索引优化难题
POLARDB v2.0，支持AAS性能洞察。在没有专业DBA的情况下，可以一键洞悉宏观、微观业务问题。帮助企业及时发现业务问题。
1、技术指标：
- SQL学习模式，防SQL注入与SQL误操作；
- 索引推荐，一键解决索引优化难题；
- AAS性能洞察，一键洞悉宏观、微观业务问题；
【云原生】
使用POLARDB v2.0替代ORACLE，可以获得POLARDB强大的云原生能力。通过oss_fdw接口可以读写OSS数据，支持冷热分离，对接云端海量算力(函数计算、MAXCompute)，获得强大的数据处理能力。企业加快推向DT时代。
1、技术指标：
- OSS外部表，冷热数据分离存储，历史数据想存多久都可以；
- 无缝对接云端海量算力(ADB、MaxCompute、OSS函数计算等)；
2.0 适合哪些业务场景和客户
1、适用场景
- 替换Oracle数据库
- 企业核心数据库
- GIS时空数据库
2、适合客户
企业级客户（党政军、医疗、新零售、新制造、科研机构、金融、互联网、物联网、交通、航空、地图，气象，测绘，LBS，国土，GIS等专业领域）
2.0 关键技术点解读
1、智能驾驶
1、SQL防火墙，防SQL注入，防误操作。
SQL防火墙背后的原理，POLARDB v2.0 for Oracle 通过开启SQL学习模式来学习业务发起的SQL请求，数据库将SQL请求变量化，转换为SQL HASH，存储起来作为SQL白名单。
当学习模式结束后，可以开启permission模式，如果有非白名单内的SQL请求，则发出警告。DBA可以关注到这个警告，判断是否为异常请求。
用户也可以将模式改为强制模式，如果有非白名单内的SQL请求，则会拒绝这样的请求，从而根本上防止SQL注入，防止用户误操作。
除此以外，POLARDB v2.0 for Oracle 还支持规则配置，例如可以拒绝不带WHERE条件的DML请求，拒绝WHERE 条件始终为TRUE的DML请求，从而防止SQL注入攻击或人为的误操作。
2、索引推荐，即使是数据库小白用户，也能一键优化数据库。
用户可以在会话中开启索引推荐的模块，一旦开启，这个会话发起的SQL请求会被后台分析，在运行一段时间后，调用索引推荐函数，我们可以看到数据库已经对到当前会话执行过的SQL进行了索引推荐的优化。
3、性能洞察，这个功能是非常强大的，通过等待时间的采集，打点，我们可以观察到数据库在过去的任意时刻是否遇到性能瓶颈，性能瓶颈是什么？即使企业中没有专业的DBA，也能轻而易举的发现数据库的性能问题。
2、并行计算，多达几十种场景，平均20倍性能提升
- 并行计算解决了复杂查询慢的问题，在企业中，我们通常会有数据分析的需求，以往由于关系数据库的分析计算能力差，需要将关系数据库的数据同步到大数据平台进行分析，而同步会有延迟、会有成本开销、会有同步问题等等。用户苦不堪言。
- POLARDB v2.0 内置了并行计算的功能，并行度会根据SQL的成本（复杂度的衡量）来规划，复杂SQL会启用并行计算，同时并行度也是自动计算的。使得用户不需要将数据同步到外部，也能实现实时分析。
- POLARDB v2.0 的并行计算覆盖了数十种场景，实测性能提升平均20倍以上。
3、会话级资源隔离
- 当用户有OLTP业务同时混合了OLAP业务时，OLTP的并发高，要求的RT低。OLAP的并发低，但是对计算要求很高，跑OLAP业务会占用大量的资源。
- POLARDB 支持16个计算节点，我们可以采用不同的计算节点来隔离OLAP，OLTP业务。
- 但是，如果用户的TP、AP业务在同一个计算节点时，还有更好的方法，会话级资源隔离，目前支持CPU和IO的资源隔离。
4、ganos时空多模组件
ganos是阿里巴巴自研的3S引擎，兼容GIS标准，支持平面几何模型、球面几何模型、栅格模型、时空轨迹模型、点云模型、拓扑网络模型等。
ganos相比开源GIS的优势也非常明显。
5、云原生的冷热分离
- POLARDB v2.0 可以将OSS作为数据存储，用户通过创建oss_fdw外部表插件，建立OSS外部表，可以将数据写入OSS，也可以从OSS读取。采用标准的SQL接口。
- 因此对于访问较少的冷数据，用户可以将数据存储在OSS，降低数据库的分布式块存储的成本，得到无限的存储空间。
- 同时由于OSS与云端的MAXCompute, ADB, 函数计算等都是打通的，所以当用户是非常大型的企业，需要对多个数据库实例进行横向的大数据分析时，OSS_FDW无疑是一种非常好的数据共享方法，将多个实例的数据通过OSS进行分析，打通大计算。
6、为什么2.0支持多模
1、传统数据库通常只支持1种索引，而POLARDB v2.0 支持8种索引
- btree、hash、gin、brin、gist、spgist、bloom、rum
2、传统数据库通常仅支持几种数据类型，而POLARDB v2.0支持大量数据类型
时间、字符串、数值，货币，字节流，比特，枚举，布尔，几何，网络，全文检索，UUID，JSON，XML，数组，复合，范围，域，图像，树，多维立方，GIS，rb，HLL，K-V，还支持扩展类型
3、POLARDB v2.0 还支持了非常多的多模插件，大幅度的帮助用户提高开发生产效率。
小结
POLARDB v2.0 for Oracle，高度兼容Oracle，同时支持了SQL防火墙、自动索引推荐、性能洞察、资源隔离等智能驾驶功能，支持了冷热分离的云原生能力，解决了企业去O难题，帮助企业快速去O。
POLARDB v2.0 for PostgreSQL，完全兼容PostgreSQL，支持并行计算，混合负载，GIS时空等多模计算，具备冷热分离的云原生能力，是企业级客户（党政军、医疗、新零售、新制造、科研机构、金融、互联网、物联网、交通、航空、地图，气象，测绘，LBS，国土，GIS等专业领域）核心数据库上云的很好选择。
原文链接
本文为云栖社区原创内容，未经允许不得转载。