tripwire
前回は、「明日は、mod_railsことpassengerをインストールしてみます。」とか書いたのですが、mod_railsを入れるためには、gemが入っていないといけませんでした。
今日は、まず、それをインストールしたいと思います。
前回同様fedora developからsrc.rpmを取ってきましょう。
$ cd src/ruby/
$ wget http://ftp.iij.ad.jp/pub/linux/fedora
/development/source/SRPMS/rubygems-
1.2.0-2.fc10.src.rpm
rpmbuildでリビルドします。
$ rpmbuild --rebuild ./rubygems-1.2.0-2.fc10.src.rpm
/usr/src/redhat/noarch/辺りにrpmファイルができているはずです。
$ ls /usr/src/redhat/RPMS/noarch/
rubygems-1.2.0-2.noarch.rpm
OKそうですのでインストールしましょう。
su - rpm -ivh /usr/src/redhat/RPMS/noarch/rubygems-1.2.0-2.noarch.rpm
入ったかどうか確認しましょう。gemコマンドを使ってみると分かります。
$ gem list
*** LOCAL GEMS ***
では、本題のmod_railsをインストールしましょう。
# gem install passenger
Building native extensions. This could take a while...
Successfully installed passenger-2.0.3
1 gem installed
Installing ri documentation for passenger-2.0.3...
Installing RDoc documentation for passenger-2.0.3...
# gem list
*** LOCAL GEMS ***
passenger (2.0.3)
今日はここまでとします。
次回は、mod_railsをビルドします。
11月 04
課題管理ツールって必要だと思います。
開発で使っているそうなので、インフラでも入れてみようと思います。
必要なもの
・ruby
・MySQL
・gem
・rails
・その他
インストールする環境
・CentOS 4.6
ま、とりあえずrubyから入れてみましょう。CentOSにデフォルトで入っているrubyは古いので入れ直しましょう。
rpmで管理できると便利ですね。ソースで管理すると面倒なので。
適当なrpmがありませんね。fedoraのdevelopmentから取ってきましょう。
http://ftp.iij.ad.jp/pub/linux/fedora/development/source/SRPMS/ruby-1.8.6.287-1.fc10.src.rpm
にしましょう。
wgetでダウンロードして、以下のコマンドでrpmバイナリファイルを作ります。
rpmbuild –rebuild ruby-1.8.6.287-1.fc10.src.rpm
エラー: Failed build dependencies:
libX11-devel is needed by ruby-1.8.6.287-1.i386
おお、CentOSには、libX11はありませんね。このrubyからはX(Tkなど)を使わないことにしてdepから削除しましょう。
コンパイルできたようです。
rpm -ivh /usr/src/redhat/RPMS/i386/ruby-*
でインストールします。
$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-linux]
$ irb
irb(main):001:0> print 1+1
2=> nil
問題ないようですね。
今日はここまで。
明日は、mod_railsことpassengerをインストールしてみます。
10月 27
InnoDBの主キーはクラスターインデックスだということを意識しよう から導き出されること
トランザクション系テーブルに主キーとして、AUTO_INCREMENTを使うのは100%ではないが、安全策と言えます。
マスター系のテーブルには自然キーを使うほうが良いでしょう。
※show table statusでRow_formatの設定値は確認出来ます。
MySQL 5.0.3以前のバージョンでは、REDUNDANTフォーマット、以降のバージョンではCOMPACTフォーマットがデフォルトになっている
COMPACTフォーマットで文字列型にすべて可変長を使用すれば、実際のデータ内容に応じて、20-30%程度は容量が節約できます。
これはディスク容量だけではなく、バッファプールの効率にも直結します。
これはmyisampackで作成するもの
InnoDBにはCOMPACTフォーマット
MyISAMにはFIXED
を使用しましょう。
※MyISAMをログ出力系にだけ使用するような場合は別です。この場合、MyISAMは
INSERTの処理性能によって選択されたので検索を速くする必要がないわけですから。
上記の物理フォーマットのことからも
InnoDBなら必ず可変長を選ぶ！
MyISAMなら固定長を選ぶ！
と言い切ってよいと思います。
できる限り効率性の高い（最小）の型を使用する！
MySQLのデータ型についてはこちらをどうぞ
このページの下の方に記載されている「初期化パラメータsql_mode」についてはMySQLのSQL_MODEとストリクトモードのほうが詳しく書いてあります。
7月 14
InnoDBについて一番大事なことは主キーがクラスターインデックスだということです。
クラスターインデックスでは、主キー(B-tree)のリーフページにデータが直接格納されています。
以下の図のようなイメージです。
一方、主キー以外のインデックス（副次インデックス）はリーフページに主キーの値を格納
していて、データにアクセスするためにそれを使用します。
以下の図のようなイメージです。
副次インデックスでデータにアクセスする場合に、
1)副次インデックスのB-treeより主キーを取得する
2)その主キーからデータをアクセスする
という２段階のアクセス経路になるというこです。
よって、副次キーでのアクセスは、たとえそれがユニークキーであったとしても、
主キーでのアクセスに比べて、倍近くのI/Oが発生することになります。
以下が計測した結果です。
InnoDB vs MyISAM パフォーマンス比較 PrimaryKEY、UniqueIndex、非UniqueIndex
「1.PrimaryKeyで一件検索」と「2.UniqueIndexで一件検索」のInnoDBどうしの結果を比較すると主キーに比べると、ユニークな副次インデックスは55%程度の性能しか出ていません。
データの格納場所が主キーの値でクラスター化されているので、
・データを連続してアクセスする場合（同一ページに存在する確率が高いので）、
バッファが有効に使用される
・同じ理由から主キーの昇順等でアクセスする場合に性能が高い
ということになります。
これも
「3.PrimaryKeyで範囲検索」と「4.非UniqueIndexで範囲検索」のInnoDBどうしの結果を比較すると
5倍程度の違いが出ています。
主キーでアクセスすると、必然的にデータにアクセスしてしまう。
よく、InnoDBはMyISAMに比較して、
SELECT COUNT(*) FROM テーブル ※where条件なし
が圧倒的に遅いと言われますが、その原因の一部が上記にあたります。
MyISAMの条件無しカウント処理が速いのは統計情報から結果を
取得するので当たり前なのですが、InnoDBがこの処理に関して
遅すぎ！なのは、条件無しカウント処理を主キーでアクセスするため
全データページにアクセスしてしまうためです。
SELECT COUNT(*) FROM テーブルの後ろに副次インデックスの
ヒントを付ければ速くなります。
主キーの値を変更する場合に、データ自体の格納場所を変更するためにコストが高い
副次インデックスのリーフページのすべてに主キーが格納されるため
主キーの項目長が長くなった場合の悪影響が大きい。
明示的に主キーを指定しない場合は以下の暗黙の主キーがMySQLによって設定されます
1)NOT NULL指定のユニークキーを指定している場合、それが主キーになる
7月 13
基本はＩｎｎｏＤＢです。
MyISAMを選択できるようなケースを考えてみます。
・完全に検索Onlyの場合（基幹系とかから一定間隔で検索用テーブルを再構築する。それ以外の時間は検索のみのようなケース。）
・ログ系のテーブルを出力のみする場合（insertは3～15倍程度MyISAMが高速）
正直、これくらいなのかなと思います。
パフォーマンスについては（5.0.37以上を選択すれば）InnoDBはMyISAMと比べてほとんど同じです。
以下は計測結果です。
InnoDB vs MyISAM パフォーマンス比較 PrimaryKEY、UniqueIndex、非UniqueIndex
InnoDB vs MyISAM パフォーマンス比較 取得件数が多い場合
InnoDB vs MyISAM パフォーマンス比較 SELECT ・・・ LIMIT N
InnoDB vs MyISAM パフォーマンス比較 副問い合わせ
InnoDB vs MyISAM パフォーマンス比較 Inner Join
InnoDB vs MyISAM パフォーマンス比較 Left Join
ただし、更新系性能についてはトランザクション管理がある(InnoDB)とない(MyISAM)とでは当然段違いに性能が違います。
InnoDB vs MyISAM パフォーマンス比較 UPDATE
InnoDB vs MyISAM パフォーマンス比較 DELETEとINSERT
UPDATEで7倍程度、deleteで4～7倍程度、insertでは前述した通りに3～15倍程度MyISAMが高速です。
ただ、トランザクションがないDBMSで正しく？更新処理を実行することは原則不可能なので、どうしようもありません。
6月 28
お問い合わせ
サイトマップ
