Oracle Open World 2018で感じたこと [最新動向]
Oracleに関わるようになってから久しいが、今年初めてOracleOpenWorldに行く機会に恵まれた。Open Worldとは、毎年秋にサンフランシスコのモスコーンセンターにて開かれるOracle社の国際会議で、世界から6万人、日本からも200人以上がこのために集まる一大イベントである。今年2018年は10/22～25に開催された。
※当日のレジストレーションの様子。長蛇の列ができている。前日のレジストレーションはこんなに並ぶことはなかった。
.jpg)
正直、始めはわざわざサンフランシスコまで行く必要があるのか、と思っていた。ラリーエリソンの話なら、いつもまとめられた記事で読めるし、興味があればWebで動画で見られる。そもそも、それらの話（多くは製品や開発のビジョンやコンセプトなど）を聞いたところで、日々の業務に直接役立つことがあるとも思えなかった。ところが、実際に行ってみるといくつか全く新しい気づきがあったので、以下に思いつくまま特筆すべきことを記載しておく。なお、ラリーエリソンのキーノートやクラウドの話は既によい記事があちこちに出ているので、ここでの記載は控える。
まず１つ目は、OracleOpenWorldは開発者のための技術の情報共有の場であるということ。10/22～25の4日間に2500以上のテクニカルセッションが開かれるため、興味のあるテーマやスピーカーで好きなセッションを選ぶことができる。今回私はExadataや18c(RAC)のコア技術に特化してセッションを選んだが、それだけでも時間が足りないほどのセッションがあった。新機能や製品コアの内容はおおむねOracle社の開発のマネージャによるものであるが、それ以外にユーザ（IOUGのACEディレクターや企業の方）の製品・サービスの事例も豊富にあり興味深かった。例えば、私が参加したのは、クラウドへのRMANバックアップ活用のススメ（下記写真のセミナ）、DellEMCの方のshadingを検証してみた話、18cRACでundoセグメントヘッダがキャッシュフュージョンできるようになった話、ExadataのストレージサーバのメモリにDBぼバッファキャッシュが拡張できるようになった話、EnterpriseManagerでマルチテナントのプロビジョニングが簡単にできるようになった話などなど。
※セミナ終了後の様子。講演者の周りに人だかりができてQAしている様子
.jpg)
次に、ユーザ企業個別のニーズに応じて、CVC（Customer Visit Center）にて現地開発のキーマンと打ち合わせで情報交換ができること。最新の製品の仕様や動向、あるいはこちら側のニーズ（改善要望）を双方から出しながら議論することができるのだ。たとえばExadataのSmartScanの最新の仕様や、プロジェクトの状況において、どのようにフラッシュキャッシュを有効活用すべきか、といった議論を、開発責任者と直接できるのである。もちろん、改善要望をあげたとしてもすぐに製品へ反映される訳ではない。しかし、Oracleのような巨大な製品プロセスに関与できる（かもしれない）機会があるのは、なかなか興味深い。また、現地開発者とのリレーションが確立できれば、トラブル発生時のエスカレーションにもポジティブな影響があるかもしれないとの期待もある。
最後に、これは言うまでもないことだが、ベンダ、ユーザ企業間の交流の場であること。各種懇親会を通してベンダ、日本企業の間で情報交換ができる機会がある。今回自分はあまり有効活用できなかったが、継続的に参加していれば横のつながりを作る機会にはなるだろう。
以上、私が当初思っていたOpenWorldのイメージと異なっていた点である。
今回実際に行ってみて、何が直接得られたか、というと、１つは「人と人とのつながり」なのではないかと思う。キーノートの内容や技術的な内容の多くは日本でも得られるが、現地での開発者やユーザ同士の交流は、なかなか日本で通常の業務を行っている中では得られないものだと思う。日本のセミナでは企業間の敷居が高いが、海外に出ると比較的気軽に名刺交換できる。また、先進的な機能や事例を聞くことで、エンジニアとしての視野を広げる機会としても良いと思う。これは自社にこもって開発や維持運用をしているだけでは難しい。開発の効率化・生産性向上の新しいヒントを得るには良いだろう。また、総じて、やはり英語がある程度できないとせっかくの機会を有効に活用できない（キーノートは同時通訳がつくが、多くのテクニカルセッションは英語のみである）ことを改めて感じた。英語のモチベーション向上にも良いだろう。
現地で下記書籍をつい購入してしまった。さらっと見た感じ、浅く広く12cの機能を活用したパフォーマンスチューニングについて記載されているので、ちょっと気になったトピックについて調べるのに良さそうである。厚くて帰りのスーツケースに入れるのに苦労した割に、まだ読めていない。
※当日のレジストレーションの様子。長蛇の列ができている。前日のレジストレーションはこんなに並ぶことはなかった。
.jpg)
正直、始めはわざわざサンフランシスコまで行く必要があるのか、と思っていた。ラリーエリソンの話なら、いつもまとめられた記事で読めるし、興味があればWebで動画で見られる。そもそも、それらの話（多くは製品や開発のビジョンやコンセプトなど）を聞いたところで、日々の業務に直接役立つことがあるとも思えなかった。ところが、実際に行ってみるといくつか全く新しい気づきがあったので、以下に思いつくまま特筆すべきことを記載しておく。なお、ラリーエリソンのキーノートやクラウドの話は既によい記事があちこちに出ているので、ここでの記載は控える。
まず１つ目は、OracleOpenWorldは開発者のための技術の情報共有の場であるということ。10/22～25の4日間に2500以上のテクニカルセッションが開かれるため、興味のあるテーマやスピーカーで好きなセッションを選ぶことができる。今回私はExadataや18c(RAC)のコア技術に特化してセッションを選んだが、それだけでも時間が足りないほどのセッションがあった。新機能や製品コアの内容はおおむねOracle社の開発のマネージャによるものであるが、それ以外にユーザ（IOUGのACEディレクターや企業の方）の製品・サービスの事例も豊富にあり興味深かった。例えば、私が参加したのは、クラウドへのRMANバックアップ活用のススメ（下記写真のセミナ）、DellEMCの方のshadingを検証してみた話、18cRACでundoセグメントヘッダがキャッシュフュージョンできるようになった話、ExadataのストレージサーバのメモリにDBぼバッファキャッシュが拡張できるようになった話、EnterpriseManagerでマルチテナントのプロビジョニングが簡単にできるようになった話などなど。
※セミナ終了後の様子。講演者の周りに人だかりができてQAしている様子
.jpg)
次に、ユーザ企業個別のニーズに応じて、CVC（Customer Visit Center）にて現地開発のキーマンと打ち合わせで情報交換ができること。最新の製品の仕様や動向、あるいはこちら側のニーズ（改善要望）を双方から出しながら議論することができるのだ。たとえばExadataのSmartScanの最新の仕様や、プロジェクトの状況において、どのようにフラッシュキャッシュを有効活用すべきか、といった議論を、開発責任者と直接できるのである。もちろん、改善要望をあげたとしてもすぐに製品へ反映される訳ではない。しかし、Oracleのような巨大な製品プロセスに関与できる（かもしれない）機会があるのは、なかなか興味深い。また、現地開発者とのリレーションが確立できれば、トラブル発生時のエスカレーションにもポジティブな影響があるかもしれないとの期待もある。
最後に、これは言うまでもないことだが、ベンダ、ユーザ企業間の交流の場であること。各種懇親会を通してベンダ、日本企業の間で情報交換ができる機会がある。今回自分はあまり有効活用できなかったが、継続的に参加していれば横のつながりを作る機会にはなるだろう。
以上、私が当初思っていたOpenWorldのイメージと異なっていた点である。
今回実際に行ってみて、何が直接得られたか、というと、１つは「人と人とのつながり」なのではないかと思う。キーノートの内容や技術的な内容の多くは日本でも得られるが、現地での開発者やユーザ同士の交流は、なかなか日本で通常の業務を行っている中では得られないものだと思う。日本のセミナでは企業間の敷居が高いが、海外に出ると比較的気軽に名刺交換できる。また、先進的な機能や事例を聞くことで、エンジニアとしての視野を広げる機会としても良いと思う。これは自社にこもって開発や維持運用をしているだけでは難しい。開発の効率化・生産性向上の新しいヒントを得るには良いだろう。また、総じて、やはり英語がある程度できないとせっかくの機会を有効に活用できない（キーノートは同時通訳がつくが、多くのテクニカルセッションは英語のみである）ことを改めて感じた。英語のモチベーション向上にも良いだろう。
現地で下記書籍をつい購入してしまった。さらっと見た感じ、浅く広く12cの機能を活用したパフォーマンスチューニングについて記載されているので、ちょっと気になったトピックについて調べるのに良さそうである。厚くて帰りのスーツケースに入れるのに苦労した割に、まだ読めていない。
Oracle Database 12c Release 2 Performance Tuning Tips & Techniques (Oracle Press)
- 作者: Richard Niemiec
- 出版社/メーカー: McGraw-Hill Education
- 発売日: 2017/03/16
- メディア: ペーパーバック
Tableauパフォーマンスチューニング [SQL・DDL]
最近、BIツールのTableauに関わる機会があった。業務チームから、遅い画面があるので相談に乗ってほしいというもの。画面からクエリを発行すると15分でタイムアウトするらしい。DB側のSQLモニタリングで見てみるとTableauから発行されたSQLが特定の表のフルスキャンで時間がかかっていることがわかった。dba_segmentsから、概ね100gb、8000万件程度の表であった。
SQLを見るとTableauの生成した難解なSQL、特にWHERE句が複雑で、実行計画のプレディケートに大量にフィルタ条件が出ていた。いろいろ切り分けた結果、この中のdateカラムから年度を計算するロジックで非常に時間がかかっていたことがわかった。SQLを直接書き換えたところ、30秒で返ってくるようになった。
問題はTableauがなぜこのようなSQLを生成したのか。よくよく業務チームの話を聞くと、どうやらTableau側にフィルタ条件としてこの年度計算ロジックを設定しているとのこと。これはTableau側に用意された関数を用いて記述されており、これを基にTableauがSQLに変換してくれる。この変換ロジックはおそらく公開されていないと思うが、恐らくこんな感じである。
(Tableau) → (Oracle SQL)
・INT(A) → round(trunc(to_number(A)),0)
・STR(A) → to_nchar(A)
・DATETRUNC → cast (trunc(A, …) as date
・DATEADD('month',A,n) → add_month(A,n)
・DATEPART('year',A) → to_number(to_char(A,'YYYY')))
・DATE(A+B) → trunc(cast(case when A is NULL or B is NULL then NULL else A || B end) as date)
特筆すべきはTableauのDATE関数を使うと、case文が使われた（NULL判定ロジック入りの）複雑なSQLに変換されるということである。AやBの引数の中にさらにTableau関数が使用されているとさらに内部が展開されていく。これにより、条件の評価が複雑となりDBのCPUを使ってしまう。例えば、集計開始基準日から当年度4/1の日付を計算する２つの計算ロジックを考えてみる。
例１）
Tableau: DATE(STR(INT(STR(DATEPART('year',DATEADD('month',-3,[集計開始基準日])))-2) + '-4-1')
Oracle: trunc(cast(case when to_nchar(round(trunc(to_number(to_nchar(to_number(to_char(add_month([集計開始基準日],-3),'YYYY')))),0)-2) is NULL or N'-4-1' is NULL then NULL else (to_nchar(round(trunc(to_number(to_nchar(to_number(to_char(add_month([集計開始基準日],-3),'YYYY')))),0)-2) || N'-4-1') end) as date))
例２）
Tableau: DATEADD('month',3,DATETRUNC('year',DATEADD('month',-3,[集計開始基準日])))
Oracle: add_month(cast(trunc(add_month([集計開始基準日],-3),'YYYY') as date),3)
どちらも結果は同じであるが、例１の方が例２に比べてCPU負荷が高いのは明白である。これを見るとTableauのDATE関数の利用がいかに高いコストなのか、加えてINTやDATEPARTといった型変換を伴う演算を加えると、SQLの複雑さが助長されることがよくわかる。
もちろんデータ量次第では問題ないケースもあるだろうし、Oracle以外のDBでは効率的に処理ができるケースもあるだろう。しかし、DB(Exadata)の性能を最大限に引き出すには、BIツールの特性を意識した作りを意識する必要があることを改めて痛感した。
今回の教訓：Oracleでは、TableauのフィルタでDATE関数は極力使用しないこと。また、日付の型変換（文字列や数値）は極力避けること
以上
SQLを見るとTableauの生成した難解なSQL、特にWHERE句が複雑で、実行計画のプレディケートに大量にフィルタ条件が出ていた。いろいろ切り分けた結果、この中のdateカラムから年度を計算するロジックで非常に時間がかかっていたことがわかった。SQLを直接書き換えたところ、30秒で返ってくるようになった。
問題はTableauがなぜこのようなSQLを生成したのか。よくよく業務チームの話を聞くと、どうやらTableau側にフィルタ条件としてこの年度計算ロジックを設定しているとのこと。これはTableau側に用意された関数を用いて記述されており、これを基にTableauがSQLに変換してくれる。この変換ロジックはおそらく公開されていないと思うが、恐らくこんな感じである。
(Tableau) → (Oracle SQL)
・INT(A) → round(trunc(to_number(A)),0)
・STR(A) → to_nchar(A)
・DATETRUNC → cast (trunc(A, …) as date
・DATEADD('month',A,n) → add_month(A,n)
・DATEPART('year',A) → to_number(to_char(A,'YYYY')))
・DATE(A+B) → trunc(cast(case when A is NULL or B is NULL then NULL else A || B end) as date)
特筆すべきはTableauのDATE関数を使うと、case文が使われた（NULL判定ロジック入りの）複雑なSQLに変換されるということである。AやBの引数の中にさらにTableau関数が使用されているとさらに内部が展開されていく。これにより、条件の評価が複雑となりDBのCPUを使ってしまう。例えば、集計開始基準日から当年度4/1の日付を計算する２つの計算ロジックを考えてみる。
例１）
Tableau: DATE(STR(INT(STR(DATEPART('year',DATEADD('month',-3,[集計開始基準日])))-2) + '-4-1')
Oracle: trunc(cast(case when to_nchar(round(trunc(to_number(to_nchar(to_number(to_char(add_month([集計開始基準日],-3),'YYYY')))),0)-2) is NULL or N'-4-1' is NULL then NULL else (to_nchar(round(trunc(to_number(to_nchar(to_number(to_char(add_month([集計開始基準日],-3),'YYYY')))),0)-2) || N'-4-1') end) as date))
例２）
Tableau: DATEADD('month',3,DATETRUNC('year',DATEADD('month',-3,[集計開始基準日])))
Oracle: add_month(cast(trunc(add_month([集計開始基準日],-3),'YYYY') as date),3)
どちらも結果は同じであるが、例１の方が例２に比べてCPU負荷が高いのは明白である。これを見るとTableauのDATE関数の利用がいかに高いコストなのか、加えてINTやDATEPARTといった型変換を伴う演算を加えると、SQLの複雑さが助長されることがよくわかる。
もちろんデータ量次第では問題ないケースもあるだろうし、Oracle以外のDBでは効率的に処理ができるケースもあるだろう。しかし、DB(Exadata)の性能を最大限に引き出すには、BIツールの特性を意識した作りを意識する必要があることを改めて痛感した。
今回の教訓：Oracleでは、TableauのフィルタでDATE関数は極力使用しないこと。また、日付の型変換（文字列や数値）は極力避けること
以上
