「達人が語る こんなデータベース設計は嫌だ!」に
参加したので、感想をまとめようと思ったのですが、
出遅れて書くことが無くなってしまったので、
「変人が語る こんなEssbase設計は嫌だ!」という
誰得なエントリでお茶を濁してみることにします。
<Essbaseサーバとサイジング>
「そもそもサイジングできない奴、一歩前に出ろ」
-----------------------------------------------------------
せめて次元数とメンバ数でサイジングをしてから
プロジェクトの規模やハードウエアの見積って欲しいですね。
開発着手の前に既にPJTが崩壊してるとか泣きたくなる(死
→
参考01<Essbaseの性能はスケールするか>
「EssbaseはRDBに比べスケールアウトが困難」
-----------------------------------------------------------
Essbaseはシェアード・エブリシング型のアーキテクチャで、
最近になってHA構成が辛うじて可能になった程度です。
しかも制限が多い。シングルインスタンス構成で
ディスクをパーティショニングくらいが限界かも(汗
ここらへんが改善されると、個人的には夢が広がります。
→
参考02 →
参考03 →
参考04<ストレージネックを解消しましょう>
「とは言ってもEssbase側で可能なことは少ない」
-----------------------------------------------------------
先述のパーティショニングや、ディスクボリュームの
割り当てを分散させるくらいしかできないので、
頼むからRAIDで早いストレージを入れてください(泣
→
参考05<オンメモリの時代>
「やっぱりディスクに触ったら負けかなと思ってる」
-----------------------------------------------------------
計算キャッシュ、インデックスキャッシュ、
データファイルキャッシュ、データキャッシュ
(直接入出力がONのときのみ有効)と
ディスクに触らせない諸々の設定があるのに、
メモリをケチって失敗するとか問題外。
→
参考06<32bit OSはオワコン>
「64bit OSでもオワコンなケースに注意」
-----------------------------------------------------------
MEMSCALINGFACTORという、4GB以上のメモリを
キャッシュに設定できるオプションがあったのですが、
とあるバージョンでは設定が効かないというバグがあり、
64bit OSでもメモリを4GBまでしか使えないという
悲しい事態が発生したことがあります(吐血
最新のEssbase 11.1.2.2ではオプション自体が廃止されて、
最初からメモリを潤沢に使えるようになった模様。
→
参考07 →
参考08<手続き型の呪い>
「手続き型でロジックが書けたら苦労しない」
-----------------------------------------------------------
EssbaseのDSLは手続き型のロジックを(基本的に)
記述できません。なので、ピヨピヨじゃないエンジニアも
開発現場で頻繁に爆死します。しかも、次元の疎密
(≒インデックスとエクステント)の違いと計算方法の
相性を理解したうえでロジックを記述できないと
パフォーマンスが劇的に劣化するので、
開発をクリアできてもシステムテストで爆死します。
というか、基本的に皆揃って爆死します。
ここでのアドバイスとしては、メンバ式的にロジックを
実装すると逃げ道があるとだけ言っておきます。
→
参考09<Essbaseはガツンと一発で操作>
「常に必要なブロックを一度に操作する意識を持つ」
-----------------------------------------------------------
計算スクリプトはロジックを逐次で記述する形式に
なっていますが、逐次実行の数が増えるとパフォーマンスは
当然悪化します。データの並列処理に強いという特性を
活かせなければ、Essbaseを導入する意味など無いに等しい
ということを、某社の営業も知って欲しいと思います。
<Essbaseはテーブルじゃねえんだよ>
「人は何故データベースといえばRDBと考えるのか」
-----------------------------------------------------------
EssbaseはRDBと違い、データが丸ごと一つのファイルに
格納されていて、@XWRITE関数と@XREF関数が使える
場合を除いて、データ連携はエクスポートとインポートで
行わなくちゃいけない作りになっています。
なので、無駄な部分にアクセスさせずにロジックを
記述しないと、膨大なアクセス待ちが発生して死にます。
言い方を変えると、FIXステートメント超重要。
更新フラグの付いた部分だけを計算対象にする
高機能計算は、計算バグの元凶となるのでOFFを推奨。
→
参考10 →
参考11 →
参考12 →
参考13 →
参考14<Essbase技術者からの反論>
「でもさ、Essbaseには利点もあるんじゃないの?」
-----------------------------------------------------------
この意見には一理ある。オプティマイザが存在しない
Essbaseでは計算処理のパフォーマンスに揺れが無い。
ただ、パフォーマンスを考えられる技術者は極めて少ない。
(僕を月300万以上で雇って貰えるならOKだけど。)
というか、Essbaseは更新系の処理をさせるのに
向いたアーキテクチャじゃないような…。
(OLAP用のDBなんで、OLAP用に使っていただきたく。)
<垂直分割と水平分割>
「理論と実践のトレードオフ」
-----------------------------------------------------------
現場レベルにおいて、垂直分割と水平分割を
提案できるエンジニアは一人もいない。
(ソース:@Bizuayeuの経験)
<物理の犠牲になる論理>
「物理と論理が喧嘩すると、物理が勝つ」
-----------------------------------------------------------
しかし、物理側が問題を解決できるわけでもないので、
最終的にプロジェクトそのものが犠牲になる。
<アウトラインはいつ崩すべきか>
「アウトラインの変更は手戻りのコストが大きい」
-----------------------------------------------------------
性能が出る出ない以前にアウトライン(≒マスタ)を
変更しないとデータそのものが入らないというのが
Essbaseのデータモデルなので、仕方ないね。
だからプロトタイプのフェーズが必須と小一時間(略
<Essbaseの理想と現実>
「Essbaseエンジニアはどこまで物理を意識するべきか?」
-----------------------------------------------------------
ぶっちゃけ物理を意識できないエンジニアは
Essbaseでは役に立たんのですよ。
それがEssbaseの最大の弱点だと真面目に思う。
残念ながら物理に至れるエンジニアが少ない現状、
ベンダーの甘言に乗ってEssbaseを導入するのは
相当なリスクじゃないかな。20年以上前から
OLAP用途には愛されている=アーキテクチャ自身は
優れているという証拠で、キチンと使えたときの
パフォーマンスは素晴らしいし、知れば知るほど
洗練された作りになっていると僕も感じるので、
非常に寂しいのだけどね。