OracleDatabaseTechnologyNight42RAC

Oracle Database Technology Night #42 Oracle Real Application Clusters Converged
Databaseを可能にするもの 2021年3月30日日本オラクル株式会社日下部明

Converged Database • マルチ・モデル • マルチ・ワークロード Oracle Real Application Clusters
• アーキテクチャ • マルチ・ワークロード(トランザクション系と大量アクセス系)を同居させるには？アジェンダ Copyright © 2021, Oracle and/or its affiliates 2

将来変化するであろうビジネス要件に柔軟に対応を可能にオラクルの戦略 | お客様に世界で最も優れたConverged Databaseを提供 3 開発者およびアナリストにとって最も生産性を高く統合されたマイクロサービス, イベント, REST,
SaaS, 機械学習, CI/CD, ローコード開発環境多くのワークロード・タイプをサポートトランザクション, データ分析, 機械学習, IoT, ストリーミング, ブロックチェイン多くのデータ・タイプとデータ・モデルをサポートリレーショナル, JSON, グラフ, 位置情報, テキスト, OLAP, XML Copyright © 2021 Oracle and/or its affiliates

主要なデータ・タイプとデータ・モデルに対応 Oracle Databaseはマルチ・モデルをサポート利用者にとって重要なことデータ一貫性すぐに分析可能であることセキュリティの確保信頼性スケーラビリティ JSON
Graph Text リレーショナル Spatial Oracle Database Blockchain Copyright © 2021 Oracle and/or its affiliates 開発者にとって重要なこと適性なデータ・モデル宣言的なSQLでアクセストランザクション主要な開発言語をサポート標準化されたAPIで開発 4

Oracle Databaseがサポートする主要なデータ・タイプとデータ・モデル Copyright © 2021, Oracle and/or its affiliates 5
リレーショナル • 表形式 • 数値・文字 • SQLアクセス • 複雑な問い合わせ Spatial • 座標・ポリゴンなど空間情報 • GPSなどの座標情報の活用 Text • テキストもしくはドキュメント・データの全文検索 JSON • テキストベースのデータ交換用のフォーマット • シンプルで使いやすいデータ形式 Graph • ノードとエッジの関係性 • 関係性の検索など高速で実現 Blockchain • データの改ざんを前後のデータのつながりで防止 • 監査証跡、トレーサビリティなど

1つのデータベースで複数のワークロードを同時に処理でき、リアルタイムなデータ分析を実現オンライン・トランザクション処理 • トレーディング・システムやショッピング・サイトなど • 同時、大量ユーザー、低レイテンシ分析処理 • ペタバイト級のデータ・ウェアハウス
など • 大量データ、大量処理 IoT • 各種センサーから情報を受け取るストリーミング処理 • 大量デバイス、超低レイテンシ • 時系列分析リアルタイム・アナリティクス • 超高速インメモリ分析 • 機械学習 • グラフ分析 Oracle Databaseはマルチ・ワークロードをサポート Copyright © 2021, Oracle and/or its affiliates 6

Oracle Real Application ClustersはなぜConverged Databaseを可能にするのかパフォーマンスとアプリケーション開発 • なぜトランザクション系と大量アクセス系を混在できるのか • なぜデータ・モデルをパーティション分割せずに配置できるのか
• なぜクラスタ構成なのにアプリケーションから透過的なのか可用性 • なぜ障害発生から短時間で全データへのアクセスを再開できるのか透過性 • なぜクライアントから見てノード構成を隠蔽できるのか今日お話したいこと Copyright © 2021, Oracle and/or its affiliates 7

Copyright © 2021, Oracle and/or its affiliates 8 Oracle Real
Application Clustersアーキテクチャ

RACの物理構成 Copyright © 2021, Oracle and/or its affiliates 9 ストレージ・ネットワーク
インターコネクト・ネットワークパブリック・ネットワークデータベース・クライアントクライアントとの通信ストレージ・ノード • ストレージ・デバイスコンピュート・ノード • CPU+メモリー • 全ノードが対等な関係コンピュート・ノード間の通信全コンピュート・ノードは全ストレージにアクセス可能

データ・モデル(スキーマ構造)、トランザクション分離レベルの挙動も同じクライアントはどのノードに接続してもシングル・インスタンス構成と同じアクセスが可能 Copyright © 2021, Oracle and/or its affiliates 10
ストレージ・ノード • ストレージ・デバイスコンピュート・ノード • CPU+メモリー • 全ノードが対等な関係インターコネクト・ネットワークコンピュート・ノード間の通信全コンピュート・ノードは全ストレージにアクセス可能パブリック・ネットワークデータベース・クライアントクライアントとの通信ストレージ・ネットワークメモリー一貫性を全自動で維持 oracle クライアントが接続したノードのプロセスがSQL 処理

サーバーがクラッシュしてもクライアントは別ノードに接続すると全データにアクセス可能クライアントはどのノードに接続してもシングル・インスタンス構成と同じアクセスが可能 Copyright © 2021, Oracle and/or its affiliates 11
ストレージ・ノード • ストレージ・デバイスコンピュート・ノード • CPU+メモリー • 全ノードが対等な関係インターコネクト・ネットワークコンピュート・ノード間の通信全コンピュート・ノードは全ストレージにアクセス可能パブリック・ネットワークデータベース・クライアントクライアントとの通信ストレージ・ネットワークメモリー一貫性を全自動で維持 oracle クライアントが接続したノードのプロセスがSQL 処理 oracle

データ・モデル(スキーマ構造)、トランザクション分離レベルの挙動も同じ全ノードを使用した1つのSQL処理の並列化が可能 Copyright © 2021, Oracle and/or its affiliates 12
ストレージ・ノード • ストレージ・デバイスコンピュート・ノード • CPU+メモリー • 全ノードが対等な関係インターコネクト・ネットワークコンピュート・ノード間の通信全コンピュート・ノードは全ストレージにアクセス可能パブリック・ネットワークデータベース・クライアントクライアントとの通信ストレージ・ネットワークパラレル実行プロセスがデータ交換しながら並列実行 oracle PX PX PX PX PX PX 接続したノードの Oracleサーバー・プロセスがコーディネーター

Copyright © 2021, Oracle and/or its affiliates 13 「データベース」とは制御ファイル、(オンライン)REDOログ・ファイル、データファイルの集合をあらわすシングル・インスタンス構成のデータベース・ファイル構造
REDOログ・ファイル制御ファイルデータファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データファイル (UNDO表領域) Oracle インスタンス

Copyright © 2021, Oracle and/or its affiliates 14 REDOログ・ファイルとUNDO表領域をOracleインスタンスごとに追加 RACのデータベース・ファイル構造
REDOログ・ファイル制御ファイルデータファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データファイル (UNDO表領域) REDOログ・ファイル UNDO データファイル (UNDO表領域) 全インスタンスからアクセスされるインスタンスが起動している間はそのインスタンスからのみアクセスされる Oracle インスタンス1 Oracle インスタンスn データベースを構成する全ファイルは共有ストレージ上にあるので全インスタンスからアクセス可能な状態にある。 REDOログ・ファイルとUNDO表領域はインスタンスが起動している間は各インスタンスからのみ書き込まれる。初期化パラメータでインスタンスごとに指定 SID.THREAD=n SID.UNDO_TABLESPACE=UNDOTBSn

Copyright © 2021, Oracle and/or its affiliates 15 「データベース」はストレージ上のファイル群を指す言葉 Non-CDB構成のファイル構造
REDOログ・ファイル制御ファイルデータファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データベース REDOログ・ファイルとUNDO表領域は Oracleインスタンスごとに存在する UNDO ×Oracleインスタンス数

Copyright © 2021, Oracle and/or its affiliates 16 プラガブル・データベースはデータファイルの集合 CDB構成のファイル構造
REDOログ・ファイル制御ファイルデータファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS アプリケーション用PDB 1 アプリケーション用PDB n ルート・コンテナ(REDOログと制御ファイルを持っている) CDB$ROOT PDB 1 PDB n REDOログ・ファイルとUNDO表領域は Oracleインスタンスごとに存在する UNDO ×Oracleインスタンス数プラガブル・データベースはデータファイルのみの集合

Stripe And Mirror Everything (S.A.M.E.) ファイルをエクステントに分割し、 • すべてのストレージ・デバイスに均等に分散する ⇒Stripe •
複製を異なるストレージ筐体の障害グループ(FAILGROUP)のストレージ・デバイスに配置する ⇒Mirror そしてストレージ・デバイスが増減してもリバランスすることでStripeとMirrorを維持する Automatic Storage Management (ASM)のファイル配置 Copyright © 2021, Oracle and/or its affiliates 17 異なるFAILGLOUPのデバイスにミラーリングすべてのデバイスにストライピングプライマリ・エクステント ASM上のファイル extent extent extent セカンダリ・エクステント(ミラー) ASMエクステント FAILGLOUP 1 FAILGLOUP 2 FAILGLOUP n

Exadata Database Machine ASMのコンセプトを正しく実装 Copyright © 2021, Oracle and/or its
affiliates 18 Storage 1 Storage 2 Storage 3 Database Server 1 Database Server 2 Flash Memory x4 HDD x12 FAILGROUP switch switch Storage n Database Server n ストレージ筐体は2RUサイズのIntel Xeonサーバー • HDD 12台 → ASMディスク12本に見える • Flash Memory 4枚(キャッシュ) • Persistent Memory 12枚(キャッシュ, X8M~) 1つのストレージ筐体が1つのASM障害グループ • ミラーは異なるストレージ筐体に格納される • ストレージ筐体ごと停止してもシステム継続ネットワーク総帯域の増加 RACでスケール・アウト ASMでスケール・アウト

その問題を解決するためにASMが導入された Oracle9i RAC • ストレージ構成はストレージ・ベンダー任せ • 単一の大型ストレージを使用する傾向があった Oracle RAC 10g
• Oracle Clusterware+ASM導入 • 複数のストレージ筐体でスケールアウトかつ障害対策 FAQ: RACは共有ストレージを使用しているからストレージ障害に弱い？ Copyright © 2021, Oracle and/or its affiliates 19 ストレージ装置のスケールアップ • 冗長化コントローラー • RAID switch switch switch switch ストレージ装置のスケールアウト • Stripe And Mirror Everything • ストレージ筐体の障害にも対応

インターフェースとアルゴリズムの実装が分離されている SQL • 入力と出力の対応関係のみ記述(宣言型) • インターフェースの定義 SQL実行計画 • SQLが定義した対応関係を導出するアルゴリズム •
全体最適化されたアルゴリズムをDBMSが自動生成 SQL実行計画の部分を構成するアルゴリズム実装 • 索引、パーティショニング、... • ネステッド・ループ結合、ハッシュ結合、... • 並列化 • ... SQLの実行モデル Copyright © 2021, Oracle and/or its affiliates 21 PX PX PX PX 索引パーティショニング結合並列化入力出力 SQL実行計画結果の正しさ(SQL)に手を付けずに実装を改良できる対応関係

データ・モデルとクラスタ・ノード構成が分離されているアプリケーション開発で本来気にするべきは抽象概念のデータ・モデルと結果集合を定義するSQLインターフェースであって、クラスタ構成の実装の制約を受けるべきではない。データ構造の一種である索引やパーティショニングはSQL 実行計画のアルゴリズムのためであって、クラスタのノード構成とは別の話。 RACはデータの配置がデータベース・サーバーと結びついていない。
シェアード・ナッシング・クラスタはデータの配置がサーバーとストレージに強固に結びついている。 Oracle Real Application Clusters Copyright © 2021, Oracle and/or its affiliates 22 データ・モデル/SQL 抽象実装データ構造/クラスタ構成

RACはデータ・モデルと物理配置が結びついていないのでパーティショニングは必須ではないクラスタ・アーキテクチャとデータ配置 Copyright © 2021, Oracle and/or its affiliates 23
データ・モデルストレージのスケールアウトデータベース・サーバーのスケールアウトデータベース・サーバー+ストレージのセットのスケールアウト Oracle Real Application Clusters Oracle Database Sharding データのパーティショニング必須 (物理配置と強い結びつき) データ・モデルをそのまま配置可能 (パーティショニングを問わない)

性質の異なる処理を同居させるにはトランザクション系大量アクセス系データ・アクセスの性質に求めるもの低レイテンシ並行性/一貫性制御高スループット計算量のオーダー性能最適化の技術要素キャッシング
索引 ... 並列化パーティショニング ... マルチ・ワークロード Copyright © 2021, Oracle and/or its affiliates 24 PX PX PX PX クラスタ構成で性質の異なる最適化を同居させるには？

Copyright © 2021, Oracle and/or its affiliates 25 トランザクション系 Cache
Fusion

Copyright © 2021, Oracle and/or its affiliates 26 Oracleサーバー・プロセスがメモリを操作しバックグラウンド・プロセスがファイルに永続化 Oracle
Databaseアーキテクチャ(シングル・インスタンス) オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス DBWn データベース・ライター・プロセスデータファイル更新履歴(REDOログ情報)はOracle サーバー・プロセスによって生成され REDOログ・バッファに置かれるオンラインREDOログ・ファイルに永続化データ・ファイルに永続化データ操作はデータベース・バッファ・キャッシュ上のデータ・ブロックにアクセス SGA REDOログ・バッファデータベース・バッファ・キャッシュ

Copyright © 2021, Oracle and/or its affiliates 27 バッファ・キャッシュ・ミスするとOracleサーバー・プロセスがストレージからデータ・ブロックを取得 Oracle
Databaseアーキテクチャ(シングル・インスタンス) オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス DBWn データベース・ライター・プロセスデータファイル SGA バッファ・キャッシュ・ミスするとOracleサーバー・プロセスがストレージからデータブロックを取得しバッファ・キャッシュに乗せる REDOログ・バッファデータベース・バッファ・キャッシュ

Copyright © 2021, Oracle and/or its affiliates 28 バッファ・キャッシュ・ミスすると別のOracleインスタンスからデータ・ブロックを取得 Oracle
Databaseアーキテクチャ(RAC) REDOログ・バッファオンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセスデータベース・バッファ・キャッシュ DBWn データベース・ライター・プロセスデータファイル SGA バッファ・キャッシュ・ミスすると別のOracleインスタンスがキャッシュしているデータブロックを取得しバッファ・キャッシュに乗せる

Copyright © 2021, Oracle and/or its affiliates 29 Oracleサーバー・プロセスから見るとローカルのデータベース・バッファ・キャッシュを操作しているだけ Oracleクライアントからはシングル・インスタンスもRACも同じに見える
REDOログ・バッファオンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセスデータベース・バッファ・キャッシュ DBWn データベース・ライター・プロセスデータファイル SGA データ操作はデータベース・バッファ・キャッシュ上のデータ・ブロックにアクセスバッファ・キャッシュ・ミスしたときにどこから取得するかの違いバッファ・キャッシュ・ミスしたときにどこから取得するかの違い

Oracle Real Application Clusters SGA ユーザーからは透過的に複数CPUで処理可能共有メモリー型マルチ・プロセッサ RACのアーキテクチャは共有メモリー型マルチ・プロセッサと同じくキャッシュ一貫性を維持 Copyright ©
2021, Oracle and/or its affiliates 30 ノード1 (キャッシュ) ノード2 (キャッシュ) データベース (ストレージ上のファイル群) SGA キャッシュ一貫性キャッシュ・メモリーキャッシュ・メモリーキャッシュ一貫性 CPU 1 CPU 2 SGA DRAM (メイン・メモリー)

Cache Fusion ディレクトリ・ベースのキャッシュ・コヒーレンス・プロトコル Cache Fusionのブロック転送は最大で3ホップ Oracleインスタンスは3つの役割に分かれる Requester • あるデータ・ブロックへのアクセスにキャッシュ・ミスしたインスタンス •
(1) Database Block Address(DBA)からそのブロックのMasterノードを算出してブロック転送を依頼 Master • そのデータ・ブロックのキャッシュ状態を管理しているインスタンス • (2) Holderにブロック転送を指示 Holder • そのデータ・ブロックの最新状態をキャッシュしているインスタンス • (3) Requesterにブロック転送 MasterがRequesterもしくはHolderと同一ならば2ホップ 31 Copyright © 2021, Oracle and/or its affiliates Oracleクライアント SGA oracle SGA Requester Master Holder (1)依頼 (2)転送指示 (3)転送 SGA LMS LMS

Cache Fusion: Masterノードディレクトリ・ベースのキャッシュ・コヒーレンス・プロトコル SGA内にバッファ・キャッシュのクラスタ全体の状態を管理する領域があり、Global Resource Directory(GRD)という。 GRDは全インスタンスで分担している。
RACのSGAサイズがシングル・インスタンスの10%増となっているのはGRDの分。あるデータ・ブロックのキャッシュ状態を管理しているGRDをもつOracleインスタンス(そのデータ・ブロックのMasterノード)は、Database Block Address(DBA)から算出される。 32 Copyright © 2021, Oracle and/or its affiliates インスタンス1 Oracleクライアント SGA oracle SGA インスタンス2 インスタンス3 GRD SGA GRD GRD Master# = f(DBA) (1)依頼

Cache Fusion: データ・ブロックのロック・モード更新する瞬間だけ排他ロック・モードが必要/読み取りは複数インスタンスで同時アクセス可能 33 Copyright © 2021, Oracle and/or
its affiliates インスタンス1 Oracleクライアント SGA X oracle インスタンス2 SGA INSERT UPDATE DELETE MERGE インスタンス1 Oracleクライアント SGA S oracle インスタンス2 SGA S SELECT oracle SELECT 排他(Exclusive)モードでキャッシュしている間は読み取り/更新可能共有(Share)モードでキャッシュしている間は複数インスタンスで同時に読み取り可能索引ブロックのルートに近い方はあまり更新が発生しない

RACのデータ・ブロックのキャッシュ管理データベース・バッファ・キャッシュをキャッシュ・ミスしたら 1. リモート・インスタンスがキャッシュしていたらそこからブロック転送(Cache Fusion) 2. どのインスタンスもキャッシュしていなければストレージから取得 Cache Fusionのブロック転送は最大3ホップ •
4ノード以上の構成でも最大3ホップ • Requester / Master / Holder の役割の配置によっては2ホップになる場合もある • Cache Fusionのレイテンシーは約100μ秒で、これはNVMe Flash Memoryのレイテンシーとだいたい同じまず、キャッシュ・ミスの回数を減らすことが重要で、シングル・インスタンスと考え方は同じ CPUのデータ吸い上げ能力に対して十分なデータベース・バッファ・キャッシュのサイズがあるか 34 Copyright © 2021, Oracle and/or its affiliates

異なるデータ・ブロックへのアクセスデータへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 35
Oracle Real Application Clusters Oracle Database Sharding X X X X X X 異なるデータ・ブロックへのアクセスは全シャードで並列に実行可能クライアントサーバー異なるデータ・ブロックへのアクセスは全ノードで並列に実行可能

同じデータ・ブロックへの更新アクセスデータへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 36
Oracle Real Application Clusters Oracle Database Sharding X X データ・ブロックを更新する瞬間だけ1つのインスタンスが排他ロックする 1つのデータ・ブロックは1つのシャードしか持っていないクライアントサーバー ※DUPLICATED TABLEは全ノードで同じレプリカを持つが更新に向いていない

同じデータ・ブロックへの読み取りアクセスデータへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 37
Oracle Real Application Clusters Oracle Database Sharding S S S X クライアントサーバー 1つのデータ・ブロックは1つのシャードしか持っていない同じデータ・ブロックへの読み取りアクセスは全ノードで並列に実行可能 ※DUPLICATED TABLEは全ノードで同じレプリカを持つが更新に向いていない

データ・アクセスの分布に暗黙の前提があるデータへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 38
Oracle Real Application Clusters Shared-Nothing Cluster 異なるデータへのアクセス分布が比較的均等シャード(パーティション)をまたぐアクセスに弱いクライアントサーバーほとんどのアクセス・パターンに対応

Copyright © 2021, Oracle and/or its affiliates 39 SQL処理時間はメモリー操作なので極めて小さいがCOMMITはファイル書き込み時間が必要トランザクション系処理
REDOログ・バッファオンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセスデータベース・バッファ・キャッシュ DBWn データファイル COMMITはI/Oを伴うデータ操作SQLはほぼメモリー操作だけ SGA バッファ・キャッシュが十分大きければキャッシュ・ミスの影響は小さいレイテンシーを下げにくい

ストレージプロセスから見たレイテンシー一般的なストレージのI/Oレイテンシー Copyright © 2021, Oracle and/or its affiliates
40 LGWR ログ・ライター・プロセス NVMe Flash Memory proc HBA HBA ストレージ処理プロセス NVMe Flash Memory 同一サーバー内のNVMe Flash Memoryでは約100μ秒ネットワーク接続ストレージの NVMe Flash Memoryでは約 200μ秒データベース・サーバー OS OS

ストレージにPersistent Memory (PMEM)を追加データベース・サーバーからストレージ・サーバーのPMEMにRemote Direct Memory Accessする。低レイテンシー・デバイス+ストレージ側ソフトウェアのコンテキスト・スイッチ削減。 Oracle Database
19c以降で以下の用途がPMEM+RDMAの低レイテンシー・アクセスが可能。 • データ・ブロックのキャッシュ読み取り • オンラインREDOログ・ファイルの書き込み Exadata X8M Copyright © 2021, Oracle and/or its affiliates 41 ※ストレージ・サーバーは最低3台からデバイス High Capacity Model Extreme Flash Model PMEM 128GB×12=1.5TB 128GB×12=1.5TB Flash Memory 6.4TB×4=25.6TB 6.4TB×8=51.2TB Hard Disk 14TB×12=168TB - ストレージ・サーバー1台あたりのストレージ・デバイス

ストレージデータベース・サーバー Persistent MemoryへのRDMAアクセス Exadata X8MのI/Oレイテンシー Copyright © 2021, Oracle
and/or its affiliates 42 ログ・ライター・プロセス proc ストレージ処理プロセス NVMe Flash Memory Persistent Memory Persistent MemoryへのRDMA では約20μ秒 HBA HBA LGWR ストレージ処理プロセスのコンテキスト・スイッチが発生しないネットワーク接続ストレージの NVMe Flash Memoryでは約 200μ秒 OS OS

Oracleプロセスが複数のデバイス・ファイルに非同期I/OかつダイレクトI/Oを並行に発行 ASM多重化書き込み Copyright © 2021, Oracle and/or its affiliates 43
oracle LGWR 1 2 3 3 1 1 プライマリ・エクステントセカンダリ・エクステント 1. COMMIT発行 BG待機イベント log file parallel write 5. CPUスケジューリング待ち FG待機イベント log file sync 6. COMMIT完了 2. 非同期I/Oで複数ストレージ・デバイスに並行でwrite発行 3. write完了確認 4. write完了通知 LGnn Oracleサーバー・プロセスログ・ライター・プロセスセカンダリ・エクステント

ASM3重化(ストレージ・サーバー3台へのWrite 3か所)でのプロセスから見たレイテンシー PMEM無効 (Flash Memoryへのアクセス) PMEM有効 (PMEMへのRDMAアクセス + Flash Memoryからの読み取り)
Exadata X8MでのOLTP処理例 Copyright © 2021, Oracle and/or its affiliates 44 待機イベント 1回あたりの平均時間処理スループット log file parallel write LGWRの書き込み完了待ち 469.90μ秒 11,394 Commit/s cell single block physical read 1データ・ブロックの読み取り 459.98μ秒 49,848 Physical Read Blocks/s 54,102 Physical Write Blocks/s 待機イベント 1回あたりの平均時間処理スループット log file parallel write LGWRの書き込み完了待ち 53.49μ秒 12,647 Commit/s cell single block physical read 1データ・ブロックの読み取り 60.47μ秒 (PMEM + Flashの平均値) 54,550 Physical Read Blocks/s 64,732 Physical Write Blocks/s 10k Commit/s, 100k Blocks/sの高IO負荷でも待機時間が約1/8に減る

Oracleクライアントから見るとシングル・インスタンスもRACも同じバッファ・キャッシュ・ミスしたときのどこからデータブロックを取得するか • ストレージ • 別のOracleインスタンス SQL実行 • ほぼメモリの更新 •
Oracleサーバー・プロセスの中で経過する時間はとても短い COMMIT • ストレージへの書き込み完了を待つ • Exadata X8MのPersistent MemoryとRDMAによるREDOログ書き込み完了時間はとても短いトランザクション系 Copyright © 2021, Oracle and/or its affiliates 45

Copyright © 2021, Oracle and/or its affiliates 47 大量アクセス系 Internode
Parallel Execution Partitioning

1つの処理が大量のデータにアクセスする • パラレル実行 • アクセス範囲の削減(パーティショニング) • 複数ある表の結合(ジョイン) 大量アクセス系 Copyright ©
2021, Oracle and/or its affiliates 48

大量データの処理を分割し、複数のハードウェア(CPU/ストレージ)に割り当てて同時に実行することで、全体の処理時間を短縮する技法パラレル実行 Copyright © 2021, Oracle and/or its affiliates
49 並列度処理時間並列度1 並列度2 並列度4

Exadata X8M-2に使用されているデータベース・サーバーは1RUサイズのIntel Xeon 2ソケット・マシン CPU • Intel Xeon 8260
Cascade Lake (24コア) • 24コア × 2ソケット = 48コア DRAM (DDR4) • 32GB DIMM × 12スロット = 384GB • 32GB DIMM × 24スロット = 768GB • 64GB DIMM × 24スロット = 1536GB 最近のサーバー・ハードウェア Copyright © 2021, Oracle and/or its affiliates 50 CPUコア数の高密度化は1RUサイズのサーバーでも2桁の並列度を可能にした

データ操作の分析/集計処理や大量一括更新に対応 • SELECT • DML (INSERT/UPDATE/DELETE/MERGE) DDLも対応 • CREATE INDEX
• CREATE TABLE AS SELECT 複数のパラレル実行サーバー・プロセス(PX)が処理対象の表に対してアクセスする範囲を自動分割して同時に処理。パーティション化されていない通常の表でもパラレル実行が可能。 1つの処理を分割して複数CPUで並列に実行 Copyright © 2021, Oracle and/or its affiliates 51 PX PX PX パラレル実行プロセス表 PX

シングル・インスタンス Oracleクライアントが接続するOracleサーバー・プロセスとは別に、パラレル実行用のバックグラウンド・プロセス群がいる。パラレル実行プロセスは最大で並列度×2セットある。セット間のデータ交換用のバッファ・メモリーがSGAにあり Table Queueという。 SQL実行計画が複雑な場合、セット1
→ セット2 → セット1 → セット2 → ... と役割を入れ替えながらデータの垂直パイプラインを構成する。パラレル実行プロセスが実行計画の途中でデータ交換可能。 Oracleのパラレル実行プロセス Copyright © 2021, Oracle and/or its affiliates 52 パラレル実行プロセスセット1 Table Queue PX PX PX パラレル実行プロセスセット2 PX PX PX PX PX Oracleクライアント oracle Oracleサーバー・プロセスコーディネーターデータファイルの範囲を分割してアクセスデータ交換用バッファ・メモリー Table Queue

RACでもSQL実行計画の途中でパラレル実行プロセスがデータ交換可能 RACのパラレル実行プロセス Copyright © 2021, Oracle and/or its affiliates 53
Table Queue PX PX PX PX PX PX PX PX Oracleクライアント oracle ノード1 Table Queue Table Queue PX PX PX PX PX PX PX PX Table Queue ノード2

ダイレクト・パス・リードパラレル実行のようにサイズの大きなデータをフル・スキャンするときはバッファ・キャッシュをバイパスする。大量データをスキャンする場合バッファ・キャッシュがあふれて再利用されることが期待できないため。バッファ・キャッシュ管理もCPU時間を使用したソフトウェアの操作。バッファ・キャッシュに載せたデータをパラレル実行で読めるようにしたのは11g Release
2から。 1台のサーバーに搭載できるメモリーの容量が増えてきたから。フル・スキャンするセグメントのサイズとバッファ・キャッシュの容量からダイレクト・パス・リードするか自動判断。 Exadata Smart Scanはダイレクト・パス・リードの応用。大量アクセス系SQLでのストレージ・アクセスの最適化 Copyright © 2021, Oracle and/or its affiliates 54 パラレル実行プロセスセット1 Table Queue PX PX PX PX データファイルの範囲を分割してアクセスデータ交換用バッファ・メモリーデータベース・バッファ・キャッシュバッファ・キャッシュをバイパス

パラレル実行とデータのパーティショニングには強い関係があるパラレル実行プロセスはデータを範囲分割して並列アクセスする。データのパーティショニング • Oracle Databaseのパーティション表の性質 • クラスタ構成のアーキテクチャの違いがデータのパーティショニングに与える影響データのパーティショニング Copyright
© 2021, Oracle and/or its affiliates 56 PX PX PX PX

列の値が特定の条件を満たすグループに表を分割する SELECT * FROM t1 WHERE partition_key BETWEEN value1 AND
value2 パーティション・キー列の値が特定の条件を満たすグループ (パーティション)に表を分割する。 • RANGE 範囲 • LIST 離散値 • HASH 列値のハッシュ値 SQLのWHERE句の絞り込み条件がパーティションの条件に合致すると、該当するパーティションのみにアクセスする (パーティション・プルーニング)。分析および集計処理の表フル・スキャンが特定のパーティションのフル・スキャンに限定できる。パーティション表 Copyright © 2021, Oracle and/or its affiliates 57 パーティション1 表表ブロックパーティション2 パーティション3 パーティション・キー

パーティション定義が同じ表をパーティション・キー同士で結合結合(ジョイン)の並列化 – フル・パーティション・ワイズ結合 Copyright © 2021, Oracle and/or its
affiliates 58 パーティション1 パーティション2 パーティション3 パーティション・キーパーティション4 パーティション・キー SELECT * FROM t1 INNER JOIN t2 ON t1.partkey = t2. partkey 結合キーがパーティション・キーである場合、値が存在するパーティションが特定できる表1 表2 パーティション・キーの定義が同じ表パーティション1 パーティション2 パーティション3 パーティション4

パーティション定義が同じ表をパーティション・キー同士で結合結合(ジョイン)の並列化 – フル・パーティション・ワイズ結合 Copyright © 2021, Oracle and/or its
affiliates 59 表1 パーティション・キー表2 パーティション・キー SELECT * FROM t1 INNER JOIN t2 ON t1.partkey = t2. partkey パーティションごとの結合をデータ交換なしに並列実行可能 PX PX PX PX パーティション1 パーティション2 パーティション3 パーティション4 パーティション1 パーティション2 パーティション3 パーティション4

パーティション定義が異なる表の結合結合(ジョイン)の並列化 – パーシャル・パーティション・ワイズ結合 Copyright © 2021, Oracle and/or its
affiliates 61 Table Queueで再配分してパーティショニングパーティション・キー表2 パーティション・キー SELECT * FROM t1 INNER JOIN t2 ON t1.key = t2. partkey パーティションごとの結合をデータ交換なしに並列実行可能 PX PX PX PX パーティション1 パーティション2 パーティション3 パーティション4 表3 PX PX PX PX Table Queueを使ってPXプロセス間のデータ交換が可能

大量の行にアクセスする分析および集計処理の高速化パーティション・プルーニング SQLのWHERE句の絞り込み条件でアクセスする範囲を特定のパーティションに限定しIO時間の削減、高速化。処理量が表全体のサイズに影響されない。パーティション・ワイズ結合表の結合(ジョイン)がアクセスする範囲を特定のパーティションに限定する。パラレル実行と組み合わせることでさらに高速化が可能。パーティション化によるSQL処理の高速化
Copyright © 2021, Oracle and/or its affiliates 62 表1 表2

アクセス範囲が表全体のサイズに影響されないパーティション・プルーニング Copyright © 2021, Oracle and/or its affiliates 63
2020/01/01 2020/02/01 2020/03/01 2020/02/01 2020/01/01 2020/01/01 時間の経過パーティション追加パーティション追加 1か月単位で集計するのでパーティションを1か月単位で分割する想定例。表全体のサイズは増加していくが、SQLがアクセスする範囲は1か月分のパーティションに限定される。

パーティション表をさらにサブ・パーティションで分割可能 2段階のパーティション化が可能 • パーティションキーとサブ・パーティションキーはそれぞれ異なる列を指定できる • 2段階のパーティション・プルーニング、もしくはパーティション・プルーニングとパーティション・ワイズ結合が異なる列で可能 •
例: RANGE-HASHコンポジット・パーティション • RANGEでまずパーティション・プルーニング • HASHでパーティション・ワイズ結合 Oracle8iの時代(20世紀)には効果があった • フル・パーティション・ワイズ結合でプロセス間通信削減を狙う • 1コア/ソケット • 低帯域インターコネクト・ネットワークコンポジット・パーティション(Oracle8i～) Copyright © 2021, Oracle and/or its affiliates 64 表1 表2 パーティション・ワイズ結合パーティション・プルーニング

SQL実行計画の途中でデータ交換可能 SQL実行計画が複雑な場合、セット1 → セット2 → セット1 → セット2 →
... と役割を入れ替えながらデータの垂直パイプラインを構成する。パラレル実行プロセスがSQL実行計画の途中でデータ交換可能であるため、実行計画の早い段階でデータ量を間引くことが可能。ハードウェアの進化によりプロセス間通信の帯域が大幅に向上した。フル・パーティション・ワイズ結合でない場合でも十分高速に結合を並列化できるので結合キーのパーティショニング設計にあまりこだわらなくてもよい。 Oracleのパラレル実行プロセス Copyright © 2021, Oracle and/or its affiliates 65 パラレル実行プロセスセット1 Table Queue PX PX PX パラレル実行プロセスセット2 PX PX PX PX PX Oracleクライアント oracle Oracleサーバー・プロセスコーディネーターデータファイルの範囲を分割してアクセスデータ交換用バッファ・メモリー Table Queue

SQLに合わせた適切なパーティション・キーを見つけられるかがポイントパーティション・プルーニングは積極的に採用したいデータの分析には時間を範囲指定する場合が多い。時刻を記録する列をパーティション・キーとしたRANGE パーティションが適用できるケースは多い。フル・パーティション・ワイズ結合は狙わなくともよい非パーティション表同士の結合も並列化可能。パーティション・ワイズ結合に合わせたパーティショニングをしなくとも十分高速。 Oracle
Databaseのパーティション化による大量アクセス系SQL処理の高速化の方針 Copyright © 2021, Oracle and/or its affiliates 66 表1 表2

全ノードへのクエリーも可能、であるが... シェアード・ナッシング・クラスタがスケールする暗黙の前提は「ノード内で処理が完結する」パーティショニングしたシャード(ノード)間は通信しないのでデータ交換ができない。複数表のジョイン(結合)が必要なら同じパーティショニングができることが前提。 • フル・パーティション・ワイズ結合のみ可能 •
それができないなら実行計画の途中でデータを間引けないためコーディネーターまでデータを持ち越し Oracle Database Shardingはトランザクション系のためのアーキテクチャ。 Oracle Database Shardingのクロス・シャード・クエリー Copyright © 2021, Oracle and/or its affiliates 67 データベース・サーバー+ストレージのセットのスケールアウト表1 表2 シャードコーディネーターデータベース・クライアントクロス・シャード・クエリー network switch トランザクション系SQLはシャードに直接発行

Oracleクライアントから見るとシングル・インスタンスもRACも同じパラレル実行 • パラレル実行プロセスはデータのアクセスを範囲分割する • SQL実行計画の途中でデータ交換可能 • データをパーティショニングしなくともパラレル実行可能パーティショニング •
パーティション・プルーニングは積極的に採用したい • パーティション・ワイズ結合を狙ったパーティション・キー設計は必ずしも必要ではない大量アクセス系 Copyright © 2021, Oracle and/or its affiliates 69

データベース処理を高速にするにはデータの位置を短時間で特定する機能が必須トランザクション系少ない数のデータの位置を特定する - 索引大量アクセス系かなり多い数のデータの範囲を特定する - パーティショニング索引もパーティショニングもデータへのアクセス範囲を狭めるという目的
これら2つのデータ構造を共存させるには？トランザクション系と大量アクセス系を同居させるには Copyright © 2021, Oracle and/or its affiliates 71

索引は列値と行アドレスの組を持っている SQLがアクセスする行数が少ない場合、表ブロックをフル・スキャンするより索引ブロックをたどった方がはるかに少ないブロック数で行の位置を特定できる。表の各行は一意なROWIDという物理アドレスをエンコードした値を持っている。 B*-Tree索引は表の特定の列の全行の値をソートして列の値とその行へのアドレス(ROWID)の組を持っている。どの列に作成した索引も対等な関係にある。 PRIMARY
KEYの要件(UNIQUEかつNOT NULL)を満たせばどの索引でもPRIMARY KEYになり得る。二次索引はPRIMARY KEYの索引をたどるのではない。 Oracle Databaseの表と索引の構造 B*-Tree索引ブロック表表ブロック Copyright © 2021, Oracle and/or its affiliates 72 ROWID 列値

複数の表の集合でレンジ・パーティションを実装 Oracle7では複数の表をビューで結合しパーティショニングを実装していた。 • パーティション・キー列にCHECK制約を付けて値の範囲を指定 • 各表をUNION ALLするビューを作成 •
SQLにパーティション・キー列があると特定の表(パーティション)にのみアクセス(パーティション・プルーニングの動作) パーティショニングの実装: Oracle7 パーティション・ビュー Copyright © 2021, Oracle and/or its affiliates 73 パーティション・キー VIEW 表1 表2 表n CHECK制約でパーティション・キー列の値の範囲を指定 SELECT * FROM v1 WHERE partkey1 BETWEEN value1 AND value2

複数の表の集合でレンジ・パーティションを実装 – ローカル・パーティション索引しか作成できない Oracle7 パーティション・ビューに索引を作成 Copyright © 2021, Oracle and/or
its affiliates 74 パーティション・キー表1 表2 表n SELECT * FROM v1 WHERE partkey1 = val1 パーティション・キー列を含む索引パーティション・キー列を含まない索引 SELECT * FROM v1 WHERE non-partkey2 = val2 索引の実装は1つの表に閉じた行アドレスのポインタしか指せない ⇒ ローカル・パーティション索引しか作成できない表のパーティション・キー列を指定したときだけ特定の表にのみアクセス可能表のパーティション・キー列を指定しないと全パーティションの探索が必要 • パーティショニングしないほうがましだった • UNIQUE制約も作成できない

1つの表を複数に分割 – グローバル(・パーティション)索引も可能にパーティショニングの実装: Oracle8 パーティション表 Copyright © 2021, Oracle
and/or its affiliates 75 表パーティション・キー表パーティション1 SELECT * FROM v1 WHERE partkey1 = val1 表パーティション・キー列を含むローカル・パーティション索引表パーティション・キー列を含まないグローバル非パーティション索引 SELECT * FROM v1 WHERE non-partkey2 = val2 1つの表 ⇒ 表パーティションをまたがったグローバル索引が可能ローカル・パーティション索引は表のパーティション・キー列を指定したときだけ特定の表パーティションにのみアクセス可能表のパーティション・キー列を含まないSQL でも特定の表パーティションにのみアクセス • UNIQUE索引も作成可能 • 表パーティション・キーとPRIMARY KEYが異なる列でも構わない表パーティション2 表パーティションn 表パーティション・キー列を含まないグローバル・パーティション索引

大量アクセス系のためのパーティショニングとトランザクション系のための索引のデータ構造の重ね合わせが可能パーティショニングの実装: Oracle8 パーティション表 Copyright © 2021, Oracle and/or its
affiliates 76 表パーティション・キー表パーティション1 SELECT * FROM v1 WHERE partkey1 BETWEEN val1 and val2 表パーティション・キー列 • パーティション・プルーニング • パーティション・ワイズ結合表パーティション・キー列を含まないグローバル非パーティション索引 SELECT * FROM v1 WHERE non-partkey2 = val2 表パーティショニングと索引のアクセス・パスが独立した大量アクセス系表のパーティション・キー列は表フル・スキャン時にパーティション・プルーニングを効かせる列トランザクション系表パーティション・キーと関係ない索引設計が可能表パーティション2 表パーティションn 表パーティション・キー列を含まないグローバル・パーティション索引

トランザクション系のためのアーキテクチャシェアード・ナッシング・クラスタがスケールする暗黙の前提は「ノード内で処理が完結する」パーティショニングしたシャード(ノード)間は通信しないのでデータ交換ができない。 • 表のプライマリ・キーがパーティション・キー • グローバル索引が作成できない複数表のジョイン(結合)が必要なら同じパーティショニング
ができることが前提。全シャードに同じデータを複製するDUPLICATED TABLEが用意されているが更新には向いていない。表の結合キーとプライマリ・キーのパーティション設計をうまくできることが必須。 Oracle Database Sharding Copyright © 2021, Oracle and/or its affiliates 77 データベース・サーバー+ストレージのセットのスケールアウト表1 表2 シャードデータベース・クライアントトランザクション系SQLはシャードに直接発行

データ・モデルとクラスタ・ノード構成が分離されているアプリケーション開発で本来気にするべきは抽象概念のデータ・モデルと結果集合を定義するSQLインターフェースであって、クラスタ構成の実装の制約を受けるべきではない。データ構造の一種である索引やパーティショニングはSQL 実行計画のアルゴリズムのためであって、クラスタのノード構成とは別の話。 RACはデータの配置がデータベース・サーバーと結びついていない。
シェアード・ナッシング・クラスタはデータの配置がサーバーとストレージに強固に結びついている。 Oracle Real Application Clusters(再掲) Copyright © 2021, Oracle and/or its affiliates 79 データ・モデル/SQL 抽象実装データ構造/クラスタ構成インターフェースと実装の分離

主要なデータ・タイプとデータ・モデルに対応 Oracle Databaseはマルチ・モデルをサポート(再掲) 利用者にとって重要なことデータ一貫性すぐに分析可能であることセキュリティの確保信頼性スケーラビリティ JSON
Graph Text リレーショナル Spatial Oracle Database Blockchain Copyright © 2021 Oracle and/or its affiliates 開発者にとって重要なこと適性なデータ・モデル宣言的なSQLでアクセストランザクション主要な開発言語をサポート標準化されたAPIで開発 Copyright © 2021, Oracle and/or its affiliates 80

マイクロサービス・アーキテクチャが言っているのは「サービスごとにデータストアを分離する」であってこれはアクセス境界の話。マルチ・モデル/マルチ・ワークロード対応のデータベースが使用できるのと、必ず分離される単機能データベースとでは設計の選択肢の幅が大きく異なる。マイクロサービス・アーキテクチャとConverged Databaseの話は矛盾しない Copyright ©
2020, Oracle and/or its affiliates 81 switch switch

Exadataは市場で調達可能な部品のみで構成されている ⇒ クラウドを構成する部品もこういうものいまどきのハードウェアの物量 Copyright © 2021, Oracle and/or its
affiliates 82 ネットワーク・スイッチ 42RUラックにIntel Xeon 2ソケットの • 1RUのデータベース・サーバー8台 • 2RUのストレージ・サーバー14台データベース・サーバーストレージ・サーバー Intel Xeon 24コア×2ソケット DRAM 64GB×24枚=1.5TB HDD 14TB×12台=168TB Flash 6.4TB×4枚=25.6TB PMEM 128GB×12枚=1.5TB 100Gbps/link

私たちのミッションは、人々が新たな方法でデータを理解し、本質を見極め、無限の可能性を解き放てるよう支援していくことです。 Our mission is to help people see
data in new ways, discover insights, unlock endless possibilities. 83 Copyright © 2021, Oracle and/or its affiliates |

OracleDatabaseTechnologyNight42RAC

OracleDatabaseTechnologyNight42RAC

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript