障害監視,運用保守,URL監視,レスポンス監視の24時間365日サービス Tripwire、MySQL Enterpriseの販売・サポートは ビーグッド・テクノロジー

MySQLブログ エントリ一覧



前回は、「明日は、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をビルドします。

課題管理ツールって必要だと思います。
開発で使っているそうなので、インフラでも入れてみようと思います。

必要なもの
・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をインストールしてみます。

1.適切な主キーを設定する

InnoDBの主キーはクラスターインデックスだということを意識しよう から導き出されること

  • 更新する可能性がある項目は主キーにしない(主キーの更新はコスト高い!)
  • 主キーの項目長はなるべく小さく(全部のインデックスページの容量に悪影響!)
  • できる限り主キーでアクセスする(副次インデックスにくらべて倍は速い!)

トランザクション系テーブルに主キーとして、AUTO_INCREMENTを使うのは100%ではないが、安全策と言えます。
マスター系のテーブルには自然キーを使うほうが良いでしょう。

2.物理フォーマットの選択

 ※show table statusでRow_formatの設定値は確認出来ます。

InnoDBの物理フォーマット

MySQL 5.0.3以前のバージョンでは、REDUNDANTフォーマット、以降のバージョンではCOMPACTフォーマットがデフォルトになっている

  • 少なくともREDUNDANTフォーマットでは、固定長が有利な点は一つもない
  • 固定長にたいしても、カラム数やカラム長といった冗長な情報を含む

COMPACTフォーマットで文字列型にすべて可変長を使用すれば、実際のデータ内容に応じて、20-30%程度は容量が節約できます。
これはディスク容量だけではなく、バッファプールの効率にも直結します。

MyISAMの物理フォーマット

  • 静的テーブル(FIXED)
  • データ型にVARCHAR、TEXT、BLOBを含んでいない場合に選択される
    • なにより一番速い
      • データファイル中の行がディスク上で即時見つけられる
      • キャッシュ動作が単純になる
    • 動的フォーマットテーブルよりもディスクの領域を消費する
      • CHARやVARCHARは不足部分に空白が埋められる
      • BINARYとVARBINARYカラムは不足部分にが0×00で埋められる
    • クラッシュした後も修復出来る確率が高い
  • 動的テーブル(DYNAMIC)
    • 可変長項目(VARCHAR、 VARBINARY、 BLOB、または TEXT)を含むとこれが採用される
    • BLOBやTEXTカラムが無いテーブルなら静的テーブル(FIXED)も指定可能
  • 圧縮テーブル
  • これはmyisampackで作成するもの

結論

    InnoDBにはCOMPACTフォーマット
    MyISAMにはFIXED
 を使用しましょう。

 ※MyISAMをログ出力系にだけ使用するような場合は別です。この場合、MyISAMは
  INSERTの処理性能によって選択されたので検索を速くする必要がないわけですから。

3.適切なデータ型の選択(文字列型)

 上記の物理フォーマットのことからも
  InnoDBなら必ず可変長を選ぶ!
   MyISAMなら固定長を選ぶ!
 と言い切ってよいと思います。

4.適切なデータ型の選択(数値型)

 できる限り効率性の高い(最小)の型を使用する!

 MySQLのデータ型についてはこちらをどうぞ
 このページの下の方に記載されている「初期化パラメータsql_mode」についてはMySQLのSQL_MODEとストリクトモードのほうが詳しく書いてあります。

 

関連会社インターオフィスのブログ記事を転載しています。

InnoDBについて一番大事なことは主キーがクラスターインデックスだということです。

クラスターインデックスでは、主キー(B-tree)のリーフページにデータが直接格納されています。

以下の図のようなイメージです。

クラスターインデックス


一方、主キー以外のインデックス(副次インデックス)はリーフページに主キーの値を格納
していて、データにアクセスするためにそれを使用します。

以下の図のようなイメージです。

非クラスターインデックス


主キーがクラスターインデックスであることの必然的結果 NO1

副次インデックスでデータにアクセスする場合に、
 1)副次インデックスのB-treeより主キーを取得する
 2)その主キーからデータをアクセスする
という2段階のアクセス経路になるというこです。

よって、副次キーでのアクセスは、たとえそれがユニークキーであったとしても、

主キーでのアクセスに比べて、倍近くのI/Oが発生することになります。

以下が計測した結果です。
InnoDB vs MyISAM パフォーマンス比較 PrimaryKEY、UniqueIndex、非UniqueIndex

「1.PrimaryKeyで一件検索」と「2.UniqueIndexで一件検索」のInnoDBどうしの結果を比較すると主キーに比べると、ユニークな副次インデックスは55%程度の性能しか出ていません。

主キーがクラスターインデックスであることの必然的結果 NO2

データの格納場所が主キーの値でクラスター化されているので、
 ・データを連続してアクセスする場合(同一ページに存在する確率が高いので)、
  バッファが有効に使用される
 ・同じ理由から主キーの昇順等でアクセスする場合に性能が高い

ということになります。

これも
「3.PrimaryKeyで範囲検索」と「4.非UniqueIndexで範囲検索」のInnoDBどうしの結果を比較すると
5倍程度の違いが出ています。

主キーがクラスターインデックスであることの必然的結果 NO3

主キーでアクセスすると、必然的にデータにアクセスしてしまう。
よく、InnoDBはMyISAMに比較して、
SELECT COUNT(*) FROM テーブル ※where条件なし

 が圧倒的に遅いと言われますが、その原因の一部が上記にあたります。
 MyISAMの条件無しカウント処理が速いのは統計情報から結果を
 取得するので当たり前なのですが、InnoDBがこの処理に関して
 遅すぎ!なのは、条件無しカウント処理を主キーでアクセスするため
 全データページにアクセスしてしまうためです。
 SELECT COUNT(*) FROM テーブルの後ろに副次インデックスの
 ヒントを付ければ速くなります。

主キーがクラスターインデックスであることの必然的結果 NO4

主キーの値を変更する場合に、データ自体の格納場所を変更するためにコストが高い

主キーがクラスターインデックスであることの必然的結果 NO5

副次インデックスのリーフページのすべてに主キーが格納されるため
主キーの項目長が長くなった場合の悪影響が大きい。

その他 InnoDBのクラスターインデックスについて重要なこと

明示的に主キーを指定しない場合は以下の暗黙の主キーがMySQLによって設定されます
   1)NOT NULL指定のユニークキーを指定している場合、それが主キーになる


   2)それも無ければ、6byteのROWIDが主キーになる

 

関連会社インターオフィスのブログ記事を転載しています。

基本はInnoDBです。

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で正しく?更新処理を実行することは原則不可能なので、どうしようもありません。

 

関連会社インターオフィスのブログ記事を転載しています。