OracleDatabaseTechnologyNight42RAC

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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インスタンス数プラガブル・データベースはデータファイルのみの集合

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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でスケール・アウト

Slide 19

Slide 19 text

その問題を解決するために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 • ストレージ筐体の障害にも対応

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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)依頼

Slide 33

Slide 33 text

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)モードでキャッシュしている間は複数インスタンスで同時に読み取り可能索引ブロックのルートに近い方はあまり更新が発生しない

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

ストレージプロセスから見たレイテンシー一般的なストレージの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

Slide 41

Slide 41 text

ストレージに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台あたりのストレージ・デバイス

Slide 42

Slide 42 text

ストレージデータベース・サーバー 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

Slide 43

Slide 43 text

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サーバー・プロセスログ・ライター・プロセスセカンダリ・エクステント

Slide 44

Slide 44 text

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に減る

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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桁の並列度を可能にした

Slide 51

Slide 51 text

データ操作の分析/集計処理や大量一括更新に対応 • 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

Slide 52

Slide 52 text

シングル・インスタンス 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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

列の値が特定の条件を満たすグループに表を分割する 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 パーティション・キー

Slide 58

Slide 58 text

パーティション定義が同じ表をパーティション・キー同士で結合結合(ジョイン)の並列化 – フル・パーティション・ワイズ結合 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

Slide 59

Slide 59 text

パーティション定義が同じ表をパーティション・キー同士で結合結合(ジョイン)の並列化 – フル・パーティション・ワイズ結合 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

Slide 60

Slide 60 text

Slide 61

Slide 61 text

パーティション定義が異なる表の結合結合(ジョイン)の並列化 – パーシャル・パーティション・ワイズ結合 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プロセス間のデータ交換が可能

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

アクセス範囲が表全体のサイズに影響されないパーティション・プルーニング 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か月分のパーティションに限定される。

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

索引は列値と行アドレスの組を持っている 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 列値

Slide 73

Slide 73 text

複数の表の集合でレンジ・パーティションを実装 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

Slide 74

Slide 74 text

複数の表の集合でレンジ・パーティションを実装 – ローカル・パーティション索引しか作成できない 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制約も作成できない

Slide 75

Slide 75 text

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 表パーティション・キー列を含まないグローバル・パーティション索引

Slide 76

Slide 76 text

大量アクセス系のためのパーティショニングとトランザクション系のための索引のデータ構造の重ね合わせが可能パーティショニングの実装: 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 表パーティション・キー列を含まないグローバル・パーティション索引

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

主要なデータ・タイプとデータ・モデルに対応 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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

No content