アシストテクニカルフォーラム2104

ということでアシストテクニカルフォーラム2104へ行ってきましたよ。

概要

  • 場所は西新宿にあるベルサール新宿グランド。
  • けっこう人は入ってました。フォーラム終了後、しばらくエレベータホールが激混みで帰れなかった。
  • 今回は14:30からの3セッションを聞いてきた。

A-1 Oracle Database In-Memory超入門

  • ほぼ満員。人気のセッションだった。
  • Oracle Database In-MemoryはOracle 12cのオプション製品。インメモリ・カラムストアをSGAに追加したもの。データを行指向メモリと列指向メモリに二重持ちする。
  • MVIEWで分析系ビューを作るのは大変。ユーザによっては数千のMVIEWを使うことになり、メンテが大変。
  • 業務処理用のメモリと分析用のIn-Memoryを同時に使うことで、業務系を動かしながら、分析系もリアルタイムで同時に使える。
  • SQLの特別な書き換えは不要。
    • BIツールもOracleに接続すれば、そのまま使える。
In-Memoryのしくみ
  • INMEMORY_SIZEという初期化パラメータを設定すると、In-Memory機能が使えるようになる。
    • ただし、自動メモリ管理外かつ、設定変更後にインスタンス再起動が必要。
  • インメモリ対象の決定は、ALTER TABLE 表名 INMEMORYで指定。特定列や、特定パーティションを指定も可能。
    • なお、表をインメモリ対象にしても、インデックスは対象にならない。
  • インメモリへの反映はOracleのバックグラウンドプロセス(IMCO)が起動したプロセスが読み込む。
    • PostgreSQLのランチャとワーカみたいなものか。
  • インメモリの反映（ポピュレーション）は5段階選択可能。
    • でも、最優先のCRITICALでも2分間隔更新なのか。
    • つまり、完全なリアルタイム反映ってわけではないと。
  • ポピュレーションの負荷はけっこう高い。ポピュレーション・スゴイタカイフカ。
    • ポピュレーション用のプロセス数でチューニングが必要かも。
    • ポピュレーション時間は次のセッションで(涙)
  • In-Memoryではデータ圧縮も可能。6段階指定可能。
  • インメモリ・カラムストアの管理ツールも当然ある。EMにインメモリ用の管理画面がある。
    • PostgreSQLだと、きっとそういう管理用のビューを提供して終わりなんだろうなあ。良くも悪くも。
参照機能の話
  • IMCU(In-Memory Compressoin Unit)ひとつに数十万行を格納。IMCU毎にMIN/MAXを記録。
  • INMEMORY_SIZEで指定したサイズが格納できるわけではない。70〜80%程度しか格納できない。見積もり時には留意が必要。
  • IMCUのMIN/MAXはストレージ索引としてつかう。条件値がMIN/MAX外なら、そのIMCUへの処理をすっとばせる。
  • SIMDベクタ命令を使ったスキャンによって、1CPUコアあたり、数十億行/秒のスキャンレートを実現。
  • Oracleのパラレル処理はインメモリ側でも有効。というかパラレル設定でクエリを投げるのが必須。
  • パーティションを併用して、パーティションによるプルーニングも活用すべきと。
  • 結合はブルーム・フィルタをインメモリにも応用できる。普通にクエリを実行すると自動でやってくれるので、クエリ発行側で意識をするわけではない。
  • RACやOracleのマルチテナント、暗号化、監査などにも組み合わせ可能。
ポピュレーション
  • ポピュレーションできないオブジェクトや機能もある。LONG型や非インラインのLOB型とか。
  • インメモリを使ってもUPDATEには対応する。旧データは無効化される。
    • 無効行数の閾値(非公開)を超えると、IMCU単位で再作成が動いてしまう。
    • 2分間隔で反映するトリクル再作成というやり方も使える。
  • ポピュレーション用の表にインデックスはいらないので、インメモリ側だけのインデックスを削除すること。
In-Memoryの恩恵
  • Oracleのインメモリの最大の強みは、メモリ上限に縛られないことと、Oracleの既存機能と組み合わせられることかな。あと、ハードウェア非依存ってことか。
  • インメモリがもたらすもの。リアルタイム、かつ分析粒度を粗くせずにBIが可能になること。

D-2 Ashisuto's Maximum Database Security

  • アジェンダ。データベース・セキュリティの課題、あるべき姿とは、どうすればいいか。
  • データベースに関わる人達。データ管理者、データベース管理者、開発者、データ利用者に分類。
    • データベース管理者は、本来はデータにアクセスする必要は本来はないけど、特権ユーザなので全オブジェクトにアクセスできてしまう。
      • これはPostgreSQLでもそうなんだよねー。
    • データ管理者はデータにアクセスする必要はあるが、職責を超えたデータアクセスは本来は不要。これはロールの不適切な設定の話なのかなー。
    • データ利用者に関しても、本来アクセス不要な列へのアクセスが可能になっているというケース。
      • そういえば、PostgreSQLって列アクセス制御って現状出来たっけ？後で確認しないと。
    • 開発者は本番環境と同等の開発環境データにフルアクセスしてしまいがち。
原則論
  • シンプルな原則。最小権限の原則。職責に応じたアクセス権のみ付与。
    • データベース管理者はデータへのアクセスは不要にするべき。
    • データ管理者は職務に関連するデータのみにアクセスを抑止する。データベース単位での制御も含む。
    • 開発者が使うデータは、普通に閲覧できないようなマスクなどをかけるべき
  • Oracle製品では先に挙げた問題に対処が可能。
現実論
  • データベースセキュリティの3つの視点。監査、アクセス制御、暗号化。
  • セキュリティにレベルを設けてステップアップする。最初は権限の付与、監査くらいから。次にDatabase Vaultなどの導入。
    • セキュリティを考えるときにも、コスト・リソースの観点は外せないので、ステップ論が必要。
DBAの内部犯行
  • 次のテーマは、DBAによる内部犯行をどうやって防ぐか。
    • 先日の某社の漏洩事故で、内部犯行が注目されている。
  • データベース管理者に対する制御、特権ユーザをどう扱うか。
    • 現状はアクセス制御や監視は不十分。
    • Database Vaultだと特権ユーザへのアクセス制限が出来るってことか。
    • あとはリアルタイム監視・通知の仕組みをつくる。
  • Database Vaultで何ができるか。複数の管理者に管理権限を分割できる。
    • これによってデータベース管理のユーザが実データ・アクセスを抑止できる。
    • レルムという保護単位を設けて、データベース管理者にも触れられないレルムを設ける。
  • データベース管理者はメタデータを含むレルムにしかアクセスさせない、とかいう制御をさせるのか。あとは、時間帯によるアクセスの制限も可能。
  • ここでPISOによる監視の話にうつる。
    • この類の話は、セキュリティ管理者を置くとかの体制も含めた検討が必要なんだよな。
  • 次はPrivilege Analysisとデータ管理者の話。
    • ふむ、付与されている権限の使用状況を収集する機能なのか。
  • 開発者向けにはデータマスキングのツールを使えと。
セキュリティに対するアシストの考え方
  • アシスト社の見解では、運用コストが大幅に上がるセキュリティ対策まではしなくていいじゃね？と。
  • 例として、ユーザデータ全体のレルムを作って保護すれば十分じゃね？的な話。
個人の感想です
  • 内部犯行に対する情報漏洩に対して、現状のPostgreSQLは無力な部分が多い・・・
  • コミュニティの思惑はさておき、このへんをどこまでPostgreSQLで頑張れるのかは大きなテーマになりそう。

D-3 高速データ分析基盤を支えるDBインフラ技術

  • アジェンダ：DWHに求められるモノ、OLTPとDWH、DWHにおけるDBインフラ技術
  • DWHの課題：DWHはお高い、汎用RDBMSはトロい、DWH専用製品はお高すぎる、リアルタイム性に欠ける。
  • OLTPとDWH
    • OLTPの特性。多くのユーザ、同時実行制御、読み取り一貫性、HA。少ない行と多くの列へのアクセス。
    • OLTPのインフラ。スケールアップ型。マルチコア、メモリ小、HAは必要
    • DWHの特性。少数ユーザ、拡張性と柔軟性、大量行と少数列の高速処理。
    • DWHのインフラ。スケールアウト型。マルチコア、メモリ大、容量効率(圧縮)、HAは優先しない。
I/Oバウンドの解決
  • まずは、I/OバウンドからCPUバウンドを目指す。
    • メニーコア、SIMD。パラレル処理、アウトオブオーダー、GPUの利用。
    • インメモリ技術、スマートキャッシュ、バッファプール。
    • Strage Index、パーティショニングなど。
  • パーティショニングの話。OracleだとEEしか使えないのが何気にポイント。PostgreSQLのパーティショニングも使いやすいわけではないけれど。さらにパーティショニング＋パラレルクエリの話。
  • 次はデータ圧縮。Oracle EEだけ取り上げてるけど、PostgreSQLのTOASTオプションやWAL圧縮も圧縮技術といえないこともないんじゃないのかな？
  • 列指向DBによるアクセス量削減の話。列単位格納＋圧縮。そういえば、スライドには製品名は出してないけど、アシストでは何を扱ってるんだろ？
  • OracleのASMの話。ASMによるデータ負荷分散（複製によるデータ保護も可能）。
  • Oracle ExadataのSmart ScanによるI/O削減。アプライアンスものの強み。
  • ストレージ索引の話。列志向DBでも使われる。Oracle Exadataでも使えるが、なかなか癖が強くてストレージ索引を有効に使えないらしい・・・
  • マテリアライズド・ビューの話。差分更新の運用が課題。これはOracleもPostgreSQLも同じ。
メモリリソース
  • 次はメモリリソースのDBインフラ技術の話。
  • データをメモリ上に展開。カラム型テーブル、ロー型テーブルの併用。⇒Oracle In-Memory
  • Oracle In-Memoryオプティマイザが、カラム型/ロー型を適切に選択してくれる。\
  • バッファキャッシュから捨てられたデータをSSD等にキャッシュするという技術。
  • PPASではネットワーク上の他サーバのメモリを2次キャッシュとして使える。もちろんNW帯域にも影響は受ける。
CPUリソース
  • CPU並列処理による性能向上。パラレルクエリなど。まだPostgreSQLでは実現できていない分野。
  • SIMD演算の高速化。Oracle In-Memoryの機能。
  • アウトオブオーダ型クエリを使ったPgBoosterの話も紹介された。
  • 海外さんのPG-StromもGPU活用の例で紹介された。
ベンチマーク
  • Star schema Benchmarkによる、Oracle In-Memory, OracleEE, 列指向DB, PPASの比較。
    • Oracle In-Memoryは圧倒的に速い。
    • 列指向DBはノーチューニングでも速い。
    • PPASはクエリによって厳しい。
  • OSSDBはDWH系でもあと1,2年で追いつけるという期待がある。逆に言えば、今は厳しい。