OracleDatabaseTechnologyNight42RAC

Oracle Database Technology Night #42 Oracle Real Application Clusters
RACはなぜクラスタ構成でトランザクション系と大量アクセス系を同居させることができるのか。
Converged Database、コンバージド・データベース、Cache Fusion、パラレル実行、パーティショニング、パーティション、並列化、シェアード・ナッシング・クラスタ、シェアード・エブリシング・クラスタ

Transcript

1. Oracle Database Technology Night #42 Oracle Real Application Clusters Converged Databaseを可能にするもの 2021年3月30日 日本オラクル株式会社 日下部明
2. Converged Database • マルチ・モデル • マルチ・ワークロード Oracle Real Application Clusters • アーキテクチャ • マルチ・ワークロード(トランザクション系と大量アクセス系)を同居させるには？ アジェンダ Copyright © 2021, Oracle and/or its affiliates 2
3. 将来変化するであろうビジネス要件に柔軟に対応を可能に オラクルの戦略 | お客様に世界で最も優れたConverged Databaseを提供 3 開発者およびアナリストにとって最も生産性を高く 統合されたマイクロサービス, イベント, REST, SaaS, 機械学習, CI/CD, ローコード開発環境 多くのワークロード・タイプをサポート トランザクション, データ分析, 機械学習, IoT, ストリーミング, ブロックチェイン 多くのデータ・タイプとデータ・モデルをサポート リレーショナル, JSON, グラフ, 位置情報, テキスト, OLAP, XML Copyright © 2021 Oracle and/or its affiliates
4. 主要なデータ・タイプとデータ・モデルに対応 Oracle Databaseはマルチ・モデルをサポート 利用者にとって重要なこと データ一貫性 すぐに分析可能であること セキュリティの確保 信頼性 スケーラビリティ JSON Graph Text リレーショナル Spatial Oracle Database Blockchain Copyright © 2021 Oracle and/or its affiliates 開発者にとって重要なこと 適性なデータ・モデル 宣言的なSQLでアクセス トランザクション 主要な開発言語をサポート 標準化されたAPIで開発 4
5. Oracle Databaseがサポートする主要なデータ・タイプとデータ・モデル Copyright © 2021, Oracle and/or its affiliates 5 リレーショナル • 表形式 • 数値・文字 • SQLアクセス • 複雑な問い合わせ Spatial • 座標・ポリゴンなど 空間情報 • GPSなどの 座標情報の活用 Text • テキストもしくは ドキュメント・データ の全文検索 JSON • テキストベースの データ交換用の フォーマット • シンプルで使いやす いデータ形式 Graph • ノードとエッジの 関係性 • 関係性の検索など 高速で実現 Blockchain • データの改ざんを 前後のデータの つながりで防止 • 監査証跡、 トレーサビリティなど
6. 1つのデータベースで複数のワークロードを同時に処理でき、リアルタイムなデータ分析を実現 オンライン・トランザクション処理 • トレーディング・システムや ショッピング・サイトなど • 同時、大量ユーザー、低レイテンシ 分析処理 • ペタバイト級のデータ・ウェアハウス など • 大量データ、大量処理 IoT • 各種センサーから情報を受け取 るストリーミング処理 • 大量デバイス、超低レイテンシ • 時系列分析 リアルタイム・アナリティクス • 超高速インメモリ分析 • 機械学習 • グラフ分析 Oracle Databaseはマルチ・ワークロードをサポート Copyright © 2021, Oracle and/or its affiliates 6
7. Oracle Real Application ClustersはなぜConverged Databaseを可能にするのか パフォーマンスとアプリケーション開発 • なぜトランザクション系と大量アクセス系を混在できるのか • なぜデータ・モデルをパーティション分割せずに配置できるのか • なぜクラスタ構成なのにアプリケーションから透過的なのか 可用性 • なぜ障害発生から短時間で全データへのアクセスを再開できるのか 透過性 • なぜクライアントから見てノード構成を隠蔽できるのか 今日お話したいこと Copyright © 2021, Oracle and/or its affiliates 7
8. Copyright © 2021, Oracle and/or its affiliates 8 Oracle Real Application Clustersアーキテクチャ
9. RACの物理構成 Copyright © 2021, Oracle and/or its affiliates 9 ストレージ・ネットワーク インターコネクト・ネットワーク パブリック・ネットワーク データベース・クライアント クライアントとの通信 ストレージ・ノード • ストレージ・デバイス コンピュート・ノード • CPU+メモリー • 全ノードが対等な関係 コンピュート・ノード間の通信 全コンピュート・ノードは全ストレージにアクセス可能
10. データ・モデル(スキーマ構造)、トランザクション分離レベルの挙動も同じ クライアントはどのノードに接続してもシングル・インスタンス構成と同じアクセスが可能 Copyright © 2021, Oracle and/or its affiliates 10 ストレージ・ノード • ストレージ・デバイス コンピュート・ノード • CPU+メモリー • 全ノードが対等な関係 インターコネクト・ネットワーク コンピュート・ノード間の通信 全コンピュート・ノードは全ストレージにアクセス可能 パブリック・ネットワーク データベース・クライアント クライアントとの通信 ストレージ・ネットワーク メモリー一貫性を全自 動で維持 oracle クライアントが接続した ノードのプロセスがSQL 処理
11. サーバーがクラッシュしてもクライアントは別ノードに接続すると全データにアクセス可能 クライアントはどのノードに接続してもシングル・インスタンス構成と同じアクセスが可能 Copyright © 2021, Oracle and/or its affiliates 11 ストレージ・ノード • ストレージ・デバイス コンピュート・ノード • CPU+メモリー • 全ノードが対等な関係 インターコネクト・ネットワーク コンピュート・ノード間の通信 全コンピュート・ノードは全ストレージにアクセス可能 パブリック・ネットワーク データベース・クライアント クライアントとの通信 ストレージ・ネットワーク メモリー一貫性を全自 動で維持 oracle クライアントが接続した ノードのプロセスがSQL 処理 oracle
12. データ・モデル(スキーマ構造)、トランザクション分離レベルの挙動も同じ 全ノードを使用した1つのSQL処理の並列化が可能 Copyright © 2021, Oracle and/or its affiliates 12 ストレージ・ノード • ストレージ・デバイス コンピュート・ノード • CPU+メモリー • 全ノードが対等な関係 インターコネクト・ネットワーク コンピュート・ノード間の通信 全コンピュート・ノードは全ストレージにアクセス可能 パブリック・ネットワーク データベース・クライアント クライアントとの通信 ストレージ・ネットワーク パラレル実行プロセスが データ交換しながら並 列実行 oracle PX PX PX PX PX PX 接続したノードの Oracleサーバー・プロセ スがコーディネーター
13. Copyright © 2021, Oracle and/or its affiliates 13 「データベース」とは制御ファイル、(オンライン)REDOログ・ファイル、データファイルの集合をあらわす シングル・インスタンス構成のデータベース・ファイル構造 REDOログ・ ファイル 制御ファイル データファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データファイル (UNDO表領域) Oracle インスタンス
14. 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
15. Copyright © 2021, Oracle and/or its affiliates 15 「データベース」はストレージ上のファイル群を指す言葉 Non-CDB構成のファイル構造 REDOログ・ファイル 制御ファイル データファイル (表領域) SYSTEM UNDO SYSAUX TEMP USERS データベース REDOログ・ファイルとUNDO表領域は Oracleインスタンスごとに存在する UNDO ×Oracleインスタンス数
16. 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インスタンス数 プラガブル・データベースは データファイルのみの集合
17. 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
18. 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でスケール・アウト
19. その問題を解決するために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 • ストレージ筐体の障害にも対応
20. Copyright © 2021, Oracle and/or its affiliates 20 RACはなぜマルチ・ワークロードが可能なのか
21. インターフェースとアルゴリズムの実装が分離されている SQL • 入力と出力の対応関係のみ記述(宣言型) • インターフェースの定義 SQL実行計画 • SQLが定義した対応関係を導出するアルゴリズム • 全体最適化されたアルゴリズムをDBMSが自動生成 SQL実行計画の部分を構成するアルゴリズム実装 • 索引、パーティショニング、... • ネステッド・ループ結合、ハッシュ結合、... • 並列化 • ... SQLの実行モデル Copyright © 2021, Oracle and/or its affiliates 21 PX PX PX PX 索引 パーティショニング 結合 並列化 入力 出力 SQL実行計画 結果の正しさ(SQL)に手を付けずに実装を改良できる 対応関係
22. データ・モデルとクラスタ・ノード構成が分離されている アプリケーション開発で本来気にするべきは抽象概念の データ・モデルと結果集合を定義するSQLインターフェース であって、クラスタ構成の実装の制約を受けるべきではな い。 データ構造の一種である索引やパーティショニングはSQL 実行計画のアルゴリズムのためであって、クラスタのノード 構成とは別の話。 RACはデータの配置がデータベース・サーバーと結びついて いない。 シェアード・ナッシング・クラスタはデータの配置がサーバーと ストレージに強固に結びついている。 Oracle Real Application Clusters Copyright © 2021, Oracle and/or its affiliates 22 データ・モデル/SQL 抽象 実装 データ構造/クラスタ構成
23. RACはデータ・モデルと物理配置が結びついていないのでパーティショニングは必須ではない クラスタ・アーキテクチャとデータ配置 Copyright © 2021, Oracle and/or its affiliates 23 データ・モデル ストレージのスケールアウト データベース・サーバーのスケールアウト データベース・サーバー+ストレージのセットのスケールアウト Oracle Real Application Clusters Oracle Database Sharding データのパーティショニング必須 (物理配置と強い結びつき) データ・モデルをそのまま配置可能 (パーティショニングを問わない)
24. 性質の異なる処理を同居させるには トランザクション系 大量アクセス系 データ・アクセスの性質に求めるもの 低レイテンシ 並行性/一貫性制御 高スループット 計算量のオーダー 性能最適化の技術要素 キャッシング 索引 ... 並列化 パーティショニング ... マルチ・ワークロード Copyright © 2021, Oracle and/or its affiliates 24 PX PX PX PX クラスタ構成で性質の異なる最適化を同居させるには？
25. Copyright © 2021, Oracle and/or its affiliates 25 トランザクション系 Cache Fusion
26. Copyright © 2021, Oracle and/or its affiliates 26 Oracleサーバー・プロセスがメモリを操作しバックグラウンド・プロセスがファイルに永続化 Oracle Databaseアーキテクチャ(シングル・インスタンス) オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス DBWn データベース・ライター・プロセス データファイル 更新履歴(REDOログ情報)はOracle サーバー・プロセスによって生成され REDOログ・バッファに置かれる オンラインREDOログ・ファイルに永続化 データ・ファイルに永続化 データ操作はデータベース・バッファ・ キャッシュ上のデータ・ブロックにアクセス SGA REDOログ・バッファ データベース・バッファ・キャッシュ
27. Copyright © 2021, Oracle and/or its affiliates 27 バッファ・キャッシュ・ミスするとOracleサーバー・プロセスがストレージからデータ・ブロックを取得 Oracle Databaseアーキテクチャ(シングル・インスタンス) オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス DBWn データベース・ライター・プロセス データファイル SGA バッファ・キャッシュ・ミスするとOracleサーバー・ プロセスがストレージからデータブロックを取得し バッファ・キャッシュに乗せる REDOログ・バッファ データベース・バッファ・キャッシュ
28. Copyright © 2021, Oracle and/or its affiliates 28 バッファ・キャッシュ・ミスすると別のOracleインスタンスからデータ・ブロックを取得 Oracle Databaseアーキテクチャ(RAC) REDOログ・バッファ オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス データベース・バッファ・キャッシュ DBWn データベース・ライター・プロセス データファイル SGA バッファ・キャッシュ・ミスすると別のOracleインス タンスがキャッシュしているデータブロックを取得 しバッファ・キャッシュに乗せる
29. Copyright © 2021, Oracle and/or its affiliates 29 Oracleサーバー・プロセスから見るとローカルのデータベース・バッファ・キャッシュを操作しているだけ Oracleクライアントからはシングル・インスタンスもRACも同じに見える REDOログ・バッファ オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス データベース・バッファ・キャッシュ DBWn データベース・ライター・プロセス データファイル SGA データ操作はデータベース・バッファ・ キャッシュ上のデータ・ブロックにアクセス バッファ・キャッシュ・ミスしたときに どこから取得するかの違い バッファ・キャッシュ・ミスしたときに どこから取得するかの違い
30. Oracle Real Application Clusters SGA ユーザーからは透過的に複数CPUで処理可能 共有メモリー型マルチ・プロセッサ RACのアーキテクチャは共有メモリー型マルチ・プロセッサと同じくキャッシュ一貫性を維持 Copyright © 2021, Oracle and/or its affiliates 30 ノード1 (キャッシュ) ノード2 (キャッシュ) データベース (ストレージ上のファイル群) SGA キャッシュ一貫性 キャッシュ・メモリー キャッシュ・メモリー キャッシュ一貫性 CPU 1 CPU 2 SGA DRAM (メイン・メモリー)
31. 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
32. 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)依頼
33. 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)モードでキャッシュしている間は複数インスタンスで同時に 読み取り可能 索引ブロックのルートに近い方はあまり更新が発生しない
34. 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
35. 異なるデータ・ブロックへのアクセス データへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 35 Oracle Real Application Clusters Oracle Database Sharding X X X X X X 異なるデータ・ブロックへのアクセスは全シャード で並列に実行可能 クライアント サーバー 異なるデータ・ブロックへのアクセスは全ノードで 並列に実行可能
36. 同じデータ・ブロックへの更新アクセス データへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 36 Oracle Real Application Clusters Oracle Database Sharding X X データ・ブロックを更新する瞬間だけ1つのインス タンスが排他ロックする 1つのデータ・ブロックは1つのシャードしか持って いない クライアント サーバー ※DUPLICATED TABLEは全ノードで同じ レプリカを持つが更新に向いていない
37. 同じデータ・ブロックへの読み取りアクセス データへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 37 Oracle Real Application Clusters Oracle Database Sharding S S S X クライアント サーバー 1つのデータ・ブロックは1つのシャードしか持って いない 同じデータ・ブロックへの読み取りアクセスは全 ノードで並列に実行可能 ※DUPLICATED TABLEは全ノードで同じ レプリカを持つが更新に向いていない
38. データ・アクセスの分布に暗黙の前提がある データへのアクセス・パターンとスケーラビリティ Copyright © 2021, Oracle and/or its affiliates 38 Oracle Real Application Clusters Shared-Nothing Cluster 異なるデータへのアクセス分布が比較的均等 シャード(パーティション)をまたぐアクセスに弱い クライアント サーバー ほとんどのアクセス・パターンに対応
39. Copyright © 2021, Oracle and/or its affiliates 39 SQL処理時間はメモリー操作なので極めて小さいがCOMMITはファイル書き込み時間が必要 トランザクション系処理 REDOログ・バッファ オンラインREDOログ・ファイル LGWR oracle Oracleサーバー・プロセス(SQL処理の主体) ログ・ライター・プロセス データベース・バッファ・キャッシュ DBWn データファイル COMMITはI/Oを伴う データ操作SQLはほぼメモリー操作だけ SGA バッファ・キャッシュが十分大きければ キャッシュ・ミスの影響は小さい レイテンシーを下げにくい
40. ストレージ プロセスから見たレイテンシー 一般的なストレージの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
41. ストレージに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台あたりのストレージ・デバイス
42. ストレージ データベース・サーバー 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
43. 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サーバー・ プロセス ログ・ライター・ プロセス セカンダリ・エクステント
44. 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に減る
45. Oracleクライアントから見るとシングル・インスタンスもRACも同じ バッファ・キャッシュ・ミスしたときのどこからデータブロックを取得するか • ストレージ • 別のOracleインスタンス SQL実行 • ほぼメモリの更新 • Oracleサーバー・プロセスの中で経過する時間はとても短い COMMIT • ストレージへの書き込み完了を待つ • Exadata X8MのPersistent MemoryとRDMAによるREDOログ書き込み完了時間はとても短い トランザクション系 Copyright © 2021, Oracle and/or its affiliates 45
46. Copyright © 2021, Oracle and/or its affiliates 46 前半終了
47. Copyright © 2021, Oracle and/or its affiliates 47 大量アクセス系 Internode Parallel Execution Partitioning
48. 1つの処理が大量のデータにアクセスする • パラレル実行 • アクセス範囲の削減(パーティショニング) • 複数ある表の結合(ジョイン) 大量アクセス系 Copyright © 2021, Oracle and/or its affiliates 48
49. 大量データの処理を分割し、複数のハードウェア(CPU/ストレージ)に 割り当てて同時に実行することで、全体の処理時間を短縮する技法 パラレル実行 Copyright © 2021, Oracle and/or its affiliates 49 並列度 処理時間 並列度1 並列度2 並列度4
50. 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桁の並列度を可能にした
51. データ操作の分析/集計処理や大量一括更新に対応 • 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
52. シングル・インスタンス 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
53. 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
54. ダイレクト・パス・リード パラレル実行のようにサイズの大きなデータをフル・スキャン するときはバッファ・キャッシュをバイパスする。 大量データをスキャンする場合バッファ・キャッシュがあふれ て再利用されることが期待できないため。 バッファ・キャッシュ管理もCPU時間を使用したソフトウェア の操作。 バッファ・キャッシュに載せたデータをパラレル実行で読める ようにしたのは11g Release 2から。 1台のサーバーに搭載できるメモリーの容量が増えてきたか ら。 フル・スキャンするセグメントのサイズとバッファ・キャッシュの 容量からダイレクト・パス・リードするか自動判断。 Exadata Smart Scanはダイレクト・パス・リードの応用。 大量アクセス系SQLでのストレージ・アクセスの最適化 Copyright © 2021, Oracle and/or its affiliates 54 パラレル実行プロセス セット1 Table Queue PX PX PX PX データファイルの範囲を 分割してアクセス データ交換用バッファ・ メモリー データベース・バッファ・キャッシュ バッファ・キャッシュを バイパス
55. Copyright © 2021, Oracle and/or its affiliates 55 データのパーティショニング パラレル実行とデータのパーティショニングには強い関係がある
56. パラレル実行とデータのパーティショニングには強い関係がある パラレル実行プロセスはデータを範囲分割して並列アクセスする。 データのパーティショニング • Oracle Databaseのパーティション表の性質 • クラスタ構成のアーキテクチャの違いがデータのパーティショニングに与える影響 データのパーティショニング Copyright © 2021, Oracle and/or its affiliates 56 PX PX PX PX
57. 列の値が特定の条件を満たすグループに表を分割する 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 パーティション・キー
58. パーティション定義が同じ表をパーティション・キー同士で結合 結合(ジョイン)の並列化 – フル・パーティション・ワイズ結合 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
59. パーティション定義が同じ表をパーティション・キー同士で結合 結合(ジョイン)の並列化 – フル・パーティション・ワイズ結合 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
60. フル・パーティション・ワイズ結合になるパーティション設計ができるとは限らない 結合(ジョイン)の並列化 Copyright © 2021, Oracle and/or its affiliates 60 表1 パーティション・キー 表2 パーティション・キー 表3 フル・パーティション・ワイズ結合 フル・パーティション・ワイズ結合にならない
61. パーティション定義が異なる表の結合 結合(ジョイン)の並列化 – パーシャル・パーティション・ワイズ結合 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プロ セス間のデータ交換が可能
62. 大量の行にアクセスする分析および集計処理の高速化 パーティション・プルーニング SQLのWHERE句の絞り込み条件でアクセスする範囲を 特定のパーティションに限定しIO時間の削減、高速化。 処理量が表全体のサイズに影響されない。 パーティション・ワイズ結合 表の結合(ジョイン)がアクセスする範囲を特定の パーティションに限定する。 パラレル実行と組み合わせることでさらに高速化が可能。 パーティション化によるSQL処理の高速化 Copyright © 2021, Oracle and/or its affiliates 62 表1 表2
63. アクセス範囲が表全体のサイズに影響されない パーティション・プルーニング 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か月分のパーティションに限定される。
64. パーティション表をさらにサブ・パーティションで分割可能 2段階のパーティション化が可能 • パーティションキーとサブ・パーティションキーは それぞれ異なる列を指定できる • 2段階のパーティション・プルーニング、 もしくはパーティション・プルーニングと パーティション・ワイズ結合が異なる列で可能 • 例: RANGE-HASHコンポジット・パーティション • RANGEでまずパーティション・プルーニング • HASHでパーティション・ワイズ結合 Oracle8iの時代(20世紀)には効果があった • フル・パーティション・ワイズ結合でプロセス間通信 削減を狙う • 1コア/ソケット • 低帯域インターコネクト・ネットワーク コンポジット・パーティション(Oracle8i～) Copyright © 2021, Oracle and/or its affiliates 64 表1 表2 パーティション・ワイズ結合 パーティション・プルーニング
65. 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
66. SQLに合わせた適切なパーティション・キーを見つけられるかがポイント パーティション・プルーニングは積極的に採用したい データの分析には時間を範囲指定する場合が多い。 時刻を記録する列をパーティション・キーとしたRANGE パーティションが適用できるケースは多い。 フル・パーティション・ワイズ結合は狙わなくともよい 非パーティション表同士の結合も並列化可能。 パーティション・ワイズ結合に合わせたパーティショニングをし なくとも十分高速。 Oracle Databaseのパーティション化による大量アクセス系SQL処理の高速化の方針 Copyright © 2021, Oracle and/or its affiliates 66 表1 表2
67. 全ノードへのクエリーも可能、であるが... シェアード・ナッシング・クラスタがスケールする暗黙の前提 は「ノード内で処理が完結する」 パーティショニングしたシャード(ノード)間は通信しないので データ交換ができない。 複数表のジョイン(結合)が必要なら同じパーティショニング ができることが前提。 • フル・パーティション・ワイズ結合のみ可能 • それができないなら実行計画の途中でデータを間引け ないためコーディネーターまでデータを持ち越し Oracle Database Shardingはトランザクション系のため のアーキテクチャ。 Oracle Database Shardingのクロス・シャード・クエリー Copyright © 2021, Oracle and/or its affiliates 67 データベース・サーバー+ストレージのセットのスケールアウト 表1 表2 シャード コーディネーター データベース・クライアント クロス・シャード・クエリー network switch トランザクション系SQLは シャードに直接発行
68. RACはデータ・モデルと物理配置が結びついていないのでパーティショニングは必須ではない クラスタ・アーキテクチャとデータ配置(再掲) Copyright © 2021, Oracle and/or its affiliates 68 データ・モデル ストレージのスケールアウト データベース・サーバーのスケールアウト データベース・サーバー+ストレージのセットのスケールアウト Oracle Real Application Clusters Oracle Database Sharding データのパーティショニング必須 (物理配置と強い結びつき) データ・モデルをそのまま配置可能 (パーティショニングを問わない)
69. Oracleクライアントから見るとシングル・インスタンスもRACも同じ パラレル実行 • パラレル実行プロセスはデータのアクセスを範囲分割する • SQL実行計画の途中でデータ交換可能 • データをパーティショニングしなくともパラレル実行可能 パーティショニング • パーティション・プルーニングは積極的に採用したい • パーティション・ワイズ結合を狙ったパーティション・キー設計は必ずしも必要ではない 大量アクセス系 Copyright © 2021, Oracle and/or its affiliates 69
70. Copyright © 2021, Oracle and/or its affiliates 70 トランザクション系と大量アクセス系の同居
71. データベース処理を高速にするにはデータの位置を短時間で特定する機能が必須 トランザクション系 少ない数のデータの位置を特定する - 索引 大量アクセス系 かなり多い数のデータの範囲を特定する - パーティショニング 索引もパーティショニングもデータへのアクセス範囲を狭めるという目的 これら2つのデータ構造を共存させるには？ トランザクション系と大量アクセス系を同居させるには Copyright © 2021, Oracle and/or its affiliates 71
72. 索引は列値と行アドレスの組を持っている 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 列値
73. 複数の表の集合でレンジ・パーティションを実装 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
74. 複数の表の集合でレンジ・パーティションを実装 – ローカル・パーティション索引しか作成できない 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制約も作成できない
75. 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 表パーティション・キー列を含まない グローバル・パーティション索引
76. 大量アクセス系のためのパーティショニングとトランザクション系のための索引のデータ構造の重ね合わせが可能 パーティショニングの実装: 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 表パーティション・キー列を含まない グローバル・パーティション索引
77. トランザクション系のためのアーキテクチャ シェアード・ナッシング・クラスタがスケールする暗黙の前提 は「ノード内で処理が完結する」 パーティショニングしたシャード(ノード)間は通信しないので データ交換ができない。 • 表のプライマリ・キーがパーティション・キー • グローバル索引が作成できない 複数表のジョイン(結合)が必要なら同じパーティショニング ができることが前提。 全シャードに同じデータを複製するDUPLICATED TABLEが用意されているが更新には向いていない。 表の結合キーとプライマリ・キーのパーティション設計をうま くできることが必須。 Oracle Database Sharding Copyright © 2021, Oracle and/or its affiliates 77 データベース・サーバー+ストレージのセットのスケールアウト 表1 表2 シャード データベース・クライアント トランザクション系SQLは シャードに直接発行
78. RACはデータ・モデルと物理配置が結びついていないのでパーティショニングは必須ではない クラスタ・アーキテクチャとデータ配置(再掲) Copyright © 2021, Oracle and/or its affiliates 78 データ・モデル ストレージのスケールアウト データベース・サーバーのスケールアウト データベース・サーバー+ストレージのセットのスケールアウト Oracle Real Application Clusters Oracle Database Sharding データのパーティショニング必須 (物理配置と強い結びつき) データ・モデルをそのまま配置可能 (パーティショニングを問わない)
79. データ・モデルとクラスタ・ノード構成が分離されている アプリケーション開発で本来気にするべきは抽象概念の データ・モデルと結果集合を定義するSQLインターフェース であって、クラスタ構成の実装の制約を受けるべきではな い。 データ構造の一種である索引やパーティショニングはSQL 実行計画のアルゴリズムのためであって、クラスタのノード 構成とは別の話。 RACはデータの配置がデータベース・サーバーと結びついて いない。 シェアード・ナッシング・クラスタはデータの配置がサーバーと ストレージに強固に結びついている。 Oracle Real Application Clusters(再掲) Copyright © 2021, Oracle and/or its affiliates 79 データ・モデル/SQL 抽象 実装 データ構造/クラスタ構成 インターフェースと実装の分離
80. 主要なデータ・タイプとデータ・モデルに対応 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
81. マイクロサービス・アーキテクチャが言っているのは「サービス ごとにデータストアを分離する」であってこれはアクセス境界 の話。 マルチ・モデル/マルチ・ワークロード対応のデータベースが 使用できるのと、必ず分離される単機能データベースとで は設計の選択肢の幅が大きく異なる。 マイクロサービス・アーキテクチャとConverged Databaseの話は矛盾しない Copyright © 2020, Oracle and/or its affiliates 81 switch switch
82. 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
83. 私たちのミッションは、人々が新たな方法で データを理解し、本質を見極め、無限の可能性 を解き放てるよう支援していくことです。 Our mission is to help people see data in new ways, discover insights, unlock endless possibilities. 83 Copyright © 2021, Oracle and/or its affiliates |