おいぬま日報(不定期)

@ [mysql] InnoDBを使う

4.0系の場合、トランザクション対応のInnoDB型テーブルを使うに当たっては、特に何も設定しなくても良いみたいです。ただし、my.cnfに skip-innodb という項目があるとInnoDBが使えないので、これがある場合はコメントアウトしておきます。そして下記のようにトランザクションが使えるかテスト。

mysql> use hoge;
mysql> create table test(a char(4)) type=InnoDB;
mysql> insert into test values('a001');
mysql> begin;
mysql> insert into test values('a002');
mysql> select * from test;
+------+
| a    |
+------+
| a001 |
| a002 |
+------+
2 rows in set (0.00 sec)
mysql> rollback;
mysql> select * from test;
+------+
| a    |
+------+
| a001 |
+------+

よしよし、徐々に思い出してきました。

@ [eclipse] Clayプラグイン

Eclipse用データベースモデリングプラグイン。テーブル設計からDDLの生成まで面倒見てくれる。動作環境にはEclipse 2.1.1/2.1.2/2.1.3 としか書かれてないのですが、3.0.1でもちゃんと動きました。なかなかいい線いってると思います。

@ [db] SAK Streets/SQL 開発言語資料

SQLの基礎から、OracleのPL/SQL、PostgreSQL、MySQLの情報がどっさり。DB関連でこれだけまとまった情報があるサイトってのもすごい。

@ [work] DB設計終わり

一番の難儀だったはずのものが、あっさり1日で終わってしまった。明日はこのモデルの検証と、出来ればExcelの仕様書からDDLを生成するマクロでも作りますかね。せっかくVBA覚えたし*1。

@ [linux] yum search遅すぎ

http://www.globe.to/~oka326/?Fedoraでは

その一方で、yumはaptより遅いという指摘もある。実際、aptはC++で開発されており非常に高速化されているのに対して、yumはPythonで実装されているため速度的に限界がある。

とありますが、本当にそれだけなのかな？primary.xml.gzのパース(?)に時間がかかっているだけのような気がします(aptはXMLなんか使ってない)。

@ [pc] そろそろサーバリプレイス

この日記があるサーバは購入してから3年も経っているのと、CPUが(無駄に)Pen4なので、消費電力を抑える関係からそろそろ新しいマシンにしようかと思ってます。

予算7万円以内で、大体の構成を考えたらこんな感じになりました。

• ベース: AOpen XC Cube EX761 \29,800
• CPU: Turion64 ML-30 \19,000ぐらい
• MEM: 512MB \4,000ぐらい
• HDD: Seagateで250GBぐらい \12,000ぐらい

CPUは価格重視でSempronにするかもしれないですが、省電力なTurionが非常に気になります。キューブ型だとどうしても熱が籠りがちになるので、なるべく発熱量は抑えたい。AOpenのベアボーンは形はかっこ悪いですが、価格面ではとてもいい感じ。

@ セッションにmemcachedを使うかどうか

• なぜmemcachedをセッション管理用に使うのか
• Why storing session on memcached?

なんか僕のエントリが元になり軽く議論になっているようですが...

個人的にはmiyagawaさんのVox/LJの方針に賛成で、「消えては困るデータ」はプライマリーのストレージとしてmemcachedを使うのではなく、MySQLに入れる方が安全だと思います*1

MySQL 使ってると、セッションデータを定期的に消してやらなきゃいけないけど DELETE FROM sessions WHERE timestamp >= '2006-12-01 00:00:00'; とかはすごく重かったりして、ここでまた刺さる

というのは、InnoDB+timestampカラムにインデックス張れば解決するのではないかと思いますが、そんな単純な話ではないのでしょうか？

ちなみにmiyagawaさんのいう

データベースに書き込む際に memcached に同時に書き込み、読み込み時には memcached -> データベースと fallback する (= Write-through Cache)

を実現するためにCGI::Session::Driver::aggregator作りました。

ただ、基本的にセッションって確認画面を挟むようなデータ登録画面で使うものだと思いますが、こういうケースだと

1. 入力画面
2. 確認画面 (セッションデータ書き込み)
3. 完了画面 (セッションデータ読み込み)

という感じでReadとWriteが同じ回数なので、Writeで2箇所のストレージに書き込む分 Write-through Cache でもあんま速度的なメリットはないのではないかと思います。ログイン状態を管理するセッションだったらReadが多い分有用だとは思いますが...

とまあ、こんなに色々理由があるんで、並列でもない、サーバが複数でもないベンチマークだけで採用の是非を判断するのは違うかな

これは本当その通りで、もともと質問してきた外人さんも「実際のアプリケーションの世界では(僕がやったベンチとは)また違った結果が出るだろうねぇ」と言っていたし、「これはあくまで一つの観点からの計測でしかない」とは言ってあるので、あのベンチの結果を鵜呑みにはしないと思います*2。セッション管理も用途や状況に応じてストレージ選べないと、ってことで。