小野マトペの業務日誌(アニメ制作してない篇)

■[Programming][日記] MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLのDATETIME型は本当に遅いのか検証してみた 06:00

バグの話

近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。

バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。

以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。

select date from STATUS force index(date) where date='2010-01-19' limit 10;

この現象は、5.5.3,5.5.4での現象としてバグ報告がなされ、すでにパッチ待ちになっていた。

MySQL Bugs: #52849: datetime index not work

MySQL Bugs: #53149: MySQL doesn’t use indexes on date column properly because of collation

よって5.5.5がリリースされれば解消されているのだけど、バグ報告中で報告されていた回避方法を紹介。

• 文字列をBINARYにキャストする
  • 本事象は、文字列がlaten1かbinary以外の文字コードとして処理された時に起こるらしいので、文字列にbinary属性を与え、キャストしてやる。
  • ex) select date from STATUS force index(date) where date= binary '2010-01-19' limit 10;
• 整数形式で結合する
  • 文字列ではなく整数形式で値を与えてやる。こっちの方がすっきりしてるけど、ライブラリのプレースホルダで値を設定するときはデータ型に注意が必要そうだなー。
  • ex) select date from STATUS force index(date) where date= 20100119 limit 10;

あとDATETIME型が遅いって本当？

INT型の方がデータ取得の処理スピードが150倍高速の圧倒的効果である。INT型はINDEXを最適に使い目的の結果を返してくれるためここまでのパフォーマンス結果がでたものと思われる。面白い副産物結果として、DATETIME型ではINDEX有り・無しかかわらず処理結果値が同じということで、DATETIME型はINDEXの恩恵を受ける事があまりできないのである

http://blog.fukaoi.org/2009/03/19/mysql_datetime

MySQLでDATETIME型のデータを高速に検索する方法 | 深追い Fukaoi.org

以前、時刻の保存形式としてDATETIME型は低速でイケていない、unix_timestamp()関数で値を設定したINT型で保存すべき、というを話を上の記事で読み、なるほどそうしておこうかなと漠然と思っていたのだけど、ちょうどいい機会なので、MySQL5.5でも通じるTipsなのか検証してみました。ちなみに、MySQLのバイブル実践ハイパフォーマンスMySQL 第2版にはこうある。

3.1 最適なデータ型の選択

• 通常は小さい方がよい

一般に、データの格納と表現を正しく行えるデータ型のうち、最も小さいものを使用するように心がける。データ型が小さいほどディスク、メモリ、CPUキャッシュで使用する領域が少なくなるため、通常はその方が高速である。また、処理に必要なCPUサイクルも通常は少なくなる。(略)

• 単純なものがよい

(略)たとえば、文字セットとその照合順序(並び替えルール)は文字の比較を複雑にしているため、文字よりも整数を比較するほうがコストがかからない。ここに例が２つある。日付と時刻は文字列ではなくMySQLの組み込み型として格納すべきであり、IPアドレスには整数型を使用すべきである。

(強調は引用者)

DATETIMEないしTIMESTAMPを推奨されました。じゃあ、日付表現のための最も小さくて単純なデータ型ってなんでしょう。DATETIME型とTIMESTAMP型の解説は以下のようになってます。

3.1.4 日付と時刻型

DATETIME

　1001-9999年までの値を格納する事ができ、精度は1秒である。タイムゾーンとは無関係に、日付と時刻をYYYYMMDDHHMMSS形式で整数にパックする。これには8バイトの記憶域が使用される。(略)

TIMESTAMP

　1970年1月1日午前0時(グリニッジ標準時)からの経過時間を秒数で格納する。つまり、UNIXのタイムスタンプと同じである。記憶域を4バイトしか使用しない(略)

はい、DATETIMEもTIMESTAMPも、形式が違うだけでどちらも整数で管理されているんですね。ここら辺は公式ドキュメントに詳しいです。unix_timestamp()したINT型とTIMESTAMPはデータの格納方式として等価と考えていいということでしょうか。

特殊な振る舞いはともかく、TIMESTAMPはDATETIMEよりもストレージ効率がよいため、TIMESTAMPを使用できる場合一般にそれを使用すべきである。UNIXのタイムスタンプを整数値として格納することもあるが、通常はそうしたところで何の特もない。その形式は何かと扱いにくいので、お勧めしない。

(強調は引用者)

うーん、INTのTipsをフルボッコです。でも実際のところはどうなのでしょう。計測してみました。

計測条件

• 比較対象はcreated_at (DATETIME型)と、created_at_timestamp (TIMESTAMP型)と、created_at_int(INT型)。
• インデックスを使用したクエリ、使用しないクエリで、Range結合をテストする
• テストデータは2000万行
• データベースエンジンはInnoDB
• クエリキャッシュを無効にし、同一クエリを何度か実行し代表的な値を採用した
• 利用テーブルは以下

CREATE TABLE `STATUS` (
  `id` bigint(20) NOT NULL DEFAULT '0',
  `user_id` int(11) NOT NULL,
  `created_at` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `date` date NOT NULL DEFAULT '0000-00-00',
  `text` varchar(256) NOT NULL DEFAULT '',
  `point` int(11) NOT NULL DEFAULT '0',
  `created_at_timestamp` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `created_at_int` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `c_` (`created_at`),
  KEY `ct_` (`created_at_timestamp`),
  KEY `ci_` (`created_at_int`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

スペック

OS ：CentOS release 5.3

DB ：MySQL5.5.3

CPU： AMD Phenom(tm) 9350e Quad-Core

Mem：8GByte

インデックス無し

DATETIME型

mysql> select SQL_NO_CACHE * FROM STATUS ignore index(c_) where 20090701000000 <= created_at and created_at < 20090701235959 limit 1;
1 row in set (5.92 sec)

TIMESTAMP型

select SQL_NO_CACHE * FROM STATUS ignore index(ct_) where 20090701000000 <= created_at_timestamp and created_at_timestamp < 20090701235959 limit 1;
1 row in set (8.40 sec)

INT型

mysql> select SQL_NO_CACHE * FROM STATUS ignore index(ci_) where unix_timestamp(20090701000000) <= created_at_int and created_at_int < unix_timestamp(20090701235959) limit 1;
1 row in set (6.13 sec)

DATETIME型とINT型がほぼ同程度の速度で、TIMESTAMP型だけなぜか一周り遅いという結果に。えー、上でTIMESTAMP型とINT型はデータ長以外等価って言い切ったばかりなのに…。実際には等価ではなく、扱うロジックに差があるために速度差が出ているんでしょう。でもTIMESTAMP型よりもデータ長が長く格納方式の複雑そうなDATETIME型がTIMESTAMP型よりも速いっていうのが謎…。何故に…

インデックス有り

DATETIME型

mysql> select SQL_NO_CACHE * FROM STATUS where 20090701000000 <= created_at and created_at < 20090701235959 limit 1;
1 row in set (0.00 sec)

TIMESTAMP型

mysql> select SQL_NO_CACHE * FROM STATUS where 20090701000000 <= created_at_timestamp and created_at_timestamp < 20090701235959 limit 1;
1 row in set (0.00 sec)

INT型

mysql> select SQL_NO_CACHE * FROM STATUS where unix_timestamp(20090401000000) <= created_at_int and created_at_int < unix_timestamp(20090401235959) limit 1;
1 row in set (0.00 sec)

えーと、どのデータ型でもきちんとインデックスが適用されていて、データ型の差異が計測出来ない程度に高速ですね。2000万行でこの速度ならどれ使ってもパフォーマンス上全く問題ないといえるでしょう。インデックス無しでは速度に差がありますが、どっちみちインデックス無しではどんなデータ型だろうと実用的なクエリ実行は行えません。これなら実践ハイパフォーマンスMySQLの教えに従って組み込みの時間型を使ってもなにも大丈夫そうです。自前のINT型、必要なし！

しかし深追いさんのベンチマークとの差はどこから来たんでしょう…。MySQL5.0.67から 5.5.3へのアップデートのどこかでDATETIMEが改良されたのでしょうか。ただ、深追いさんのベンチマークは、そもそもDATETIMEに対してインデックスが効いている気配がないので、今回僕がハマったようなバグかCardinalityの破損であのような結果になったのではないかという気も少ししています。自分の環境では以前の5.0.67でもDATETIMEのインデックスは効いていたような気がするので…。ちなみに今回のテストはInnoDBで行いましたが、MyISAMテーブルでもdatetimeインデックスは適用されました。

まとめ

時間のデータは素直にDATETIME型かTIMESTAMP型を使おう！*1

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

• 作者: Baron Schwartz,Peter Zaitsev,Vadim Tkachenko,Jeremy D. Zawodny,Arjen Lentz,Derek J. Balling,伊藤直也(監訳),田中慎司(監訳),吉川英興(監訳),株式会社クイープ
• 出版社/メーカー: オライリージャパン
• 発売日: 2009/12/14
• メディア: 大型本
• 購入: 14人 クリック: 213回
• この商品を含むブログ (44件) を見る

■[日記]iPadで絵を描いてきた！ 01:58

金曜日、@umezoが「iPadを触らせてもらいに行くけど誰か来る？」って行ってたので、ホイホイとiQONのVASILYさんまでお邪魔してきました。

SketchBook Pro

iPadいじらせてもらった諸処の感想は後述。どうしても試してみたくて@kyunsさんに頼んで有料のドローイングアプリを試させてもらった。AutodeskのSketchBook Proというアプリ。

このアプリが素晴らしく、しばらくお絵描きに没頭してしまった。この様子は複数のソースでUstream/YouTubeしていたので、観てもらえばどんな様子か分かると思う。

@pen2さん撮影(ust)。50分くらいあるけど、描き始めてからTwitterにアップするまでの完全収録。ニコニコ動画に上げてみた。ダイジェストだけ編集したんだけど、音声が消えてしまう現象が起きたのでUstreamアーカイブそのままをアップした。

@kyunsさんビュー(ust)

http://www.ustream.tv/recorded/6063992

別角度から、@wady撮影

完成品。いい絵かどうかはともかく。

観てもらえれば分かると思うけど、SketchBook Proがかなり本格的に作り込まれているため、「細部を書き込むときは拡大しないといけない」という点にさえ気をつければまずまず実用的に描ける。俺程度のテキトーな描き手には十分応えてくれる感じだった。鉛筆には及ばないけど、マウスやペンタブよりずっといい感じ。

液タブとの比較

まさにこれは液晶タブレットだよなーと思った。感圧に対応していないのと、指で描いているために精密な描画ができないという欠点があるけど、前者は今後の技術とTipsでカバー、後者はiPhone用スタイラスを使うという手http://www.youtube.com/watch?v=jYSRQDxeGZYを使えば解消しそう(iPhoneでは太い専用スタイラスは使い物にならなかったけど、iPadの大画面なら使える)。

逆に、液タブ製品よりもよいなと感じたのは、以下の点

• どこでも使える
  • 液タブをカバンにいれて持ち歩ける人はいないけど、iPadなら持ち歩いて、サッと取り出せる。
• わいわい描ける
  • 178°まで奇麗に見える液晶で、その場にいるみんなが絵を覗き込める。会話がうまれる。楽しい！
• ぐるぐるできる
  • iPadの背面はとてもいい感じのカーブを描いているので、意のままに紙を回転させる事ができる。
• 個人的に、書き味が好み。
  • 液晶に限らないけどペンタブって、紙面がツルツルしてて個人的に苦手だった。線が走らなくてぐにゃぐにゃになっちゃったり。そういうのはiPadにはなかった。

感圧機能がないとはいえ、これでWacomの一番安い液晶タブレットの半額だから、液タブ欲しいけど買えなかったって言う人はiPadも考えてみるといいかもしれないよ！

Wacom Cintiq 21UX DTZ-2100D/G0

• 出版社/メーカー: ワコム
• 発売日: 2008/01/11
• メディア: Personal Computers
• 購入: 1人 クリック: 159回
• この商品を含むブログ (12件) を見る

落書き以外のiPadいじった感想

• HTML5によりNew York Timesのページ上で再生される動画クリップや、HTML5版YouTubeで涼しい顔して再生されるHD動画が美麗。液晶の品質がよく解像度も充分なので、立てかけて動画やスライドショー再生させてるだけでも絵になる。
• iPadで動くiPhoneアプリはClassic環境みたいなものだと思うべきで、iPad用にUIが作り直される必要がある
  • でもフルスクリーンなゲームはそのままでも全然いける。アクションゲームは臨場感を増し、タワーディフェンスゲーはボードゲームになる。

http://www.youtube.com/watch?v=w_qyZQcnr9A

http://www.youtube.com/watch?v=SPcGlJsCfII

• タイピングに関しては結構慣れが必要。でもiPad上で開発できるようになりたい。
  • TouchTermを使ってターミナルを使わせてもらった。vimを起動して何行か書いてみたけど、遅延が感じられない。iPhone上だとj,k押してからカーソルが動くまで1,2秒の遅延があるので、ちょっとしたパラメータの変更くらいしかできなかった。なのでiPadはCPU性能的には開発に充分と思われ。あとはSSHクライアントのUIがiPad最適化され、秋にマルチタスク対応すれば資料と行き来してコーディングできる環境が整う。

http://www.youtube.com/watch?v=hZ5N7la06XA

■[Programming]LVMスナップショットバックアップのためのシェルスクリプトを作った 23:47

今までmysqldumpを使ったデイリーバックアップを行っていたんですが、 いざ障害時に復旧しようとすると、SQLの実行のための時間がかかりすぎる、MERGEテーブルに対応していない(のでSQLをsedで書き換えるハメになった)等の理由から、LVMスナップショットバックアップに移行することにしました。

というわけでさっき

• /dev/ssdvg/lv01 を/var にマウントした環境において
• MySQLのデータディレクトリ /var/lib/mysql/favotter/ をLVMスナップショットバックアップする

というスクリプトを書きました。何かの参考にするために上げておきます。LV消したりとか危ない事を自動化しているので、これを使ったり参考にしたりした事によるいかなる損害も保障しません。また、このスクリプトを実行する前に、バックアップしたいVolumeGroup上に、スナップショット用の空き容量(今回は1GB)を作る必要があります。

やってること

1. MySQLをFLUSH TABLEする(書き込みバッファの内容をファイルに書き出す)
2. /dev/ssdvg VolumeGroupのlv01 Logical Volumeのスナップショットを /dev/ssdvg/lvSnapに1GBで作成
3. /var/lib/mysql/favotterを /バックアップ先ディレクトリ/＜日付＞-<DB名>にコピーする
4. /dev/ssdvg/lvSnap LVを削除する
5. コピーをtar.gz圧縮する。

#/usr/bin/sh
DATE=`date '+%Y-%m-%d-%a%H:%M:%S'`;
SRC_LV="/dev/ssdvg/lv01";
SNAP_LV="/dev/ssdvg/lvSnap";
SNAP_SIZE=1G;
DB_NAME="favotter";
DB_PATH="lib/mysql/$DB_NAME/";
DB_PASSWORD="<your db password>";

DEST_PATH="/home/matope/Documents/favotter/dbbackup/hotcopy/";
DEST_FULL=$DEST_PATH$DATE-$DB_NAME;

sudo mkdir /mnt/snap;
sudo /sbin/modprobe dm_snapshot;
sudo /sbin/lsmod | grep snapshot;

mysqladmin -u root -p$DB_PASSWORD flush-tables;
sudo /usr/sbin/lvcreate -s -L $SNAP_SIZE -n lvSnap $SRC_LV;
sudo mount $SNAP_LV /mnt/snap;
sudo cp -rpv /mnt/snap/$DB_PATH $DEST_FULL;
sudo umount /mnt/snap;
sudo /usr/sbin/lvremove $SNAP_LV --force;
sudo tar -cvzf $DEST_FULL.tar.gz $DEST_FULL;

この本を参考にしました。すごく実用的でおすすめです。ふぁぼったーもめきめき高可用性ゲットやでー

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

• 作者: 松信嘉範
• 出版社/メーカー: 翔泳社
• 発売日: 2009/09/17
• メディア: 単行本（ソフトカバー）
• 購入: 48人 クリック: 3,359回
• この商品を含むブログ (33件) を見る

■[ふぁぼったー]ふぁぼったー Version.4をリリースしました！：新機能概要 06:58

先週の土曜日からデータベース障害のためふぁぼったーが停止するという事態になりましたが、今朝障害復帰を果たすとともに、同時にふぁぼったー新バージョンへの移行を行いました。

新ふぁぼったー

機能詳細は以下

『Myふぁぼったー』機能(要ログイン)

TwitterのOAuth認証に対応し、ふぁぼったーにログインする事で、自分がフォローしているユーザーのふぁぼりやふぁぼられを読めるようになりました。ユーザー各人が趣味の合わないTweetに煩わされること無く、より興味のあるつぶやきを読みやすくなります。

listsへの対応(要ログイン)

2009年9月にTwitterに追加された「lists」機能に対応しました。ユーザーが購読しているListsのメンバーのふぁぼりやふぁぼられを表示出来ます。

@tsuda/media-contentリストの例(要ログイン)

http://favotter.net/list.php?user=tsuda&list=media-content

『ふぁぼったー検索』の強化 (一部要ログイン)

従来より提供している『ふぁぼったー検索』がさらに強化され、

• AND/OR/-検索
• 任意のfav数によるフィルタリング、
• RSSフィード

に対応しました。さらに、Myふぁぼったーと連携し、ログインしているユーザーのFollowingのふぁぼりやふぁぼられに絞り込んだ検索が可能になりました。(Following絞り込みのRSSフィードは未対応)

クロール範囲の拡大

従来、ふぁぼったーでは日本語ユーザー 3万9000人、英語ユーザー 6万8000人のFavoritesを収集していましたが、新クローラーの開発により、毎時間日本語ユーザー 10万人以上、英語ユーザー 30万人以上のクロールを実現しました。

その場でfav機能の強化

ふぁぼったーにログインしていれば、今までのようにパスワードダイアログが出る事無く、1クリックで確実にふぁぼることができるようになりました。

ドメイン移行

従前のサブドメインを改め、専用ドメインに移行しました。新URLは以下

日本語版 http://favotter.net/

英語版 http://en.favotter.net/

取り急ぎ機能概要まで。

■[ふぁぼったー]ふぁぼったーをBest Twitter Appに投票しよう！について 00:43

前回のエントリー以降、どうにかして海外の動向を知ろうと海外Twitter界隈についてアンテナを広げようと思っていたんだけど、Favstarさんがこんな事をつぶやいていた。

Enjoy favstar this week? Vote for Favstar.fm in the Open Web Awards as best twitter app. http://mashable.com/owa/votes/category/26?c=26 - Top 5 get acknowledged.

和訳：今週はfavstarを楽しんだ？ Open Web Awardsの Best TwitterアプリにFavstar.fmを投票してね！http://mashable.com/owa/votes/category/26?c=26 - トップ5が認められる

http://twitter.com/Favstar/status/5460494247

Open Web Award？なんぞ？

という訳で調べてみた。

Open Web Award

Open Web Awardとは、Mashableというソーシャルメディア情報サイト？が2年前から毎年開催している、要するにユーザー投票によるソーシャルメディアの賞らしい。で、このTwitter Best App部門では、その名の通りTwitter関連サービス／アプリ世界一を決める投票がおこなわれているっぽい。

で、Favstarさんがこれにノミネートしている！しかも結構票を集めている気がする*1！！これは負けてられない！ぼくもそれやりたい！！

本題

といったいきさつで、ふぁぼったーもOpen WebAwardsにノミネートしてみたいと思います。

つきましては、ふぁぼったートップに掲示したバナー

からOpen Web Awardsにジャンプし、

の画面からSubmit & Tweetでノミネート(推薦)をお願いします

ノミネートは一人につき一日一回までだそうです。このノミネート数ののべ数が多かったサービスが決選投票に進出します。

ええ、 blogランキングぽちっとしていってくださいね的な感じで押して頂ければ、是非に。

最後に、もうちょっと詳しくレギュレーションを説明しますね。

このアワードは、ノミネート(推薦)期間と、投票期間に別れており、前述の通り、推薦期間内に上位5番目までの推薦を集めたサービスが決戦投票に進出する。

• 推薦期間 - 10月14日-11月15日(EST)
• 投票期間 - 11月18日-12月13日(EST)
• 結果発表 - 12月15日(EST)

推薦期間もう残り5日しかないので、実は既に絶望的な状態なのだけど、まあやらないよりはいいだろう、とりあえずやってみようというのが今回の趣旨です。以上、ご協力よろしくお願いします！！

■なぜふぁぼったーは英語圏で負けたのか 01:00

前口上

今年の7月にリリースされてから、早々に公式サイドバー広告入りするなど英語圏で圧倒的な人気を集めるfavstar.fm。ふぁぼったーは2008年の1月から英語版サービスを展開していたにもかかわらず、なぜ英語圏の制空権を得られなかったのか。たまたま見つけた海外のふぁぼったーユーザーに Twitterで直接インタビューしてみた。

インタビューに答えてくれたのはjoshsharpさん、メルボルンのWeb開発者らしい。

Togetter(トゥギャッター) - まとめ「なぜふぁぼったーは英語圏で負けたのか(インタビュー原文)」

やりとりはとぅぎゃったーにまとめたので、簡単な和訳を記します。

インタビュー

―― こんにちは、私はふぁぼったーの開発者です。海外の方の意見が知りたいので、ふぁぼったーとFavstarについて質問していいですか？

joshsharp: いいですよ、お役に立てれば。 :)

―― ありがとうございます！ ふぁぼったーは英語圏に向けたWebサービスとして、Favstarと比較して何が足りないと思いますか？ *1

joshsharp: 僕はふぁぼったーが大好きだよ。Favstarはほんの少し綺麗で、時々favを素早くクロールするけど、でもそれだけだね！僕はふぁぼったーの方が好き。

―― ありがとう！デザインとクロール速度は大切ですね。

サイトデザイン、というかより本質的にはフォントいじりについてどう思うか聞いてみた。あれは完全にテキストサイト文化なので、外国人に面白さが伝わるか疑問だったので。

―― 日本人として、僕はふぁぼったーのフォント表現をポップだと感じるんですけど、あなたはどう思いますか？フォントをモノクロに直すべきかなと思ってるんだけど。

joshsharp: いや、フォントや色は既にグッドだよ。

―― ふむふむ。安心しました。

外人的にもフォントいじりはオッケーらしい。これは収穫。あまりダラダラ質問しても悪いので、再びストレートを投げてみた。

―― じゃあ、正直なところ、なぜFavstarはfavotterと違って英語圏でウケたと思いますか？

joshsharp: 正直、多分デフォルトの日本語テキストがちょっとだけユーザーをビビらせたと思う。あと、サブドメインじゃなくて専用のドメイン名を持つべき。それと、あなたがイングリッシュスピーカーで、既にその一部になっていないのであれば、巨大な'西洋の'サイトの間で人気を得るのは難しいね。それは理にかなっていて、自明な事だ。

もうなんか、これに尽きるというような意見が出てきた。英語のできないやつは世界のWebサービスで通用しませんよって当たり前か。当たり前なんだけど、動く現物があればなんとか分かってくれるだろうとタカをくくっていたようなところがある。甘かった。あれだ。悪しき日本人の「いいものを作れば売れる」幻想。

言語の壁は情報の壁である以上にユーザーにとって心理的な、いわば空気の壁でもあって、空気の壁を感じさせたらユーザーは敬遠する。相手の文化圏の空気が分からなくては、ユーザーに受け入れられる筈もないと感じた。ふぁぼったーは英語インターネットの空気が分からなかったのでfavstarに負けたんだ。

とはいえ、まあ空気なんてわかんないので、当面取りうる対策としては、「サイト上の英語をちゃんとする。日本語を完全に排除する」。その上で機能性を向上させれパブを強化すれば、まだ機はあると思う。

――なるほど、わかった。ふぁぼったーに最も足りないのは、1. ネイティブで自然な英語のサポート、2. ドメインというわけですね。

joshsharp: その通り。あと、多分宣伝してくれる誰か英語を話す人。

――ああ、宣伝は大切ですね。次バージョンのリリース時にはTechCrunchあたりの英語メディアにプレスリリースを送りたいと思ってます。

joshsharp: techcrunchはいいアイデアだね．

――OK、急なお願いなのに難しい質問に答えてくれてありがとう。とても参考にになりました、がんばります

joshsharp: いや、役に立てたようでよかったよ。

いや、本当にためになりました。英語の勉強しよう！！

■[Programming]ふぁぼったーの負荷分散の計画をあれこれ考えてみた。 02:22

今日一日調べたこととかまとめてみる。

問題点

• 次回リリースの新機能はDB select負荷がかなり掛かるはずである。
• 現状でもデータLOADによる負荷が10に達し、selectにスロークエリ、接続エラーが出ている。DBの負荷分散が急務である。

参考: Load Average

参考: Slow Query

• あと、STATUSテーブルが2GBに達しようとしているので、デフォルトのサイズ制限4GBが見えてきた。再定義できるけど。

垂直分割対応案

日本語版DBと英語版DBのデータベースとクローラを別ホストに格納する

• 現状、favotterとfavotter_enはほぼ同規模のDBとなっている。
• ただし、参照は圧倒的にfavotterが多い。
• favotter_enのクローラを止めたら、スロークエリが激減した事がある。
  • 参考: Twitter / 小野マトペ: まる一日英語版のクローラ止めてたらすげー負荷下がった ...
  • 参考: Twitter / 小野マトペ: スロークエリも激減してるんだけど… http://g ...
• クロール負荷とINSERT負荷はかなり減るだろう。論理的にも簡単。
• しかし参照負荷に差ががあるのが気がかり。

レプリケーションする

• Webが参照するスレーブDBから、クローラの実行負荷を分離する事が出来る。
• しかし、INSERT処理はマスタにもスレーブにも等しく走るので、このDBへの挿入負荷をスレーブDBから分離する事はできない。
• 問題はINSERT時のテーブルロックだと思われるので、クローラ負荷が分離したところで効果はやや疑問。

水平分割対応案

MERGEテーブルを利用する

• 複数のテーブルをマージするMERGEテーブルを利用する
• INSERTのロック範囲を狭められるので効果はありそう。
• 欠点
  • INSERT時の主キー同一性チェックがINSERT_METHODで指定した挿入テーブルに対してしか行われないので、挿入する対象テーブルはロジック側で完全に制御する必要がある。ぶっちゃけ面倒。
  • TritonnがMERGEテーブルに非対応。ふぁぼったー検索をMySQL以外で実装する必要がある。

パーティショニングを利用する

• MySQL5.1の新機能。一つのテーブルを複数のパーティションに分割する。
• MERGEテーブルと比べて、主キー同一性チェックの問題がないらしくてうれしい。より透過的？
• 欠点
  • そもそもMySQL5.1なので、今はTritonnが使えない。
  • Groonga(単品)に移行するか、Groonga MySQLストレージのリリースを待つしかない

結論

こうして考えると、水平分割はふぁぼったー検索がTritonnに依存している関係上、一筋縄ではいかない。

ふぁぼったー検索をTritonn以外の方法(例えばGroonga単体)で実装すれば、ふぁぼったーはTritonn(=MySQL5.0.45)の呪縛から解き放たれ、MySQL5.1にアップグレードしモダンなパーティショニングを使う事ができる(MERGEテーブルは使いたくない)。

しかし、ふぁぼったー検索は、通常の全文検索だけでなく

• 動的に増加するfav数によるフィルタリング
• ユーザーによるしぼりこみ
• ふぁぼりユーザー(fav_by)によるしぼりこみ
• ユーザーのprotect状態変更への追従
• 発言削除への追従

と、DBから分離して管理するには面倒な要件が盛りだくさんなので、片手間で独自実装するのは現実的とは思えない。つまり、Groonga MySQLストレージを待ちたい。

一方垂直分割に関しては、レプリケーションとDB分離、どちらがメリットがあるかすぐには分からないが、どちらも仕組みはとても簡単なので、どちらとも評価して決めればよい。総論として、ふぁぼったーDB負荷分散戦略としては、

「Groonga MySQLストレージエンジンを待望つつ、レプリケーションまたは日本・英語DBの分離を行う」

で決まりかと思われる。と結論が出たところで寝ます。おやすみなさい。