てすと
written by iHatenaSync
ClubDB2参加記録 第177回 DB2 BLUとイントラパラレル試してみたよ(ゲスト講師:永安氏)に行ってきました。
久しぶりのblogです。
もっとアウトプットする癖を定着させたいですが、なかなかうまく行かないですね。
さて、表記の通りで、久しぶりにCLUB DB2に参加してきました。
最近は気持ちの余裕が足りてなく、勉強会からもついつい足が遠のいていましたが、「このままじゃダメだ」と思い、思い切って業務を切り上げて参加してきました。
DB2 BLU(ブルー)アクセラレーションのご紹介(by @sumi_chan )
簡易的に高速分析処理をさせるテクノロジー
- カラムストアによるI/O削減
- 列単位で保管。DWHの場合、行全部ではなく一部の列にアクセスすることが多い → 余計な列をI/Oしない分I/Oを減らす
- 効率のよい圧縮
- 列単位で圧縮 = 同じ(似た)データが繰り返しやすい = 圧縮率が上がる
- 高頻度のデータは高圧縮にする圧縮アルゴリズム
- 圧縮状態で演算が可能 → 解凍コストが不要
- ”=”だけでなく、”>”、”<”演算も可能!
- SIMDを使うことで高速
- データスキッピング
- 何らかのデータの塊(ページ単位?)毎にデータ範囲のタグを持つ。不要なページヘのアクセスをスキップすることでI/Oを減らす。
- (例)5年分のデータを保管しているDBで直近1年分だけアクセスする場合、不要な4年分にはI/Oしない。
- エンティティ単位でカラムナを選択できる
- Create TableのOrganize by [COLUMN|ROW]で指定
BLUの強み
- 全体的に早くなることもメリットだけど、極端に遅いことを回避することが大きなメリット
DB2 BLUとイントラパラレル試してみたよ!(by 永安さん)
毎度ながら訳の分からない長文になるので、心に残ったキーワードを中心に。
- PostgreSQLで限界を感じることがあるため、テクノロジーとしてイントラパラレルを試してみたかった
- PostgreSQLはシングルプロセス、シングルI/O
- グリーンプラムは?と思ったら、内部に複数のPostgreSQLが動いているらしい
- 元データ 100GBをDB格納すると
- Non-BLU : 189GB(TBL+Index)
- BLU : 48GB
- この時点で約4倍の差。Non-BLUが圧縮なしとはいえ、この時点で大分性能が出そう。
- 検証結果として、すっごく早くなったクエリが沢山と、そんなに早くなっていない(それでも通常の行指向DBと同じぐらいのパフォーマンス)のクエリがある。
- 早くなるパターン
- 利用する列が少ない = I/Oが大量に減る
- I/Oが1/30に減る例も!
- その分CPUバウンドになって、CPU利用率が上がっている
- CPU利用率が上がっても総処理時間が短くなっているので、総CPU利用量は下がっていそう。
- イマイチなパターン
- select *を含むクエリ
- 内部で列をくっつけて行を作りなおすJoinが動くので、どうしてもオーバーヘッドが大きい。
- でも、Non-BLUに負けてないんだからすごい。
- select *を含むクエリ
- データによって差が出るのでPoC重要
カラムナーDBの実装
本編最後のQAで非常に有意義なことを知ったのでメモ
- 行の再構成コストを削減するために、カラムナーDBはいろんな実装がある
- 行指向DBをマスターとして保持しつつ、アドホック・クエリー用に列指向DBを同時持ちする
- 1つずつではなく、複数の列をまとめて格納する
- BLUは1列ずつのデータしか保持しない
- 今回の例は、行の再構成コストを払ってもお釣りが来るほど、I/O削減が効いているパターンだと思われる
- 確かにDBによっては30倍の圧縮効率が出ていた。
- カラムナーDBをOLTPに使うのはさすがに無理
- INSERT/DELETEまでは何とかなるがUPDATEが致命的
- UPDATE文を内部でDELETE/INSERTに置き換える実装をしているが、遅い
- DB2 for z/OSにはBLUは提供されていない
雑談
当然ながら2次会にも参加しました。永安さんの正面という一番美味しい席に座らせてもらって、楽しい&有意義な時間を過ごさせてもらいました。楽しかった〜。
本編で、かなりの質問をさせていただいたのですが、2次会でも遠慮せず(失礼しました!)色々と質問させていただきました。
毎度のことながら終電の関係でお先に失礼しましたが、非常に楽しい&有意義な時間でした。
でも、お酒の席の会話、半分ぐらい忘れちゃってる。。。もったいないので、次からはメモ持参で参加しようかな(笑)
その他のキーワード
- 検証結果を非公開(配布資料なし/UStreamなし)理由
- 前提条件を無視して、数字だけがひとり歩きしかねないので数字は公表しなかった
- 数字だけひとり歩きして嫌な思いをさせたくない
- 追試可能な状態にしてある。再現性がある
- 最近の永安さんの肩書:チーフデータマエショリスト(笑)
- 一瞬、どんな肩書なのか真剣に考えてしまいました。
- 30日で検証準備からプレゼン準備を実施
- 最初にWBSを作成!
最後に
毎度のことではありますが、運営して頂いているClubDB2の皆さん、いつもありがとうございます。
また、お忙しい中検証結果をシェアしていただいた永安さん、ありがとうございました。
またまた、2次会でお会いした皆さんとも楽しい時間を過ごすことが出来ました。
ClubDB2参加記録 第146回 達人が語る こんなデータベース設計は嫌だ(by ミックさん)に行ってきました。
毎度毎度、久しぶりにClubDB2に参加してきました。
ここ半年ほど、第4金曜日に夜勤が入ることが多くなり、参加したくてもできないことが多かったのですが、今回は講演者がミックさんということで、夕方に1時間早上がりをする段取りまで付けて参加しました(笑)
ミック([twitter:@copinemickmack] / id:mickmack)さんについては、前回の登壇(Welcome to Wikis)で初めてお目にかかり、その後著書を2冊ほど読ませていただきました。
特に近著 「達人に学ぶDB設計徹底指南書」については、非常に多くのグレーノウハウ、バッドノウハウ、「わかるわかる」と頷くノウハウから「えー!こんなのあり(笑)」といったノウハウを分かりやすく紹介していただき、気付ば毎朝30分x5日ほどで読了してしまいました。2時間ちょっとで読み終わってしまうとは、高い買い物でした(笑)
今回の2次会でありがたくサインも頂き、現在は後輩の課題図書として貸出中です。
この本で、前チームの若者たちが少しでもピヨピヨを卒業してくれると嬉しいものです。
![達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ](https://images-fe.ssl-images-amazon.com/images/I/61bMuQNwkoL._SL160_.jpg)
達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2012/03/16
- メディア: 単行本(ソフトカバー)
- 購入: 21人 クリック: 316回
- この商品を含むブログ (24件) を見る
閑話休題。
さて、今回のミックさんの公演ですが、サイジング方面からみたDB設計がテーマでした。
話は多岐に渡ったのですが、私自身考えさせられることが多かったテーマを中心にブログにまとめようと思います。
これだけは覚えて帰ってほしい3つのキーワード
ミックさんが「これだけは!」とおっしゃるキーワード。これはそのまま掲載して、このブログを読み返すたびに気付けるようにしたいと思います。
- トレードオフ
- ハードウェアの進歩により大分変わってきたが,データベースの世界にはまだまだのこっている。
- データベースに求められる要求水準は青天井
- これは主に性能要求に関することだったと思います。
- 手続き型の呪い
- ファイル≠テーブル
- 超重要。DBエンジニアの人生を変える(笑)
- ストレージに触るものは不幸になる。
- 「ディスクに触ったら負けかと思ってる」
ミックさんの名言
前回の公演でも触れていたことなのですが、「ガリガリチューニングを頑張るよりH/Wを買うのが(多分)正しい」
特にSI案件ではこれがかなり難しいことなのですが、エンジニアとしてはかなり的を射ている言葉だと思います。先日、社内でこの考え方を話したら、参加者の皆さんが目からウロコが落ちる反応をしていました。コロンブスの卵ではあるのですが、このご時世、まさにそのとおりですよね。
具体的には、以下のような対処がこれに当たると思います。
- メモリを積む
- 良いストレージ製品を買う
- パーティショニングオプションを買う
ディスクに触ったら負け?
このキーワード、インフラエンジニアとしてもろに食いつきました。「そうなの?」って。
でも、世界の大部分のシステムであれば、たしかに、インフラレイヤーをDBエンジニアに意識させたらインフラエンジニアの負けですよね。制約があるなら、最初から設計して、「こういうふうに使ってね」って説明したいものです。
でも、ケースバイケースとはいえ、メインフレームの基幹システムの分野ではディスクの物理設計、パフォーマンスをちゃんと見られないとインフラエンジニアとしては不十分だと感じる事が多いです。(私もまだまだ勉強中の身ですが)
責任分界点という考え方
ミックさんが一例としてあげていた「ビュー ⇔ テーブル ⇔ ファイル ⇔ ストレージ」の責任分界点議論、
それぞれの責任分界点を以下のように分けていました。(アプリケーションエンジニア部分はkmasu追記部分)
- ビュー:アプリケーションエンジニア
- テーブル、ファイル:DBエンジニア
- ストレージ:インフラエンジニア
この「責任分界点」とか「役割分担』という言葉って、往々にして誤解を生みやすい言葉ですよね。
私は、(誰に聞いたか忘れたのですが)「責任分担」という言葉が好きです。
一例を上げれば「インフラエンジニアとしてストレージに責任をもつなら、隣接するDBエンジニア領域を知らないと責任が持てないよね?」ということです。
ちょっと長くなるのですが、
「システム全体を考えれば、インフラエンジニアはストレージだけを見ていれば良いのではなくて、ストレージ観点でファイル(DBMS)側に入り込んでいかなければダメだし、DBエンジニアもストレージのことを勉強して、インフラエンジニアを使いこなさないといけない。あくまで、スペシャリティとしてどこまでをカバーするか、であって、隣接する分野の知識を持ち、その分野のスペシャリストを使いこなしてシステム全体を最適化するのがエンジニアとしての責務」だと思うんです。
このへんはid:megascusさんとほぼ同じ考えなのだと思いました。
酒井さんとの議論
2次会でちょっとだけ酒井さんと話をしたテーマです。
ここは後日まとめたいな〜。
検索キーがクラスターインデックスだったら、ループのほうが早いことがある?ってことを話しさせていただきました。
その他キーワードメモ
- TPC-Cは「システム構築の現場では」参考にならない。超ハイスペックストレージを使っていてサイジング無視だから
- シェアードナッシング VS シェアードディスク。パフォーマンスを出そうとすれば社アードナッシング型になるが、制約が大きい
- 全部メモリに載せちまえ(笑)
- 32bit OSはだめよ!2Gの制約。オワコン
雑談
当然ながら2次会も参加しました。
毎度ながら、終電の関係でみなさんより少し早くお暇しましたが、非常に楽しい時間を過ごすことができました。
火消し会場から登場した(笑)ミックさんに、「障害対応は血沸き肉踊りますよね〜」っていったら、「ソルジャー症候群」だって言われちゃいました。いけないとは思いつつ、やっぱりそれはだめですよね(^^; でも、自分で火をつけるところまでは行っていない(はず)なので大丈夫です!
あと、PureScaleに話が及んだ瞬間の下佐粉さんの必死っぷりが楽しかったです(失礼!)でも、私もあそこは話したくてうずうずしました。「CFやCF Linkが高速で、ほぼダイレクトメモリアクセスだから、ロック制御や更新データ制御もボトルネックにならない!(なりにくいんです!)」って。
そうそう、「「魂に重量を引かれている」的なあれ」ってところ、思ったより会場の反応が鈍かったなぁ。自分的には一番面白かったです。
Excel列名変換問題を解いてみた。
Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編) - give IT a tryにたまたまたどり着いて、「そういえば最近Perl使っていないな(というかコード書いていないな)」と思ったので、まずは問題1に挑戦してみた。
問題1: Excel列名変換問題 仕様 入力されたアルファベットを数字に変換する。 変換ルールはExcelの列名と同等。 例) A=1、B=2、Z=26、AA=27、XFD=16384 起動時引数 [0] アルファベット (A〜ZZZZ...[上限なし])*2 実行例 ExcelColConv.pl A → 1 ExcelColConv.pl AA → 27
思考ロジックを整理しておくと
で、作ったコードが以下。
my @val_array; my $val_sum = 0; my %hash; %hash = (a => 1,b => 2,c => 3,d => 4,e => 5,f => 6,g => 7,h => 8,i => 9, j => 10,k => 11,l => 12,m => 13,n => 14,o => 15,p => 16,q => 17,r => 18,s => 19,t => 20,u => 21,v => 22,w => 23,x => 24,y => 25,z => 26); my $input = $ARGV[0]; my $len = length( $input ); # 入力文字列の順を逆にする for ( my $i = 0 ; $i < $len ; $i++){ $val_array[ $i ] = substr( $input , $len - $i - 1 , 1 ); } #1桁ずつ26進数として処理 for ( my $j = 0 ; $j < $len ; $j++){ my $conved_val = $hash { $val_array [ $j ] } ; $val_sum = $val_sum + ( $conved_val * (26 ** $j)) ; } print "value : $val_sum \n";
ここまで作って答え合わせ。
Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編) - give IT a tryの答え(上位3作品)を見ると、
- 第1位:ハッシュ変数による変換。但し、ループが1回
- 第2位:文字コード変化を活用した変換。
そうそう、こうやってみたかったんですが、ordっていう関数があるんですね。で、Aのアスキーコードが65だから、64引くと。ちょっと調べたら、文字コードから文字にするにはchar関数を使えば良いようです。これは第2問に使えそうです。
# Convert A-Z to a number my $ascii_code = ord($columns[$i]); # subtract 64 (to convert A to 1 B to 2 etc) my $value = $ascii_code - 64;
久しぶりにPerlの基礎を確認するのに便利だったページをいくつかメモしておく。
後は、MacでPerlを使う際の注意点。UnicodeとかCR改行コードでハマるとは思いませんでした。
http://d.hatena.ne.jp/hornistyf/20080421/1211981662
投資積立バランスの見直し
2012年も2ヶ月経過してしまい、当初の予定より2ヶ月遅れだけど投資のメンテナンス中。
今日は、積立金額の見直しを行った。(というか、やっと結論を出して、変更手続を行った)
改めて整理したところ、投資信託の積立に401Kの積立額を足すと、外国株式比率が高すぎることが判明。まずはこのバランスどりをおこなった。
これに401Kで先進国株式インデックスに投資しているので、国内/先進国/新興国比率が3:2:1、国内外比率が1:1になるようにした。
今回のバランス調整は以上で終了。
4月には会社の積立預金制度の変更があるので、これに合わせて再度バランス調整を行う予定。
なお、投資金額合計を見たところ、リバランスを行うまではなさそうなので見送り。
ただし、過去に購入したアクティブ運用の投資信託をどうするのか、今年1年で結論を出す予定。