2009年3月29日日曜日

BIについて調べるの巻(4)


ビジネス・インテリジェンス―未来を予想するシナリオ分析の技法



北岡 元
東洋経済新報社
売り上げランキング: 7737


おすすめ度の平均: 5.0

5 思考の枠組み
5 己を知ることの重要性




MySQLレプリケーション

レプリケーションとは

一般にレプリケーションとは、他のサーバにデータベースを複製することをいいます。複製はLANやインターネットなどネットワークを経由して行われるので、物理的に離れた場所にあるサーバへデータベースをレプリケートすることもできます。

複製方法の種類

複製の方法には同期と非同期の2種類があります。
同期複製の場合は、レプリケーションを構成する全てのサーバで常に全く同じデータが保持されることが保証されますが、一方でデータの同期を取るために他のサーバの応答を待つ必要があるので、サーバの台数が多くなる程、全体の応答性が低下する可能性があります。

逆に非同期複製は、サーバ台数の増加によるパフォーマンスの低下はほとんどありませんが、短い時間で観測した場合、サーバ間でデータの同期が保証されないという問題があります。

構成の種類

主なレプリケーションの構成にはマスタスレーブとマルチマスタがあります。
マスタスレーブ構成は、更新系のクエリを受け付けるのはマスタサーバのみで、スレーブはマスタから伝搬されたもの以外の更新処理は行いません。

マルチマスタは、どのサーバでも更新系のクエリを受け付けるような構成です。

MySQLのレプリケーションでできること


負荷分散


負荷分散機を経由して、スレーブサーバ群に参照系のクエリを負荷分散することができます。ただし、前述した通りMySQLのレプリケーションは非同期なの で注意が必要です。具体的には、全く更新しないテーブル、もしくは、クライアントアクセスがない夜間のバッチ処理でしか更新しないマスタテーブルに対する 参照系のクエリのような、スレーブへの伝搬の遅延が問題にならないクエリは負荷分散することができますが、ユーザ情報の更新をマスタに対して行った直後に スレーブにそのユーザの情報を問い合わせるような場合には、得られた結果が食い違う危険性があります。

MySQLのレプリケーションでできないこと


更新系の負荷分散


更新系クエリの負荷を複数のサーバに分散することはできません。

まず、単純なマスタスレーブ構成ではマスタは1つしかないので、更新系のクエリはこのマスタに集中させるしかありません。

次にデュアルマスタ構成を考えてみます。MySQLのレプリケーションでは、スレーブは他のスレーブのマスタになることができるので図3のようなデュアル マスタ構成にすることができます。しかし、マスタ間で更新処理が競合する可能性があるので、より上位のレイヤで更新対象となるテーブルごとにクエリの発行 先のマスタを区別するなど工夫が必要です。例えばユーザー情報の更新はマスタAへ、商品情報の更新はマスタBへ、というようにです。

これで更新系のクエリを分散することができるようになるわけですが、実は負荷の分散にはなっていません。なぜなら、マスタAに対して行われた更新処 理は、レプリケーションによりマスタBでも実行されるので、結局、両方のマスタで更新系のクエリが実行されることになり、更新系クエリの受け付けの分散は できても更新処理の負荷を分散したことにはならないからです。

Reference http://www.irori.org/doc/mysql-rep.html

2009年3月28日土曜日

OLAPのすすめ

OLAPという仕組みがEAIなどのI/Fとしてファンクショナルにさらりと表示されているとカッコイイが、今のご時世にはジレンマが生じそうな問題。IEしか動作しないというのは企業レベルにおいては特に問題ないこともあげられるだろう。とはいうものの開発はLinux上で行い、Viewer(クライアント)はIEという状況が想定されるですね。Tomcatとdbのバージョンの互換性が肝になるのでしょう。あとJAVAとの3つの相性か。

Reference http://itpro.nikkeibp.co.jp/members/ITPro/oss/20050117/154848/


CakePHPのはじめ



独自のルートを設定する前に、CakePHP のデフォルトのルートについて知っておく必要があります。CakePHP のデフォルトルーティングによって、どんなアプリケーションでもうまく動くようになっています。URL の中に、アクション名を置くことで、アクションに直接アクセスすることができます。コントローラのアクションに URL を使うことでパラメータを渡すこともできます。
    デフォルトのroutesのURLパターン:
http://example.com/コントローラ名/アクション名/パラメータ1/パラメータ2/パラメータ3

/posts/view という URL は、PostsController の view() アクションにマップされます。 /products/viewClearance は、ProductsController の view_clearance() アクションにマップされます。URL でアクション名が指定されていない場合には、index() メソッドが用いられます。

デフォルトのルーティングでは、URLを使ってアクションにパラメータを渡すこともできます。例えば、/posts/view/25 というリクエストは、PostsController 上で view(25) として呼ぶのと同じことになります。

Resource http://book.cakephp.org/ja/view/46/Routes%E3%81%AE%E8%A8%AD%E5%AE%9A

2009年3月21日土曜日

「ふりかえり」の手引き

アジャイル・レトロスペクティブスという本で気になったところを抜粋。

イテレーションレトロスペクティブのステップ

・場を設定する
->目標とアジェンダを確認してセッションの下準備を行う。
チェックインしたりチームの約束を作成したりして、参加しやすい雰囲気作りをする。

・データを収集する
->客観的な情報と主観的な情報を確認して、チームで共通の理解を得る。みんなの視点を考慮に入れることで、よりよいアイデアを手にすることができる。
・アイデアを出す
->チームが作り出した共通の理解を様々な視点から吟味する。
アクティビティを使って、みんなで一緒にアイデアを掘り起こしていく。

・何をすべきかを決定する
->チームのアイデアを優先づけし、チームに変化をもたらす改善点や試みをいくつか選択する。

・レトロスペクティブを終了する
->計画やコミットメントをチームがどのように実行するかをまとめる。参加者に感謝を述べて、レトロスペクティブを振り返る。

■イテレーションレトロスペクティブのステップ■
->経験や改善を取込む->製品を構築する->インクリメントした製品を出荷する->場を設定する->データを収集する->アイデアを出す->何をすべきかを決定する->レトロスペクティブを終了する

AGENDA
Retrospective Goal:
Learn from Previous iterations and find root causes of Problems
(レトロスペクティブの目標:前回のイテレーションから学び、問題の根本的な原因を見つける。)

>= Get Started ~ Overview(はじめに~概要)

>= Examine Project History(プロジェクトの歴史の調査)
>= Look for Patterns(パターンの探索)
>= Analyze and Synthesize Finding(結果の分析、統合)
>= Prioritize and Plan(優先づけと計画)
>= Wrap-Up(まとめ)

■SMART Goals■
・Specific(明確な)
・Measurable(計測可能な)
・Attainable(達成可能な)
・Relevant(適切な)
・Timely(タイムリーな)

2009年3月16日月曜日

BIについて調べるの巻(3)


やはり分析をしたからにはバックデータになる資料添付が必須なので、PDF,Excel,CSV,HTML出力ができるというのはとてもよい。ACCESSからExcelへ落としてグラフ作成の流れを一元できれば良い。プレゼン用にPPT作成時にグラフィカルは懲りたいところ(?)ボタン一つで出力するところまで仕込んでおけば良いのだから。実績分析レベルだとロールが決まっているから良いのだけれどランダムではないシュミレーションとなると季節変動要因を実績値に反映させるのがミソになりうる。反映させる意志をどのように判定するのかはランダムではいけないからなぁ。

2009年3月15日日曜日

BIについて調べるの巻(2)

オープンソースでBIツールとなっているものがどういったものか色々と探しては見てるのだけれど中々というかあまり出ていないことが分かる。なので、いくつかあたったけどpentahoが良いのかなぁと思うようになってきた。これを何らかのI/Fを通じてコミュニケーションツールと合体させるとディベートに発展するかもしれない強烈な議論が繰り広げられるかもしれないと社内ツールを模索したときにふとひらめいたのだった。

2009年3月14日土曜日

BIについて調べるの巻(1)

" データがあるところに分析のニーズありで、今後のRFIDの普及に伴い、そこから発生する大量のデータを分析したいというニーズが高まると予想される。こうしたニーズは、DWHやBIに対する新たな需要を促進すると同時に、少なからず既存のDWHやBIにインパクトを与えるだろう。"
エントリーはまだ全くさびれていない。サプライチェーンからのRFIDをとっかかりとして徐々に脚光をあびてくるのであろう。このながれはDWHからの意思決定に関するデータがレポーティングとしてのマンスリー、ウィークリィからデイリーもしくはタイムリーに変化してきた背景がある。意思決定のスピードが今日の営業・製造工程に多大なる影響を及ぼすからである。営業>受注>製造>納品までのサプライチェーンは今後もスピードが要求されると同時にシュミレーションのスピードも追い求められてくると考える。

2009年3月12日木曜日

さくらインターネットにcakePHPを設定

してみた。
とりあえず、なにを やっていいのか わからないので
まずデータベースコネクトができるか かくにんした。

2009年3月8日日曜日

CakePHP初心者セミナー

GREEのセミナールームでCakePHPの初心者セミナーに参加してきた。

題名『ケイクで始める快適WEB開発』

■本編
1.CakePHPとは
CakePHPの概要
CakePHPのインストール
初期設定

2.CakePHPの基本1
データベーステーブルの作成
Controllerの作成

3.CakePHPの基本2
Modelの作成
Viewの作成

4.応用テクニック
Controllerで使える機能
Modelで使える機能
Viewで使える機能

おもに

Controller(処理の入り口を担当する)

Model(データベースとのやりとりやロジックを担当する)

View(画面を表示を担当する)

について時間をかけて行った。
var $scaffold;

このscaffold;がCakeで肝になるが動作確認的な用途が大きい。
QueryログはCakeが自動的にsqlを見せることができる特徴な機能である。

$html->linkはphp内のリンクを呼び込んでくる引数になってる。

link($post['Post']['title'], 
"/posts/view/".$post['Post']['id']); ?>

この追加文はController文の中に記載。view.ctpを作成して、$idの番号を表示させよ。という文。
function view($id = null) {
$this->Post->id = $id;
$this->set('post', $this->Post->read());

ここのdebugモードを2→0へ書き換えるとdebug画面が消える。
Configure::write('debug', 2);

Configure::write('debug', 0);