256bitの殺人メニュー

インフラエンジニアだったソリューションアーキテクトなくわののブログ。こちらのBlogは個人の意見となっていて会社とは全く関係ありません。お約束です。[twitter:@kuwa_tw]めんどくさがりが重い腰を上げて何かをアウトプットすることにどれほどの意味があるのかを試してみたいブログでもある。

MySQL5.5でパーティショニング使って時系列のデータを分散する

はい、乙カレーさまです。寒い日が続きますね。
そしてMySQLも続きそうな私です。


前回はトリガをやってみましたが、今度はパーティショニングをしてみます。

パーティショニングとは

パーティショニングは、特定のカラム情報を使って、テーブルを論理的/物理的に自動で分ける事で管理を簡単にしたり、パフォーマンスを確保する機能のことです。例えば今回は、更新日時でパーティショニングを行うことで、特定期間のデータを削除する等の運用が簡単になります。

パーテションの設定

プライマリキーの設定


まず既存のテーブルの場合は最初にパーテションを行うカラムがプライマリキーが含まれていないといけないので貼り直します。

mysql> ALTER TABLE usermaster_cs DROP PRIMARY KEY, ADD PRIMARY KEY(user_id, upd_datetime);
新規テーブルの場合

これから作るテーブルをパーティショニング対応するならCREATE TABLE文に含めることが出来ます。
この場合はupd_datetimeカラムを使用して、2013年1月からの月ごとのデータが入る様にパーティショニングを設定します。

mysql> CREATE TABLE `usermaster_cs` (
	  `user_name` varchar(255) NOT NULL,
	  `user_id` int(10) NOT NULL,
	  `type` int(10) DEFAULT NULL,
	  `status` int(10) DEFAULT NULL,
	  `upd_datetime` datetime NOT NULL,
	  PRIMARY KEY (`user_id`,`upd_datetime`)
	) ENGINE=InnoDB DEFAULT CHARSET=utf8
PARTITION BY RANGE  COLUMNS(upd_datetime)
(PARTITION p201301 VALUES LESS THAN ('2013-02-01 00:00:00') COMMENT = '2013-01',
 PARTITION p201302 VALUES LESS THAN ('2013-03-01 00:00:00') COMMENT = '2013-02' ,
 PARTITION p201303 VALUES LESS THAN ('2013-04-01 00:00:00') COMMENT = '2013-03' ,
 PARTITION p201304 VALUES LESS THAN ('2013-05-01 00:00:00') COMMENT = '2013-04' ,
 PARTITION p201305 VALUES LESS THAN ('2013-06-01 00:00:00') COMMENT = '2013-05' ,
 PARTITION p201306 VALUES LESS THAN ('2013-07-01 00:00:00') COMMENT = '2013-06' ,
 PARTITION p201307 VALUES LESS THAN ('2013-08-01 00:00:00') COMMENT = '2013-07' ,
 PARTITION p201308 VALUES LESS THAN ('2013-09-01 00:00:00') COMMENT = '2013-08' ,
 PARTITION p201309 VALUES LESS THAN ('2013-10-01 00:00:00') COMMENT = '2013-09' ,
 PARTITION p201310 VALUES LESS THAN ('2013-11-01 00:00:00') COMMENT = '2013-10' ,
 PARTITION p201311 VALUES LESS THAN ('2013-12-01 00:00:00') COMMENT = '2013-11' ,
 PARTITION p201312 VALUES LESS THAN ('2014-01-01 00:00:00') COMMENT = '2013-12' ,
 PARTITION p201401 VALUES LESS THAN ('2014-02-01 00:00:00') COMMENT = '2014-01' ,
);
既存テーブルの場合

既存のテーブルに設定するならALTER TABLE を使いましょう。

mysql> ALTER TABLE usermaster_cs
PARTITION BY RANGE COLUMNS(upd_datetime) (
PARTITION p201301 VALUES LESS THAN ('2013-02-01 00:00:00') COMMENT = '2013-01',
 PARTITION p201302 VALUES LESS THAN ('2013-03-01 00:00:00') COMMENT = '2013-02' ,
 PARTITION p201303 VALUES LESS THAN ('2013-04-01 00:00:00') COMMENT = '2013-03' ,
 PARTITION p201304 VALUES LESS THAN ('2013-05-01 00:00:00') COMMENT = '2013-04' ,
 PARTITION p201305 VALUES LESS THAN ('2013-06-01 00:00:00') COMMENT = '2013-05' ,
 PARTITION p201306 VALUES LESS THAN ('2013-07-01 00:00:00') COMMENT = '2013-06' ,
 PARTITION p201307 VALUES LESS THAN ('2013-08-01 00:00:00') COMMENT = '2013-07' ,
 PARTITION p201308 VALUES LESS THAN ('2013-09-01 00:00:00') COMMENT = '2013-08' ,
 PARTITION p201309 VALUES LESS THAN ('2013-10-01 00:00:00') COMMENT = '2013-09' ,
 PARTITION p201310 VALUES LESS THAN ('2013-11-01 00:00:00') COMMENT = '2013-10' ,
 PARTITION p201311 VALUES LESS THAN ('2013-12-01 00:00:00') COMMENT = '2013-11' ,
 PARTITION p201312 VALUES LESS THAN ('2014-01-01 00:00:00') COMMENT = '2013-12' ,
 PARTITION p201401 VALUES LESS THAN ('2014-02-01 00:00:00') COMMENT = '2014-01' ,
);


稼働中ならPercona-Toolkitで提供しているpt-online-schema-changeで無停止で行うことが出来ます。ありがたやありがたや。

pt-online-schema-change --charset="utf8" --set-vars="sql_log_bin=OFF" --execute --alter="
PARTITION BY RANGE COLUMNS(upd_datetime) (
PARTITION p201301 VALUES LESS THAN ('2013-02-01 00:00:00') COMMENT = '2013-01',
(snip)
 PARTITION p201401 VALUES LESS THAN ('2014-02-01 00:00:00') COMMENT = '2014-01' ,
);" h=localhost,D=database,t=usermaster_cs,u=dbuser
パーテション追加

もし、2014年2月分のレンジ追加を行う場合は以下のSQLで可能です。

mysql> ALTER TABLE usermaster_cs
ADD PARTITION (
PARTITION p201412 VALUES LESS THAN ('2014-03-01 00:00:00') COMMENT = '2014-02' ENGINE = InnoDB,
);

実行時はロックがかかります。データが無ければ一瞬で終わりますが、気になる場合は前述のpt-online-schema-changeを使いましょう。


レンジを都度追加していく場合はもしもレンジの追加を忘れていた場合等に、その存在しないパーテションレンジへデータの追加しようとした場合にはデータ追加が出来ない、と言う事になります。


その場合はMAXVALUEを指定して、このレンジよりも最新のデータはこのパーテションレンジで救う事が可能となります。素晴らしい。

mysql> ALTER TABLE usermaster_cs ADD PARTITION (PARTITION pmaxvalue VALUES LESS THAN (MAXVALUE));


その代わり2月分をまとめたい、と言う話になった場合はREORGANIZE PARTITIONでパーテションレンジを分離する必要が出てきます。
どっちが楽かみたいな話はありますが、自動でADDするような仕組みを作るならMAXVALUEは設定しなくてもいいかもしれないですね。

mysql> ALTER TABLE usermaster_cs REORGANIZE PARTITION pmaxvalue INTO (
    PARTITION p201412 VALUES LESS THAN ('2014-03-01 00:00:00') COMMENT = '2014-02',
    PARTITION pmaxvalue VALUES LESS THAN (MAXVALUE)
);
パーテション削除

(2014/2/8:追記 削除完全に書き忘れてたw)
2013年1月のデータが要らなくなったんで削除したい、と言う場合はDROP PARTITIONで該当のパーテションを削除したらOKです。
これもそんなに時間かからないですが、ロックかかるので気になる環境であればpt-online-schema-change使いましょう。
当たり前ですけどデータも消えちゃうので注意。

mysql> ALTER TABLE usermaster_cs DROP PARTITION p201301;
データ入れ込み

じゃあデータを入れてみませう。(実際はトリガでデータを入れ込む予定)

mysql> insert into usermaster_cs select * from copy_source_table;

設定の確認

SHOW CREATE TABLE

SHOW CREATE TABLE を使用すると、パーティショニングされたテーブルの作成に使用されたPARTITION句をみると大体わかります。

mysql> SHOW CREATE TABLE usermaster_cs;
(snip)
SHOW TABLE STATUS

SHOW TABLE STATUS を使用するとテーブルがパーティショニングされているかを判定することができます。

mysql> SHOW TABLE STATUS \G
(snip)
 Create_options: partitioned
(snip)

INFORMATION_SCHEMAで確認

下記クエリでusermaster_csにあるパーテションを確認できます。

mysql> SELECT * FROM INFORMATION_SCHEMA.PARTITIONS WHERE table_name='usermaster_cs' \G
EXPLAIN PARTITIONS SELECT

EXPLAIN PARTITIONS SELECT ステートメントを使用するとパーティショニング環境のクエリのEXPLAINが行うことができます。
どのパーティションが SELECT で使用されているか判別できます。


条件を入れない場合は全てのパーテションに対してアクセスが行くのに対して、

mysql> EXPLAIN PARTITIONS SELECT * FROM usermaster_cs \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: usermaster_cs
   partitions: p201301,p201302,p201303,p201304,p201305,p201306,p201307,p201308,p201309,p201310,p201311,p201312,p201401,pmaxvalue
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 68886025
        Extra:
1 row in set (0.00 sec)


条件を入れた場合には該当パーテションにだけアクセスが行くことがわかります。

mysql> EXPLAIN PARTITIONS SELECT * FROM usermaster_cs WHERE upd_datetime='2013-10-30 21:04:06' \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: usermaster_cs
   partitions: p201310
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 2247981
        Extra: Using where
1 row in set (0.00 sec)


この前のトリガと組み合わせると特定テーブルのデータを別テーブルで期間保存とか出来たりして便利かもしれないですね。
ではでは三ʅ(◔౪◔ʅ)三(ʃ◔౪◔)ʃ


実践ハイパフォーマンスMySQL 第3版

実践ハイパフォーマンスMySQL 第3版


MySQLでトリガ使って別テーブルに自動でコピる

はい、おつカレーさまさまです。桑野です。
ブログを更新できなくて落ち込んだりもするけれど私は元気です。


もんごさんとかもんご野郎とかよく言われる昨今ですが最近久しぶりにMySQLを触っているのでその話を。
そーいえばMySQLのトリガ設定とかほぼやったことなかったので、メモ書き。

トリガとは

トリガというのは、特定のテーブルにある操作(UPDATE,INSERT,DELETE)が行われた時にイベント駆動的に実行される機構のことですね。

トリガ作成

CREATE TRIGGER で作成されます。

トリガの設定

下準備

GRANT でトリガを設定するユーザにTRIGGER権限を与えておきましょう。

GRANT TRIGGER ON `user`.* TO 'dbuser'@'192.168.0.%' IDENTIFIED BY 'dbpass';
元テーブル定義
mysql> CREATE TABLE `usermaster` (
	  `user_name` varchar(255) NOT NULL,
	  `user_id` int(10) NOT NULL,
	  `type` int(10) DEFAULT NULL,
	  `status` int(10) DEFAULT NULL,
	  `upd_datetime` datetime NOT NULL,
	  PRIMARY KEY (`user_id`)
	) ENGINE=InnoDB DEFAULT CHARSET=utf8 

複製先テーブル作成

同じテーブル定義のテーブルを作成します。

mysql> CREATE TABLE usermaster_cs LIKE usermaster;

TRIGGER設定

注意
  • 変更前の行のデータはOLDに、更新、挿入される新しいデータはNEWで表現される
  • TRIGGERは [AFTER / BEFORE] * [INSERT/UPDATE/DELETE]の条件で1つしか設定できない
  • もし複数SQL実行したいならBEGIN〜ENDでまとめよう
TRIGGER作成[INSERT]

AFTER / BEFORE で、イベント実行後、前にTRIGGERを実行するか設定できます。
これはINSERT用。適当に書いちゃったけど良い書き方ないかなぁ。

mysql> 	DELIMITER |
mysql> 	CREATE TRIGGER userm_insert AFTER INSERT
	 ON usermaster FOR EACH ROW
	 BEGIN
	 INSERT INTO usermaster_cs SET 
	   `user_name`=NEW.`user_name`, 
	   `user_id`=NEW.`user_id`, 
	   `type`=NEW.`type`, 
	   `status`=NEW.`status`, 
	   `upd_datetime`=NEW.`upd_datetime`;
	 END;
	|
mysql> 	DELIMITER ;
TRIGGER作成[UPDATE]

こっちはUPDATE用、大して変わらん。

mysql> DELIMITER |
mysql> CREATE TRIGGER userm_update AFTER UPDATE
	 ON usermaster FOR EACH ROW
	 BEGIN
	 UPDATE usermaster_cs SET 
	   `user_name`=NEW.`user_name`, 
	   `user_id`=NEW.`user_id`, 
	   `type`=NEW.`type`, 
	   `status`=NEW.`status`, 
	   `upd_datetime`=NEW.`upd_datetime`
	   WHERE `user_id`=OLD.`user_id`;
	 END;
	|	
mysql> DELIMITER ;

テスト実行

INSERT確認
ますたーでINSERT
mysql> INSERT INTO usermaster SET 
	   user_name="kuwano", 
	   user_id=1000000, 
	   type=7, 
	   status=1, 
	   upd_datetime="2014-01-17 00:00:00";
すれーぶで確認

はいっとるはいっとる。

mysql> SELECT * FROM usermaster_cs WHERE user_name="kuwano";
UPDATE確認
ますたーでUPDATE
mysql> UPDATE usermaster SET 
	   user_name="mongo", 
	 WHERE user_id=1000000;
すれーぶで確認

かわっとるかわっとる。

mysql> SELECT * FROM usermaster_cs WHERE user_name="kuwano";
mysql> SELECT * FROM usermaster_cs WHERE user_name="mongo";

運用系

トリガの削除

DROP TRIGGERで行うます。
IF EXISTSでuserm_insertトリガがあるなら削除です。

mysql> DROP TRIGGER IF EXISTS userm_insert ;
トリガの設定確認

トリガの設定確認がしたい場合はSHOW TRIGGERSで。

mysql> SHOW TRIGGERS;
(snip)

| userm_insert | INSERT | usermaster | 
 BEGIN
 UPDATE usermaster_cs SET 
   `user_name`=NEW.`user_name`, 
   `user_id`=NEW.`user_id`, 
   `type`=NEW.`type`, 
   `status`=NEW.`status`, 
   `upd_datetime`=NEW.`upd_datetime`
 END                                                                                   | AFTER  | NULL    |          | root@localhost | utf8                 | utf8_general_ci      | utf8_general_ci    |

| userm_update | UPDATE | usermaster | BEGIN
 UPDATE usermaster_cs SET
   `user_name`=NEW.`user_name`, 
   `user_id`=NEW.`user_id`, 
   `type`=NEW.`type`, 
   `status`=NEW.`status`, 
   `upd_datetime`=NEW.`upd_datetime`
   WHERE `user_id`=OLD.`user_id`;
 END | AFTER  | NULL    |          | root@localhost | utf8                 | utf8_general_ci      | utf8_general_ci    |

余談

実行がそもそも走ってるかどうかよくわからん時はテスト時だけはgeneral_logとか有効にしてみるといいよ。

my.cnfで以下を有効に。

general_log = On
general_log_file=general.log

もしくは、SET GLOBALで。

SET GLOBAL general_log = 'ON';

ではでは三(卍^o^)卍ドゥルルルル

実践ハイパフォーマンスMySQL 第3版

実践ハイパフォーマンスMySQL 第3版

『インフラエンジニアの教科書』この本をなんと呼ぶ?教科書と呼ぶ!

ぼくがいわゆる、インフラエンジニア。サーバサイド等をやるエンジニアになった時に何かに詰まったり、気になった事ができた時にGoogleで検索して、良く出てくるページが有ったんです。それは「sanonosa システム管理コラム集」でした。
その頃はインターネット上の情報もそんなに多くなくて、sanonosaさんの知識は幅広いしありがたいなぁ、と思ってました。
それから、ぼくのRSSリーダー(その頃はWebで見れるRSSリーダーってあんまりなかったですねw)には長らく、 @ さんのブログは入っていたと記憶しています。


その@ さんの書いたインフラエンジニア向けの本が出るということで、もし初心者向けだったとしても買うしかない、と思って即決で買った本が、こちらの『インフラエンジニアの教科書』です。



インフラエンジニアの教科書

インフラエンジニアの教科書


初心者向けだったとしても、みたいなことを言いましたが、結論から言うと、現役のインフラエンジニアでも読んで損はない本だよ、と言う本でした。
ホントすいません(; ・`ω・´)

概要

インフラエンジニア、と言われている職種がどのような仕事をし、それを実現するためにどのような知識が必要なのかを網羅的に説明している本になります。

内容

まず最初に思ったのは、インフラ技術にフォーカスした本は多くても、インフラエンジニアと言うテーマに沿った本、というのはあんまり無い本だなぁと。
そして、さらにいうと、購買関連の知識まで書いた本というのはエンジニア向けの本としてはあんまりみたことなくてカバー範囲すげぇ!と本当に感心しました。


多かれ少なかれ、技術書、というのはハウツー本、の様相を呈しているものだとおもいますが、この本は、教科書です。
教科書には、やり方だけではなく、本質的な事もかいてあります。
もちろん、一つ一つの事柄にはもっと深い理由や、細かい事象が存在しています、ですが、教科書に必要なことは、あるテーマに対して全てを網羅し、必要な事に対するとっかかりを残しておくこと。だと思っています。
この本はサーバ、ネットワークから始まり、セキュリティ、運用、購買、商談、ファシリティ、セキュリティ、データセンタ。
これだけの内容を200ページ足らずの1冊に含めて、説明できていることが、脅威です。


もちろん、これだけの内容の全てを語りきれてはいないかもしれませんが、これぞ、まさに、教科書です。
「教科書」が達成できていると感じました。


さらに、最初に書いたようなエンジニアである@ さんの知見が随所にみられ、自分の知識と照らし合わせることで正しいのかな、どうなのかな?と考えながら読み進めるだけでも面白くためになる本でもあります。
非常に読みやすいため、飽きずに最期まで読めてしまいました。


ぼくらの業界では時間の流れが早い事もあって、こういった根本的な部分って業務で触るまで何があるのか、わからんとなることも多く、それって世界を無駄に狭くして(た|る)よなーって思うことがあります。こういった本があることで、そうかー、こういう仕事をしていくといいのかな?とかこういう仕事をしたい!とかそういった事を考えるキッカケになるかなーと思います。*1

まとめ

これから、少なくともインフラエンジニアといわれている(この呼び方には賛否がある方もいるかと思いますが、サーバサイド、から物理層、のレイヤーが下よりの)エンジニアを目指している方、現在そのような仕事をしている方には勉強、共感、比較、いろんなことができる本だと思いますので是非読んでみてはいかがかと思います。


最後に、、、サインくださいm(_ _)m

インフラエンジニアの教科書

インフラエンジニアの教科書


中国超人インフラマン [Blu-ray]

中国超人インフラマン [Blu-ray]

*1:本来現場の人間がちゃんとやれよって話ではあるんですけど、、、なかなか難しいことも多いですよね(;´Д`)

pyenv+virtualenv環境の作成方法まとめマン

はい、おつカレー様です。
桑野です。
最近暑いですね、カレーが捗りますか?ぼくは捗ってます。


最近PythonでWebアプリを書いたりもしているんですが、環境構築についてちょこちょこまとめておこうと思いまして書きます。

今日はpyenvの環境作成について、、、要するに自分メモですw

pyenv

Pythonでアプリやら、スクリプトやら使うのにpyenv環境、本番とかでもCentOS6でも使われるPythonは2.6系だったりして、3.3とか、2.7系を使いたい時にいちいちRPMビルドをしたくないし、Pythonのバージョンアップしたい時等、環境もわかりやすくなるし、ぐちゃぐちゃになったら作り直せるしpyenvは便利。

必要なパッケージのインストール。
$ sudo yum install vim gcc gcc-c++ make git openssl-devel zlib-devel readline-devel sqlite-devel bzip2-devel
pyenvのインストールと環境設定

まずインストールしましょ。
git cloneしてもってきましょ。

$ cd ~
$ git clone git://github.com/yyuu/pyenv.git .pyenv


次に.bashrcに環境変数を設定しましょ。
必要なのは、PYENV_ROOTとPYENV_ROOT/binにPATH通すこと。
通したら pyenv initでpyenvを使用する準備は完了です。

export PYENV_ROOT="${HOME}/.pyenv"
export PATH=${PYENV_ROOT}/bin:$PATH
eval "$(pyenv init -)"


.bashrcと.bash_profileにも入れておきましょう。

$ cat <<'EOF' >>~/.bashrc
export PYENV_ROOT="${HOME}/.pyenv"
if [ -d "${PYENV_ROOT}" ]; then
    export PATH=${PYENV_ROOT}/bin:$PATH
    eval "$(pyenv init -)"
fi
EOF
$ cat <<'EOF' >>~/.bash_profile
export PYENV_ROOT="${HOME}/.pyenv"
if [ -d "${PYENV_ROOT}" ]; then
    export PATH=${PYENV_ROOT}/bin:$PATH
    eval "$(pyenv init -)"
fi
EOF
pyenv-virtualenv

pyenvはプラグインが使用できますが、pyenv-virtualenvはpyenvでvirtualenv環境を構築するのに必要なプラグイン(他になんかあるのかな?)

$ source ~/.bashrc
$ cd ${PYENV_ROOT}/plugins
$ git clone git://github.com/yyuu/pyenv-virtualenv.git
pyenv環境のPythonインストール

後はpyenvコマンドでPythonインストールしましょ。

$ cd ~
# インストールできるPython環境の一覧表示
$ pyenv install -l
# バージョン2.7.5のPythonのインストール
$ pyenv install 2.7.5
# バージョン2.7.5のPythonをもとにした、django-devというVirtualEnv環境の作成
$ pyenv virtualenv --distribute 2.7.5 django-dev
使い方
$ cd ~
# global環境のPython変更(このpyenvを使用する場合デフォルト2.7.5が使用される)
$ pyenv global 2.7.5
# local環境のPython変更(実行ディレクトリに.python-versionファイルが作成され、そこ以下のディレクトリのPythonはlocal環境として使われる)
$ pyenv local django-dev
$ cat .python-version
django-dev


そんな感じで便利なので使ってみましょう!ではでは。


パーフェクトPython (PERFECT SERIES 5)

パーフェクトPython (PERFECT SERIES 5)


ラスト・アナコンダ [DVD]

ラスト・アナコンダ [DVD]

doxygen と graphviz でクラス図を出してみる

はい、おつカレー様です。
夏はカレーとビールですね。


最近bottleのソースコードリーディング的な事をやっていたりするのですが、これをやっている際にdoxygenでのクラス図生成が便利だったので、メモリん。
環境はCentOS6系です。

doxygengraphvizのインストール

yum。楽チン。

# yum install doxygen graphviz

bottleのソースも落としておきましょう。

$ mkdir bottle bottle_doxygen
$ wget  http://bottlepy.org/bottle.py -O ./bottle/bottle.py

設定ファイルのテンプレート生成

次にDoxygenの設定ファイルのテンプレートを出力しましょう。

$ doxygen -g Doxyfile
$ cat Doxyfile  | grep -v ^# | grep -v ^$
DOXYFILE_ENCODING      = UTF-8
PROJECT_NAME           =
PROJECT_NUMBER         =
OUTPUT_DIRECTORY       =
CREATE_SUBDIRS         = NO
OUTPUT_LANGUAGE        = English
BRIEF_MEMBER_DESC      = YES
REPEAT_BRIEF           = YES
ABBREVIATE_BRIEF       =
ALWAYS_DETAILED_SEC    = NO
INLINE_INHERITED_MEMB  = NO
FULL_PATH_NAMES        = YES
STRIP_FROM_PATH        =
STRIP_FROM_INC_PATH    =
SHORT_NAMES            = NO
(snip)

設定ファイル変更

今のディレクトリ構成にしたがって変更。

$ diff Doxyfile.org Doxyfile
28c28
< PROJECT_NAME           =
---
> PROJECT_NAME           = bottle
41c41
< OUTPUT_DIRECTORY       =
---
> OUTPUT_DIRECTORY       = ./bottle_doxygen/
571c571
< INPUT                  =
---
> INPUT                  = ./bottle/
991c991
< GENERATE_LATEX         = YES
---
> GENERATE_LATEX         = NO
1360c1360
< HAVE_DOT               = NO
---
> HAVE_DOT               = YES
項目名 意味
PROJECT_NAME プロジェクト名(適当に)
OUTPUT_DIRECTORY HTML出力先を指定
INPUT ソースディレクトリを指定
GENERATE_LATEX LATEX出力が要らないので。いるならYESのまま。
HAVE_DOT クラス図を出力する

doxygen実行

これだけです。デフォルトがDoxyfileになってるんで、この場合は $ doxygen だけでもOKです。

$ doxygen Doxyfile

ブラウザからみたい

場合はApacheとかの公開ディレクトリに置きましょう。(すいませんw適当w)

$ /bin/cp -rf bottle_doxygen/html/ /var/www/doxygen/bottle/

こんな感じででます。

いじょ。

#bpstudy 71さん で「後悔しないもんごもんごの使い方 」という発表しました

はい、乙カレー様です。桑野です。


おくれちゃいましたが、7/31に開かれましたbpstudy #71にて発表して参りました。
@ さんにアプリ側のお話をしていただき、私の方でサーバ側でそもそもユースケースとはどんなものか、というお話をしました。


一部では@ さんによる、「運用が楽になる分散データベース Riak」という発表をされていて、運用はホント楽そうだよなーと指をくわえてみたりもしましたw
Riakの話はいろんな場所で聞きますが、アーキテクチャが綺麗にまとまっているイメージで、クラスタリングKVSとしてはよっぽどの環境でなければ安定運用できるんじゃないでしょうか。と思っています。


そして、二部では私達が「運用を楽に"したい"分散データベース MongoDB」という事でお話したわけですが、以前のWEB+DB PRESSさんの記事を書いた時にもちょっとブログで書きましたが、ユースケースによってNoSQLに対する印象は変わると思っております。
MongoDBは結構苦労するNoSQLだとは思いますw が、使い道ではある程度良い部分をいいとこ取りできますよっていう部分が伝われば幸いかと。
丸の内MongoDB勉強会の方々が最近はその辺りを布教されていますので、勉強会にでて詳しい話をきいてみるのも良いかと思います。


NoSQLを擬人化するならMongoDBは明るい大雑把なキャラになるとおもいますw
Riakは真面目な感じで、Cassandraは多分高飛車な感じでしょうかねどうですか!サーバ擬人化ユーザ会の皆様!?、、、って急におかしな話をしましてすいません(; ・`ω・´)

最後に

出演者の方々。
聞いてくださった方。
bpstudy運営の方々。

皆様ありがとうございました!!

資料

後半アプリ編


WEB+DB PRESS Vol.75

WEB+DB PRESS Vol.75


謎の惑星モンゴ [VHS]

謎の惑星モンゴ [VHS]

『Web+DB Press Vol.75』にMongoDB徹底入門を書かせて頂きました。

はい、おつカレー様です。くわのです。
気づいたらすっげーーーーーーーーーーBlog書いてなくて、やべーなこれって思ったので今後は書いて行こうと思っています(´;ω;`)


と、今回も書籍の話だったりするんですが(汁
Web+DB Press Vol.75』に第2特集としてMongoDB徹底入門を書かせて頂きました。



@さんと一緒に書いたのですが、僕の日本語のおかしい部分をまつかずさんは直してくれたのでぼくは一生頭が上がらないのだと思いますが、そういう意味では僕と一緒に記事を書いた人全てに僕は頭が上がらないのだなと思うと、僕は頭を下向きに固定して生きたほうが生きやすいんじゃないかと、僕は、、、僕はあああぁあぁ!
、、、また取り乱しました。すいません。

特集の内容

読者の対象としては、MongoDBを触ったことない人向けとなっています。
記事の内容は、

  • MongoDBのユースケース
  • 一般的な使い方の説明
  • 開発を行うにあたっての障壁が少ない、と言う利点

の部分等を二人で書いて行きました。
やはりドキュメント指向/スキーマレスたるMongoDB的には開発が簡単である、と言う部分を入れてなんぼであろうという所もあったためです。


僕の方では特に、ユースケースは気をつけて書いた部分になります。
日本では特にですが、世間一般的にMongoDBへログを貯めるという方法をよく紹介されていますが、窪田さんの訳されているこの記事のように、どのように使ったらいいかはよく考えて使わないと痛い目を見る事があるよ、と言った部分は伝えたいなと思ってユースケースの部分は書きました。


って、なんだこれ、脅しか?この記事こわいwww

ともあれ

結構NoSQLはネガティブな捉え方をされる場合も多いですが、使い道によっては非常に開発スピードが早くしたり、柔軟なサービス開発の役に立つ事もあります。
興味を持っていただけたらお手にとってもらえれば幸いと思っています。


Web+DB Press Vol.75』は「継続的Webサービス改善ガイド」、SPDY、Chefといったおもしろい記事も多いですよ!!!


WEB+DB PRESS Vol.75

WEB+DB PRESS Vol.75