【参加】ClubDB2 第194回

今回は、DB2のV10.5のFP4と5の新機能のお話でした。
とても有意義なお話だったのに参加人数が少なくてとてももったいなかったです。
そして、参加できなかった人は資料が良かったいのでもったいなかったです。

---

ClubDB2  第194回

DB2  最新情報あれこれ

メモ

DB2  BLU  の拡張

• カラム型のテーブルと通常のテーブルを混在したデータベースを作ることができるようになった。 
• 圧縮機能の向上によってIOが少なり、メモリ消費量も少なくなった。 
• Netezzaのゾーンマッピングを取り込み、各データ領域の最大値・最小値を保持し、不要なデータに触れることがなくなっただめ高速化した。 
• 集計系DBを構築するならBLUを利用することで圧倒的に構築スピードが上がった。特にチューニングが必要なくなったのが大きい。 

pureScale Lite

• FP4からpureScale Liteが導入された。今までのRDMAから一般的に使いやすいTCP/IPベースでpureScaleを実現できるようになった。CF2台、メンバー2台から2台のサーバにそれぞれCFとメンバーを起動させた構成できるようになった。 
• データのLoadはLiteの方が早く、updateは通常の方が早い。selectはほぼ変わらない。 

BLUシャドーテーブル

• OLTPでinsertされたデータをBLUのカラムテーブルに自動でコピーすることのできる機能。 
• 従来オプションだったレプリケーションの機能をDB2内にバンドルされた。この機能を利用してシャドーテーブルを更新している。 
• OLTPのトランザクションがある状態でシャドーテーブルに分析クエリーを実行すると1msくらい遅くなった。(power7 3.7GHz×8core、8億件(90GB)) 
• 分析クエリーがある状態でトランザクションがあるとき、分析クエリーが10並列くらいまでは処理が失敗しないがそれ以上だと処理数が多すぎて耐えられなくなる。 
• トランザクションで入ったデータがシャドーテーブルにコピーされるまで約3秒程度。 
• バッチ処理でデータをinsertする場合は、通常のテーブルに入れてからシャドーコピー。 
• レプリケーション技術を使っているためLoadを使っているテーブルはシャドーコピーできない。 

DB2 BLU ON  WINDOWS

• 今までAIXとLinuxだけだったが、FIX5からWindows  Serverでも利用できるようになった。 

NetezzaとDB２ BLUの使い分け

• データサイズと同時ユーザ実行数とLoadの優先度 
• データサイズが大きい場合はNetezza。スモールスタートの場合はDB2 BLU。同時ユーザ実行数が多い場合はNetezzaでは耐えられないためDB2 BLU。Loadの要件が厳しい場合はNetezza。 

【参加】ClubDB2 第193回

2015年一回目のClubDB2です。
本日は、DB2利用初めて人向けのDB2アーキテクチャの説明でした。

もともとOracle開発者の人がDB2開発者への転換時に使った資料であるため、違いを理解することができてとても勉強になりました。

長らくお世話になった渋谷のIBMイノベーションセンターが2月末になくなってしまいます。
なので、記念に残り少ない回数のどこかで是非いらしてほしいです。

次回は『2015年2月13日(金) 19:00～21:00 第194回 DB2最新情報もろもろ（仮）』となっています。

ClubDB2 twitterアカウント @clubdb2
ClubDB2 ハッシュタグ #clubdb2

---

ClubDB2 第193回

テーマ：初めてのDB2開発者向けDB2アーキテクチャー入門
日程：2015年1月30日(金) 19:00～21:00
場所：IBMイノベーション・センター 18Fセミナールーム(渋谷)
講師：すみちゃん

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/ClubDB2/page/%E7%AC%AC193%E5%9B%9E



・DB2はiniファイルを修正するのではなくコマンドで変更する。
各変数が関係を持っているため、不整合が起きたときにエラーになるようになっている。
・レジストリパラメータは使える機能になると構成パラメータに移行されることが多い。
・データベースの構成パラメータのほとんどは作成後に変更できないので、作成時には注意が必要。
・パッケージキャッシュのinsert回数＝アクセスプランを考えた回数と言っても過言ではない。パッケージキャッシュのinsert回数が多いほど、アクセスプランを考えている。
・ステートメントヒープはコンパイル時に使用する。少ないとオプティマイザが選択肢を少なくしてアクセスプランを選択する。
・最近のメモリー管理はオートの方がおすすめ。DB管理者はインスタンス全体で何GB必要か考えること。また、初期設定は決めることができる。

ClubDB2 #178

ClubDB2 #178

○メモ

・DBがDeactireteしている状態でアプリがDB2に接続するとactiveteされる。この時すごく遅い。

　→事前にactiveteしておこう。

・DBのデータもスキャン対象にした方がよい？

　→基本しない。

　インターネットからデータを取得している場合のみありかも。

・仮想環境で発生するトラブルは？

　→IO

　→パフォーマンス見積もりが難しい。

　→AWSだと、LUNをたくさん組んでストライピングすると物理よりも早くなる可能性あり。

・問題発生に抑えること。

　リソース　CPU、メモリ、ディスク、IO

　最近実施した変更内容

　何が問題でどういう状態へ戻したいのか

　いつぐらいから問題が発生しているのか

　問題が起きる前に何か変更しなかったか

・問題判別は下のレイヤーから実施するのが基本。

・nmonはIBM発で様々なLinuxディストリビューションで利用できるようになった。

・スナップショットでしか取れない情報：コンテナの空き

・DB2pdはリソースが逼迫しているときでも使える。CPU100%時に便利。

第176回 データベース設計徹底指南！！

今回は、MySQLで有名な奥野幹也氏による、データベース設計の勉強でした。

twitter @nippondanji
blog http://nippondanji.blogspot.jp/2013/11/db.html

データベース設計徹底指南 from Mikiya Okuno


特定のRDBに関する説明ではなく、RDBを設計する上でのポイントよく記載されています。
本当は、直接お話しを聞きたかったのですが、参加することができず、Uｓｔでの視聴になってしまいました。非常に勉強になりました。

ドキュメントを読むだけでも十分勉強になりますので是非1度読むとよいと思います。

ClubDB2 第175回 アクセスプラン(実行計画)の読み方入門

アクセスプランの勉強してきました。

今までもClubDB2で取り上げていただいたのですが、いろいろと参加できなくて初めての経験でした。




資料はこちら

アクセスプラン（実行計画）の読み方入門 from Akira Shimosako

演習問題

https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/4ac81e67-d1c5-430f-969d-249fd346e68c/page/9bd90677-07e3-4612-9008-0502ddfd65e8/attachment/466af8cf-6880-414e-b873-1f0e64a2761a/media/DB2%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%97%E3%83%A9%E3%83%B3%E5%85%A5%E9%96%80_%E5%95%8F%E9%A1%8C.pdf


演習問題回答

https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/4ac81e67-d1c5-430f-969d-249fd346e68c/page/9bd90677-07e3-4612-9008-0502ddfd65e8/attachment/6edffe0c-3685-4907-bd16-f0c5ce59a816/media/DB2%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%97%E3%83%A9%E3%83%B3%E5%85%A5%E9%96%80_%E8%A7%A3%E7%AD%94.pdf







アクセスプランとは、実行計画。DBがデータにアクセスときの計画です。

これは、取得した統計情報をもとにDBが最も早くデータにアクセスする方法の計画です。

あくまでも計画なのでDBが思っているだけです。実際のデータアクセスはSQLを実行するまでわかりません。

とはいえ、データベースの保守とやっている人はアクセスプランの読み方を知っておかないとDBのレスポンス遅延が発生したときに調査できませんので、是非勉強したいものです。


アクセスするときに最もポイントになるのが、インデックスがあるかどうかです。

インデックスを使うと早くなることが多いです。

インデックスを使うかどうかどうかは抽出するデータが総データ容量の半分以下のときは使用した方が早いです。逆に半分以上の場合は、データを総舐めする方が早いです。





後は、メモです。



・インデックスは張るっていう。データベースは作るっていう。不思議！

・アクセスプランが変わる可能性

・データサイズ

・使用可能のインデックスの有無

・その他リソースの影響

・インデックスは絞り込める場所に張ろう・EXPLAINを取得する方法をしないとサポートに問い合わせできないぞ！

・DB2のコマンドはDOSでも動くように8文字になっている。

・filter factor=絞り込める割合

・アクセスプランは思っているだけ。実際は統計情報が古い可能性が高くずれてしまう。
アクセスプランと実行結果の差が大きいときはやばいので対処が必要。

・リアルタイム統計情報取得をOFFにする判断基準

・コストベースとルールベースがある。

DB2は基本的にコストベース。指定もできるけどおすすめしない。

・ネステッド・ループ・ジョインは小さいテーブルのとき最速。

ClubDB2 第173回

Clubdb2 第１７３回

アジェンダ：　注：内容は変わる可能性があります。
1. ITエンジニアがデータサイエンティストを目指すには？
2. データサイエンティストに必要な「道具」
3. Pythonを使ったデータ分析の実践

講師:
　日本IBM 中林 紀彦
時間 11月22日（金）19:00 ～ 21:00
場所 IBMイノベーション・センター 18Fセミナールーム(渋谷)

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/ClubDB2/page/%E7%AC%AC173%E5%9B%9E

・ITエンジニアが分析結果を持っているだけでは勿体ない。分析結果をオペレーションに組み込む
・ビジネスユーザに課題を持ってもらう。
・ビックデータで何ができるかという問いは意味がない。各社でデータの有効活用方法は違う。基本他社の事例は役に立たない。ビジネスの状況をよく理解できている人でないと分析はできない。
データ分析の整備だけでなくデータを分析する機能を合わせて整備しないとなかなかうまくいかない。分析環境を整備しないと難しい。
・RDBMSだけでなくテキスト検索もできないといけない。
・将来的には画像分析や動画分析も求められる。
・Pythonは分析のライブラリが充実している。もちろん可視化まで実現できる。
・データ分析手法をエンジニアが知っておくのは当たり前。
・ITだけで分析した結果でアナリストの分析結果を超える。ただし、ツールでできることではなく事象ごとにアルゴリズムを作る必要がある。
・音声分析はテキストにしてからテキストマイニング。また、話すスピードなどから感情を読み取ることも必要になる。
・画像分析は物の認識はできるようになった。しかし、属性までは分析できていない。
・Drレベルが集まらないと１つの課題のモデルは作れない。
・感と経験を数値的に説明するためにデータ分析をするとモデルを作りやすい

MySQL 勉強用スライド

どのスライドも初級者から中級者まで勉強になると思うので、復習に呼んで見ると良いと思います。



MySQLを基礎から運用まで深く学ぶ人におすすめのスライドまとめ8つ
http://it-ch.net/t/11

• 初心者向けMySQLの始め方
• MySQLインストールのお作法
• MySQLの文字コード
• MySQL初心者向け負荷軽減のはなし
• DBパフォーマンスチューニングの基礎：インデックス入門
• 俺のSQLがこんなに遅いわけがない
• MySQL Casual な生活 - メンテナンスからチューニング・障害まで
• 1台から500台までのMySQL運用 MySQL Beginners

ClubDB2 第156回

purescaleに関するお話を聞いて来ました。
個人的はOracle RACよりも好きな技術なので、とても興味深かったです。

https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=ja#/wiki/ClubDB2/page/%E7%AC%AC156%E5%9B%9E

○感想

purescaleの最小構成事例は、中小企業でも導入できるレベルのものだった。(定価で3000万円程度)並行処理が必要なDBの構築があった場合は、検討に入れても良いと感じた。

IBMは今後もアプライアンス製品を多くのパターンで出すことが想定される。アプライアンス製品は、性能から考えた場合コストパフォーマンスが良いため、中小企業でも導入しても良いと感じたが、一方で融通が効かないため、今の要件や開発や運用を前提とした場合、導入は難しいかもしれない。ホスティング契約などでアプライアンスを利用するのが現実的な気がした。

今後、他社でもアプライアンス製品を多く出し、業界的に自由なハード設計はできなくなっていくように感じた。そうなった場合を備えて、アプライアンスを前提とした要件定義の仕方などを考えていく必要があると感じた。

アプライアンスのみでDBを構築しようと考えた場合、どのデータ配置してどう連携すればよいのかエンタープライズのデータモデリングが難しくなると感じた。

クラウドとアプライアンスの住み分けが難しいと感じた。

【勉強会】ClubDB2 第146回

IBM主導のDB2の勉強会であるClubDB2に参加して参りました。
今回は、ミックさんによる「達人が語る こんなデータベース設計はヤダ！」でした。


↓資料はこちら
http://d.hatena.ne.jp/mickmack/20120714/1342246442

↓議事メモはこちら
https://docs.google.com/document/d/1b009Pr7bpDT0lyDD8kzDd5Hs_XYfXbMRuj6LUhCiONA/edit


印象的だったお話は3つ。

1. ループを利用したSQLの連続使用は禁止
   これは、手続型言語を利用している人に多くみられるもので、whileやfor文の間にSQLを入れて小さいSQLを何度も発行してしまうような処理です。
   このようなプログラムは本来1回のSQLで複数の行や列でとってくるのが正しいやり方です。
   もし、ループ利用したSQLを発行してしまうと1回のSQLは頑張っても0.01～0.1msです。複雑なSQLな場合1ms程度。しかし、ループを使ってしまうことで、100ループしただけで、複雑なSQLよりも遅くなってしまうことがわかります。
   皆さんも注意しましょう。
2. 論理設計は限りなく美し、そして物理で対応しよう。
   これは言葉のままです。パフォーマンスを向上させるためには、論理設計、物理設計の両方で対応することができますが、可能な限り物理で対応(メモリの増設など)した方が良いというものでした。
   その方が、保守もしやすく、チューニングのために時間をかける必要もないため、結果的に安く済むそうです。
   たしかにそうですね。中小企業では微妙ですが。
3. ディスクorストレージに触ってはいけない。
   DBは可能な限りメモリで処理を完結しましょう。当たり前の話ですが、意外に難しいですね。メモリも安くなったので足りなくなったら足せばよいという話でもありますが・・・
   今回の話のポイントは、ディスクはこれ以上進化しない。そのため、メモリで処理しないといけない。SSDもメモリっちゃメモリですからね。
   また、DBサーバーではストレージを利用していることが多いですが、ストレージの設計やチューニング、見積もりの方法が世の中であまり公開されていなく、非常に困難であるということ。

また、ライトニングトークでは、jfluteさんによるDBfluteの概略説明でした。

DBfluteって初めて聞いたのですが、簡単に説明するとOSSのO/Rマッパだそうです。
DB設計者の視点から作ってあるため、上で説明したループ利用した処理も利用していないとのことでした。
対応言語は、JavaとC#だそうです。

【勉強会】ClubDB2 第145回

IBM主導のDB2の勉強会であるClubDB2に参加して参りました。
ClubDB2には、非常にお世話になっています。
可能な限り参加するようにしています。

毎回、DBに詳しい方々がハイレベルな話をわかりやすく噛み砕いて説明してくださるので、勉強になります。

是非皆様にも参加して欲しいです。

日程：2012年6月22日（金）19:00 ～21:00
場所：IBMイノベーション・センター 18Fセミナールーム(渋谷)
内容：第145回 DBチューニングの基礎：インデックスを理解しよう
講師： 日本アイ・ビー・エム株式会社 ソフトウェア事業
下佐粉 昭（しもさこ　あきら）


↓議事等

https://docs.google.com/document/d/1E59iQp_Wxb8ErZysSBC9_s6TY5wHcFzLlg6JlRRn6J8/edit

↓資料はこちら
https://www.ibm.com/developerworks/wikis/download/attachments/118194222/%E3%82%A4%E3%83%B3%E3%83%87%E3%83%83%E3%82%AF%E3%82%B9%E5%85%A5%E9%96%80.zip


今回は、インデックスのチューニングについてです。
いやー結構知らないことがありましたねー

他のDBと比較とかやってみたいですね。
それぞれで最適なチューニング方法は違うと思うので。