Oracle Exadataのパフォーマンス　Part1：Cell Offloading

投稿日: 2015年2月14日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

Oracle Exadataのパフォーマンスは次のサブセットに分割されます。

●Cell Offloading
　　・Smart Scan
　　・Storage Indexes
　　・HCC(Hybrid Columnar Compression）
●DBRM/IORM
●Smart Flash Cache
●更なるモニターとクエリーによるチューニング

Cell offloading (またはoffloading）はExadataの前にデータベース段階で行われたであろうものがストレージ段階で行われているものを記述するための一般的な用語です。これはおそらく、Exadataを選択する最大の利点です。

Smart Scanでは、Exadataマシン・オペレーションの一部はデータベースにより少ないデータを戻し、I/Oを減少させます。ユーザは「Cell Smart Table Scan」と 「Cell Smart Index Scan」の2つのウェイト・イベントで、Smart Scanをモニターすることができます。Smart Scanからのデータ・フローはSGAプールにバファーできないので、これがデータを高速にリターンする理由の1つです。

SmartScan

ストレージ・インデックス（Storage index）はSmart Scanと連携しています。ストレージ・インデックスの目的はデータ量を削減することではなく、データをリードする時間を削減するようにデザインされたいます。ストレージ・インデックスは物理セル・ストレージの特定領域内のデータについて情報を保持するイン・メモリー構造です。これらはストレージ・サーバへクエリー述語を受け渡し、ストレージ・インデックスは各1MBストレージ領域の値のマップを保持しているのでプレ・フィルターとして考えてください。一致する行を含めることができない任意の領域はリードすることなく除外することができます。またストレージ・インデックスはパーティションのタイプの1つと考えられます。ディスクI/ Oは、パーティション除去に類似した方法で除去されます。パーティションは関連するレコードを含むことができないなら、パーティションのブロックはリードされません。同様にストレージ領域が関連するレコードを含んでいなければ、ストレージ領域はリードされません。これはよくOLAPシステムに使用されます。本質的にユーザはストレージ・インデックスを作成することはできません。ストレージ・セルが繰り返しリクエストを受け取った後に自動的に作成されます。これらのインデックスはメモリーに保存されるので、Exadata のリブート後には消えて、再構築する必要があります。

HCC (Hybrid Columnar Compression)は保存したデータの行と列順序方式の両方を組み合せを利用した技術です。HCC行のセットに保存された「compression unit」と呼ぶロジカル構成を作成することで行われます。データがロードされた時に行セット用の列バリューは一緒にグループ化され、圧縮されます。行セット用の列バリューは圧縮後に圧縮ユニットにストアーされます。ローディングのスピードを最大化するためにはユーザは「DW」ローディング技術を使用する必要があります。従来型のDML (Data Manipulation Language)オペレーションを愛用することもできますが、ロードは遅くなります。3つのタイプのHCCがあります。最初のQuery LowはLZO圧縮アルゴリズムを使用し、4x圧縮率が想定されています。2番目がQuery Highでzlibまたは gzipを使用し、6x圧縮率があります。3番目がArchive Lowで、gZipを使用し、高圧縮レベルです。この3つ目のオプションはロードが難しく、パーティションまたはデータセットがアップデートされない後にロードしなければ使用されません。

関連したトピックス