Alibaba CloudのPolarDBの徹底分析(7)_AWS Auroraとの比較

# 類似点
- share storageのアーキテクチャ
- computingとストレージの分離
- 1 write node + 複数read replicaの構成

## 相違点
## Oracleと互換性あるかどうか
  - AWS Aurora: 
      - MySQLとPostgeSQLのデータベースエンジンしかない。(100%互換)
      - AWSでOracleを使いたい場合は、RDS Oracleを利用することになる。(高額なOracleライセンスが必要)
  - PolarDB：
      - MySQLとPostgeSQL(100%互換)
      - Oracleと高い互換性のエンジン
          - Oracleそのものではなくて、クエリレベルでOracleと高い互換性を持つエンジン
          - Oracleライセンス不要であり、リソースの料金だけ払えばよい。

## clusterエンドポイントによる自動的にread/writeの分離
https://www.ashisuto.co.jp/cloud/aws/pr/aurora-column-part1.html

## PolarDB
https://qiita.com/dennis_wang/items/eff3a3993e4b590cfaca#%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
1. cluster endpoint：すべてのnodeに自動的に負荷分散、なおかつread/writeの自動分離してくれるendpoint
2. primary endpoint： primary endpointへ接続するためのendpoint
3. reader endpoint：すべてのread-only nodeへ接続するためのendpoint
4. custom endpoint：インスタンスを任意に指定(複数可)して接続するためのendpoint
5. instance endpoint：インスタンスごとに用意され、そのインスタンスにのみ接続するためのendpoint

|種類|AWS|Alibaba Cloud|
|:-----:|:----:|:----:|
|cluster endpoint|なし|あり|
|primary endpoint|あり|あり|
|reader endpoint|あり|なし(custom endpointで作成できる)|
|custom endpoint|あり|あり|
|instance endpoint|あり|あり|

:::note info
Auroraは更新・参照それぞれのエンドポイントがありますが、クエリに応じてエンドポイントを振り分けるのはアプリケーション側の責務です。
Auroraには`クラスターエンドポイント`という言葉もありますが、実は`プライマリインスタンス`のエンドポイントを指しています。
Auroraのエンドポイントに関する構成図：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/daf30c67-6835-b61d-83cd-c80425f07735.png)
readとwriteともにheavyなworkloadではreadの処理はプライマリインスタンスだけではなく、read replicaにも負荷分散したいでしょう。その場合は以下の方法があります。

１．アプリケーションを改修して振り分ける方法：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/a9d146c6-a542-9138-2057-cdd0736fbec5.png)
2.プロキシを導入して振り分ける方法： 
- 自前でProxyの導入、運用が必要で、かなり手間かかります。
- Proxyは単一障害点ならないように、冗長構成などを考慮する必要もあり、さらにハードルが高くなってしまいます。
- RDSにはRDS Proxyという機能がありますが、read/write自動分離＆自動振り分けという機能がないため自前で構築運用するしかありません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/1ecbe882-86d4-a752-b9b7-646bac83d7be.png)

参照・更新クエリを振り分けるプロキの例：
- MySQL： [MariaDB MaxScale](https://mariadb.com/kb/en/maxscale/) や [ProxySQL](https://proxysql.com/)
- PostgreSQL： [Pgpool-II](https://www.pgpool.net/mediawiki/index.php/Main_Page)

:::

:::note info
なぜRDS ProxyはAuroraクラスターのマスターノードとリードレプリカ間で自動的に読み書きが分割できないのか？
RDS Proxyはデータベース接続の効率性と安定性を向上させますが、自動的に読み書きを分割する機能は提供しません。読み書きを分割するには、アプリケーション側でマスターまたはリードレプリカのエンドポイントを適切に指向するように実装する必要があります。
1. 書き込み操作：RDS Proxyのエンドポイントは主にAuroraクラスターのマスターノードに書き込み操作を指示します。
2. 読み込み操作：リード操作をリードレプリカにオフロードしたい場合、これはアプリケーションレベルで処理する必要があります。アプリケーションは、読み取りクエリをリードレプリカに、書き込みクエリをマスターノードに指示するように設計されるべきです。これには、アプリケーションがマスターとリードレプリカの両方のエンドポイントを認識している必要があります。
3. 読み書き分割の手動設定：アプリケーションが読み書き分割を必要とする場合、通常は読み取り操作と書き込み操作のために別々のエンドポイントを設定します。Auroraでは、特定のタイプの操作（例えば、読み取り専用のエンドポイント）に指定されたカスタムエンドポイントを作成できます。その後、アプリケーションのロジックは、操作の性質に基づいてクエリを適切なエンドポイントにルーティングする必要があります。
4. RDS Proxyの使用：この設定では、RDS Proxyはこれらのエンドポイントへの接続をより効率的に管理するために使用されますが、与えられたクエリ（読み取り vs 書き込み）をどのエンドポイントに使用するかの決定はアプリケーションによって行われ、RDS Proxyによって行われるわけではありません。
:::


# HTAP(Hybrid Transaction／Analytical Processing)
HTAPデータベースはオンライントランザクション処理（OLTP）データベースとオンライン分析処理（OLAP）の両方のワークロードを同時に処理できるハイブリッドデータベースです。
PolarDBはHTAPも対応しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/d1e9c5e3-61fc-48f7-3a2f-37ccfd644b22.png)
- IMCI(In-Memory Column Index)のRead-only instanceを起動すれば簡単にOLAP利用できる。
- 内部のRedo logレプリケーションによって、ROインスタンスからIMCI RO(OLAP分析用)インスタンスにデータを同期し、ミリ秒レベルの遅延が保証されること。
- applicationから統一のcluster endpointへアクセスすればよくて、 Proxy側内部で自動的に実行計画によってOLTPとOLAPのクエリを識別し自動的に適切なROインスタンスに振り分けられる。

# セキュリティ関連
PolarDBではSQL FireWallという機能があります。
- SQL firewallとは
実行してはいけないqueryパタンを定義して、リスクの高いSQL操作を事前に遮断する機能

- 利用シーン：
    - DBがハッキングされ、攻撃者はDBを一括copyですべての情報を抜き出すことを防ぎたい
    - 日々の運用業務でDELETE文にwhere条件がなく、誤ってデーブルを丸ごと誤削除を防ぎたい

- 利用タイプ：
    - blacklist: 特定のタイプまたは特定のSQLステートメントをブロック
    - whitelist: ホワイトリスト内のSQLのみ利用可能

# 復元
|復元の粒度|PolarDB|Aurora|
|:-----:|:----:|:----:|
|instance丸ごと復元|○|○|
|databaseレベル復元|○|☓|
|tableレベルの復元|○|☓|


# コスト
||PolarDB|Aurora|
|:-----:|:----:|:----:|
|DBインスタンス時間(従量課金)|課金対象|課金対象|
|ストレージ時間(従量課金)|課金対象|課金対象|
|I/Oリクエスト数(従量課金)|無料|課金対象($0.34/100万リクエスト)|

I/Oリクエスト数の料金は処理の種類や量に大きく影響されるため、試算することが難しいですが、一般的なオンライトランザクションシステム(普通のwebサービス)は基本的にリクエストごとにDBアクセスするため、I/O料金はデータベース料金の全体の半分以上を占める場合も少なくありません。
ですので、Auroraを利用する場合は、I/O料金は大きく見積もったほうが無難でしょう。

# まとめ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/942fca8e-78dd-0ee2-866e-3a5f05a7333c.png)