ぱぱネット（仮）

_ 三洋Xacti DMX-CG65

新型Xacti がちょっと欲しくなっている。ぶっちゃけ、 モノとしては以前から退化している部分もある。 HD(720p)撮影機能外して、ジャイロ手ぶれ補正とH.264対応を加えたという感じだから。

でも今回の三洋は一味違う。プロモーションをブログ関連に全面的に向けていて、 これが製品の印象をガラリと変えている。以前のXactiは「ハンディなんとか対抗」 という己を良く理解していない無謀なマーケティングの元、ムービー売り場に 置いてもらおうとして爆死していたわけだが...。 昔からネタ撮影はXactiが向いていると思ってたのよ。そもそも 子供の運動会とかは俺は撮影できないしな('A`)

ただ...CG65は最近デジカメでは当り前になりつつある広角撮影が苦手なので、 その点どーなのかなあと。

_ キヤノンPowerShotTX1

一見似たような商品に PowerShotTX1 がある。撮影スタイルはずいぶん違う。Xactiは動画撮影中に静止画が撮影できるが、 TX1はデジカメがメインで本当に一瞬だけ動画を撮影する、という感じで 設計されている(撮影時間が極端に短い想定)。

だって、動画形式が今どきMotionJPEGってどうなんだ？という。720pで撮影できるのは 評価できるけど、ビットレート高いから激安SDカードが使えそうもない、という 点が激しくマイナス。アップロードも再エンコ必須だから、カメラでとって カメラのD端子でテレビで再生という使い方がメインだろう。 動画に関しては 全体的な未完成度が指摘されとるね...。

_ というわけで

新しいデジカメが欲しいぞ。

_ クマ三郎＆るぅ嬢の新居

どうも、ここ最近クマさんの日記が更新されなかったのは、新居の引越し準備のため土日忙殺されてたかららしい（インターネットもない）。俺もそうだったからわかるけど、実家から最初の引越しは 何が足りないのかわからないので 、けっこう難航するんだよねえ・・・1度でも一人暮らし（二人暮しか？）してればいいんだが。

昨日の夜、 クマ：「調理器具選んで〜」 と呼ばれたのでいそいそと行ってきました。

という感じでしたが。まあ、たぶんクマさんの姑。舅じゃなくて。

_ 最初新居の近所で

買い揃えようと思ったんだが、金物屋と思っていたところが生活雑貨がほとんどなく園芸店と化していたりしたので難儀する。

仕方ないのでバスを乗り継いで某スーパーまでやってきた。全く関係ない話だが、横浜は港町じゃなくて住宅地の多くは山間部と呼んでいいと思う立地が多い・・・高低差がけっこうあるのよね。

さすがに大手スーパーの日用雑貨コーナーではモダンな小鍋や使いやすそうなフライパンなどがそろっており大満足。クマさんとるぅ嬢は二人でいろいろ選んでいるようです。いいねえ若いもんは・・・(´ー｀)y─┛~~

_ 夕食

一応

1. パセリ
2. バジル
3. ローレル
4. チューブにんにく
5. チューブしょうが
6. チューブわさび
7. とうがらしホール
8. 豆板醤
9. 甜面醤
10. ブラックペッパー
11. 鳥がらスープの素
12. マギーブイヨン
13. キッチンペーパー

を差し入れてあった俺。さらに、塩、こしょう、白ワイン、小麦粉などを買い足す。食材を残しておけない（平日はそれぞれ実家から通う）そうなので、クマさんの希望通り献立はパスタ中心にした。

• スズキのムニエル・バターソース
• 付け合せはじゃがいもとにんじん
• 生トマトとベーコンのパスタソース
• レタスとトマトのサラダ
• にんにく卵スープ

いかん・・・つい自分で調理してしまう。 クマさんにやらせなければ！ 教えるのに必死でけっこう調理時間がかかってしもうた。

まあ一応食えたので一安心。

_ 反省会

「フライパンの蓋がないのは罠だ！」「皿立てて乾かす奴なんてったっけ？」「調理にも使う皿が絶対的に足りない」「ごみ片付けたら移動式の台が欲しいね」といったところ。

_ [開発][Linux] 噂のTokyo Cabinet

mixiのアーキテクトである 平林幹雄さんの一連のソフト群は mikio ware と呼ばれ、筋(どの筋？)では有名です。 いろいろなものを作られているのですが、最近、富に注目を浴びているのは、 Tokyo Cabinet / Tokyo Tyrant と呼ばれる軽量データベース。

個人的にはSQLite3という、 組み込みリレーショナルデータベースを良く使っていたのだが、 いくつか問題にぶち当たっていて、これを解決する手段を探していたというわけ。

• 原則DBロックで2,3プロセスから書き込むと良く更新失敗する
• RDBMSなので割と真面目にテーブル設計しないといけない
• 登録が遅い！トランザクション使えば速いがそのロック期間は(1)の問題が生じる
• サーバ実装のデファクトがない
• レプリケーションがない
• パフォーマンスチューニングの余地が少ない

特に1番めの欠点を直そうとSQLite3を改造しようとして挫折した経験あり(笑) これができないとウチのような小規模Webページでも大変困ったことになるのです。

一方Tokyo Cabinetは、RDBMSではないのでテーブル同士のJOINなどはできないものの、

• mixiの更新時刻処理に使われていて毎秒数万アクセスをさばいている(らしい)
• ハッシュ、B+木、固定長、テーブルDBを選択でき、テーブルDBは非常に理解しやすい
• Tokyo Tyrantというサーバ実装がある
• レプリケーションがある
• ハッシュ表やリーフ(ノード)サイズが細かく制御でき、かつzlib/bzip2による圧縮もサポート

という素晴らしい特徴があります。なかなかいい感じではないですか。

_ [開発][Linux] テーブルデータベースの基本

TCの真骨頂は、カリカリにチューニングしたハッシュデータベース(PerlやRubyの連想配列のようなKey-Value-Storage)にあるらしいのですが、私はテーブルデータベースにしか興味がないのでこれを使ってみます。

テーブルデータベースは、名前の通り「表」です。

が、SQLのテーブルとはだいぶ異なります。なんとカラムは自由に増やせます。特定の行だけに カラム'type'があって、他の行にはない、なんて事も可能です。SQLだとALTERで増やして、 デフォルト値で埋めるなんて作業をしなければなりませんが....

どうもTTは基本的にハッシュデータベースであり、 primary keyだけは特別 扱い しているものの、残りのカラムはすべてセルデータに結合して記憶されているようですね。 セルに「7」という数値だけではなく「type:7」という形で記憶されるようです。 事前にテーブル設計をしなくても良いのはメリットである半面、「typ o 」みたいな 間違いをしてもTT側でチェックしてくれる訳ではないのでハマりそうですな(笑)

あと、これは面喰らったのですが、サーバ版のTokyoTyrantでは基本的に 1つの初期化スクリプト＝1データベース＝1テーブルのようです。1データベースに 複数のテーブルを格納することはできないようです。つまりTCPポートが別々に分かれた 複数のサーバを起動しておくという使い方になるようです（少なくとも標準では）。

起動にはttserverというサンプルファイルを/etc/init.dにpostepgみたいな テーブル名と同じファイル名にしてコピーして所定の変数を書き換えます。 以下の例はポート1993にpostepg.tctという名前のテーブルを作成する例です。

# configuration variables
prog="ttservctl"
cmd="ttserver"
basedir="/mnt/windex/postepg"
port="1993"
pidfile="$basedir/pid"
#logfile="$basedir/log"
#ulogdir="$basedir/ulog"
ulimsiz="256m"
#sid=2
#mhost=""
#mport="1993"
#rtsfile="$basedir/rts"
dbname="$basedir/postepg.tct#opts=l#apow=8#dfunit=2"
maxcon="1024"

chmod a+x postepgして/etc/init.d/postepgで起動します。

_ [開発][Linux] TokyoTyrantへのアクセス

Perl,Rubyなどのバインディングが存在しますが、私はPerlを使いました。

use TokyoTyrant;
my $pe = TokyoTyrant::RDBTBL->new();
die "ERROR: unable to connect" if (!$pe->open('localhost', 1993));
if ($pe->rnum == 0) {
    $pe->setindex($pec->{'eventid'}, $pe->ITDECIMAL);
    $pe->setindex($pec->{'nibble'}, $pe->ITTOKEN);
    $pe->setindex($pec->{'provider'}, $pe->ITLEXICAL);
    $pe->setindex($pec->{'title'}, $pe->ITQGRAM);
}
$pe->close();

ちょっとハマったのは データベースのタイプを合わせること ですか。hogehoge .tct をデプロイしている サーバにアクセスするためには、必ずTokyoTyrant::RDBTBLを使わねばなりません。 まあ少し考えればわかることですが...

登録数が0のときにインデックスを張っています。数値はITDECIMAL、文字列辞書式順はITLEXICAL、 「ニュース,報道」みたいなカンマや空白で区切られた複数の意味を持つ文字列はITTOKEN、 自由な単語で検索したい文字列にはITQGRAMを付与します。これで検索などが高速化されます。

データの登録はprimary keyを取得して、それに対してPerlのハッシュリファレンスをputします。

 my $cols = {
     'eventid'=>23435,
     'nibble'=>'2f 情報・ワイドショー その他',
     'provider'=>'NHK総合',
     'title'=>'おはよう日本'
 };
 my $rkey = $pe->genuid();
 $pe->put($rkey, $cols);

検索結果はprimary keyのリストで返ってくるので、それを使ってgetします。 Q-GRAMのインデックスを張っておくと、SQLite3のlikeなんて目じゃない柔軟な検索が可能になります。 ちなみにQCFTSANDは空白で区切られた単語単位のAND検索。Googleとまではいかないけど、 こんなお手軽に柔軟な検索ができるようになるのはTTのメリットでしょう。

my $qry = TokyoTyrant::RDBQRY->new($pe);
$qry->addcond('title', $qry->QCFTSAND, 'よう 本');
my @rlist = $qry->search();
foreach my $rkey (@rlist) {
    my $rcols = $pe->get($rkey);
    print $rcols->{'title'} . "\n";
}

基本はこれだけ。

_ [開発][Linux] ベンチマーク

ベンチマーク用にtcttestというコマンドが用意されているので、どのくらい速いか調べてみた。 インデックスは張りまくりの条件です。

tcttest write -tl -ip -is -in -it -if -ix ./test/test.tct

Q-GRAM転置インデックス生成を含む6種類のインデックスを張りながらでも、 250万レコード平均で4800レコード/秒というすさまじい速度です。 100万レコードから250万まで測定しましたが、微妙に時間が延びるもののほぼ線形。 ディスクの延びもほぼ線形でした。

最近はスケールアウトが流行りですが、これだけ速ければTC一つで事足りる事例も 多いのではないでしょうか。特に個人では.....

次は検索時間を調べてみたいと思います。