Mar 10, 2005

SQLiteに移行した件について。

SixApart Professional NetworkのMLをチェックされている方はご存知だと思いますが、先月末あたりからTimothy Appnelのエントリーをきっかけに(私自身も含めて)SQLiteネタで盛り上がっていました。それが理由というわけではありませんが、このブログも「MySQL+ダイナミックパブリッシング」から「SQLite+スタティックページ」に移行してみました。

以降では「ダイナミックパブリッシング」「スタティックページ」をそれぞれ「DP」「SP」と略記します。

でなぜ移行を思い立ったかというと、以前から(細かいバグの件は別にして)DPはイマイチだなーと感じていたことがあったからです。少し詳しく説明すると以下のような現象・事実があるのです。

「DPに失敗した際に表示されるエラーページが検索エンジンbotにクロールされてキャッシュされている例を散見する」

ロリポップの場合、時間帯によってはMySQLサーバーが過負荷状態になってクエリーに応えられずDPに失敗することがしばしばあるため、このような現象が観測されます。他のレンタルサーバーでも同じ状況は発生し得ますが、ロリポップは10数万のユーザーに対してわずか6台のMySQLサーバーしか用意されておらず(もちろん全ユーザーがMySQLを利用するわけではありません。おそらく10%以下でしょう。)、極めて状況が悪いと言えるでしょう。

「CGIの実行時間を制限するサーバーでは、再構築時、実はSPよりDPの方がInternal Server Errorを起こしやすい」

例として個別アーカイブをすべて再構築する場合を考えると分かりやすいです。SPでは(mt.cfgの)EntriesPerRebuildで指定された個数(既定では40個)ずつ再構築していくために一回ずつのCGI実行時間は短く保たれます。一方、DPでは個別アーカイブの再構築は行われない代わりにFileInfo(個別アーカイブの動的生成に必要な情報)の更新が行われますが、この作業はEntriesPerRebuildの値に関わらず一回のCGI実行で一度に行います。

前者(SP)の一回ずつのCGI実行時間はエントリー数が増加してもほぼ一定で、またEntriesPerRebuildに小さ目の値を設定することでInternal Server Errorを積極的に回避することもできます。MySQLサーバーがビジーで再構築に失敗しがちな場合にもこの対処が一定程度有効です。しかし、後者(DP)の所要時間はエントリー数の増加とともに単調に増加するのみでユーザー側から制御する手段がありません。

つまり、サーバー環境によってはダイナミックパブリッシングは(仮に使えたとしても)実用的でない場合があるということです。

SQLiteを使う場合、現状ではDPは使えませんから上記の問題は半ば強制的に解決します。また、MySQLサーバーの負荷状況に依存しない(Webサーバーの負荷状況にだけ依存する)という利点もあります。各Webサーバーに一つずつMySQLサーバーを立ち上げてくれればDPでも構わないわけですが、一応バックアップを取ったりデーモンが落ちたら再立ち上げする管理コストや、ストレージ容量の問題があるのでしょうね。

さて、Movable TypeでのSQLiteのおおまかな利用方法に関しては随分前のエントリーに書いてあります。

Ogawa::Buzz: SQLiteをMovable Typeで使ってみる

上記のエントリーはDBD-SQLite 0.31(SQLite 2.8.12相当)を前提に書いたものです。その後DBD-SQLite 1.08(SQLite 3.1.3相当)がリリースされて、Version 3系のSQLiteとMovable Typeを組み合わせて利用できるようになりました(当時はできませんでした)。それに応じて上記エントリーには記述を追加してあります。

また、SQLite2系とSQLite3系の性能差に興味があるSQLiteマニアな人は、下記のエントリーも参考にされるとよいでしょう。AutoCommitをOnにした状態のままでもSQLite3にするだけで4~9%程度の速度改善が期待できます。

Ogawa::Buzz: Benchmark: Importing Multiple Entries

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com