ubuntu に kumofs を導入して動かしてみた

先日えとらぼより公開された、kumofs を自宅マシンの ubuntu に導入して、動くところまでを確認してみた。Key-Valueストアを利用する機会を作ろうと考えている手前、実際のところちゃんと利用したことがなかったので、まずは基本部分から。ドキュメント通りの導入ステップと、簡単なアクセスによる利用テストのみ。

なお kumofs のアーキテクチャについてはこちらで紹介されている。

今回導入した環境は以下のとおり。

• OS: Ubuntu 9.10 (KVM)

必要パッケージの導入

コンパイルや動作のために必要となるパッケージを導入。

$ sudo apt-get install libtokyocabinet-dev
$ sudo apt-get install ruby rubygems
$ sudo apt-get install g++

MessagePack for C/C++ の導入

MessagePack の C/C++ はパッケージがないので自前でソースから導入する。この時点でのバージョンは 0.4.2。

$ wget "http://dl.sourceforge.jp/msgpack/46155/msgpack-0.4.2.tar.gz"
$ tar xzf msgpack-0.4.2.tar.gz
$ cd msgpack-0.4.2/
$ ./configure
$ make
$ sudo make install

MessagePack for Ruby の導入

一方 MessagePack for Ruby は gem で導入。

$ sudo gem install msgpack

kumofs のコンパイル

いよいよ kumofs のコンパイル。この時点でのバージョンは 0.3.1。特別やることはなかった。

$ http://github.com/downloads/etolabo/kumofs/kumofs-0.3.1.tar.gz
$ tar xzf kumofs-0.3.1.tar.gz
$ cd kumofs-0.3.1/
$ ./configure
$ make
$ sudo make install

kumofs を動かす

アーキテクチャの紹介でもともかく分散構成が基本であることを前面に出しているし、それを実現するための方法もとても簡単なのがすばらしい。でも単一のサーバ上で構築してもなんら問題なく動く。

まずはマネージャを起動。

$ sudo kumo-manager -v -l localhost &

続いてサーバを起動。

$ sudo kumo-server -v -l localhost -m localhost -s /var/kumodb.tch &

管理ツールで状態を確認してみる。VM 稼働かどうかは定かではないけども、なんか時間がおかしい。

$ kumoctl localhost status
hash space timestamp:
Thu Jan 01 09:00:00 +0900 1970 clock 0
attached node:
not attached node:
127.0.0.1:19800

マネージャにサーバを登録。

$ kumoctl localhost attach
$ kumoctl localhost status
hash space timestamp:
Tue Mar 02 23:38:08 +0900 2010 clock 124
attached node:
127.0.0.1:19800  (active)
not attached node:

なぜか時間も正常に表示されるようになったぞ。

最後に、ゲートウェイを起動。アプリケーションはこのゲートウェイに対して通信する。

$ sudo kumo-gateway -v -m localhost -t 11211 &

使ってみる。直接つっついてみるケースと、プログラムからのアクセスの両方をやってみた。

$ telnet localhost 11211
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
set foo 0 0 5
12345
STORED
get foo
VALUE foo 0 5
12345
END

$ sudo gem install memcache-client
$ sudo gem install system_timer
$ irb

require 'rubygems'
require 'memcache'

kumofs = MemCache::new 'localhost:11211'

kumofs.set 'foo', 123
kumofs.get 'foo'

=> 123

さあいこう！

http://coderepos.org/share/browser/events/phpframework/piece_framework/trunk

機能をすべて実装したものの、まだまだチューニングや見えざる敵（bug）との戦いが控えています。
俺たちの戦いはこれからだ！



r15761 号をもってコミットメントは終了です。
ご愛読ありがとうございました。

PHP Simple HTML DOM Parser

PHP Simple HTML DOM Parser

これ面白い。

require_once 'html_dom_parser.php';

$dom = file_get_dom('http://www.google.co.jp/search?q=%E3%83%94%E3%82%AB%E3%83%81%E3%83%A5%E3%82%A6&lr=lang_ja&ie=utf-8&oe=utf-8');

foreach ($dom->find('a') as $node) {
    $node->innertext = str_replace('ピカチュウ', 'オプーナ', $node->innertext);
    $node->href = 'http://www.opoona.com/index.htm';
}

foreach ($dom->find('b') as $node) {
    $node->innertext = str_replace('ピカチュウ', 'オプーナ', $node->innertext);
}

print $dom->save();

なんか色々思いついたので、暫らくの間これで遊びます。

室内整頓中

ごちゃーっとしていることに嫌気が差した2008年、思い立って自宅室内にところ狭しと並べられていた家電、パソコン類を整頓することにしました。

手始めに、既に使っていないくせに何故か部屋の中に留まり続けていた小型のブラウン管TVや CRT ディスプレイを処分。
驚くべきことに4台にもなっていた自作パソコンも、機能面や用途面を含めてえいやと一台に集約して残りを排除。
うちに遊びにきた人は必ず反応していた3面もの液晶ディスプレイも、ワイド24型を1つだけを残して残りは排除。
テレビに接続されていた各種プレイヤも、HDDレコーダ１つを残して残りは排除。


と、ここまで一気に進めて室内スッキリし始めたところで、PC からアナログ線で繋いで利用していた古いステレオアンプ＋スピーカーx2が何故か気に入らなくなり、デスクトップPC向けのエレガントな2.1chサラウンドシステムを IYH!（イヤッッホォォォオオォオウ！の意ですなわち衝動買い）。調整も済んでいい音を楽しんでますが、思い切りやってしまった感が。

家電はこんなところで、後日は本類に着手する予定。

Piece_ORM で簡単データベース＋PHPプログラム

Piece_ORM を使えば、だれでも簡単にデータベースを使ったPHPプログラムを書くことができます。（任天堂のCM風に。）

1. フォルダの作成

Piece_ORM を動作させるには、プログラムのファイルとは別に3つのフォルダを使います。
プログラムファイルを作成するフォルダ内に、次の3つのフォルダを作成します。

• config
• cache
• mappers

2. データベース情報を準備する

次に Piece_ORM から接続するデータベースサーバの情報を設定します。
仮にデータベースの情報が

データベース: PostgreSQL
ホスト名: localhost

database : example
username : example_user
password : example_password

以上のようなものなら、先ほど作ったフォルダのうちの１つ、config フォルダの中に「piece-orm-config.yaml」という名前のファイルを作成し、次のように記述します。

- name: database1
  dsn: pgsql://example_user:example_password@localhost/example

3. テーブルを準備する

続いて、実際にプログラムから読み込みや書き込みを行おうとするテーブルを準備します。

データベース内の実際のテーブルは予め作成しておきます。ここでは「person」という名前のテーブルを作成したとします。

先ほど作ったフォルダのうちの１つ、mapper フォルダの中に「Person.yaml」という名前のファイルを作成します。中身は何も必要ありません。


4. プログラムを書く

最後にプログラムを書きます。書くプログラムは非常に短くて簡単です。

SELECT 文の SQL は次のようなコードを準備します。SELECT した結果のレコードがオブジェクトとして簡単に参照が可能です。

<?php

// Piece_ORM を読み込む
require_once 'Piece/ORM.php';

// Piece_ORM を設定する
Piece_ORM::configure('config', 'cache', 'mappers');

// person テーブルを対象にする
$mapper = Piece_ORM::getMapper('Person');

// select * from peron where id = 1;
$person1 = $mapper->findById(1);
echo $person1->name;    // name カラムを表示

// select * from peron where name = 'foo';
$person2 = $mapper->findByName('foo');
echo $person2->name;

INSERT, UPDATE, DELETE も簡単です。

<?php

// Piece_ORM を読み込みと設定
require_once 'Piece/ORM.php';
Piece_ORM::configure('config', 'cache', 'mappers');

// person テーブルを対象にする
$mapper = Piece_ORM::getMapper('Person');

// 新しいレコードとして INSERT
$person = new stdClass();
$person->name = 'foo';
$mapper->insert($person);

// name カラムを変更して UPDATE
$person->name = 'bar';
$mapper->update($person);

// DELETE
$mapper->delete($person);

詳しくはこちら

Piece_ORM のインストール
Piece_ORM のより詳細なチュートリアル

iTunes ライブラリのデータ共有＆バックアップ環境の最も簡潔な方法

音楽や動画などのデータを保存しているストレージ用のマシンとHDDがヘタれたので、ひとまず新しいHDDを買ってきたんですよ。この手のPCパーツを買うのは2年ぶりほどですけど、相変わらず暫らく遠ざかっているだけで性能アップと価格ダウンの進展が大きくて驚くばかりですよ。HITACHI の省電力仕様のHDD 500GB が 9000円でした。

で、タイトルにあるように iTunes ライブラリ（音楽データ、アートワーク、楽曲再生リスト）を新しい HDD に移しつつ、既存の再生環境でも正しく再生されるようにしないといけないなあと思ったんですね。気をつけないと「データが見つかりません」とか言われてデッドリンクが大量発生しちゃうし。
そこで、ふと気づいたんですよ。なんで今までこの方法が思いつかなかったんだろうと。google で調べても同じことやってるケースが一杯ヒットしているくらいだし。

iTunes ライブラリ用って１つのフォルダにまとめられているんで、そこをシンボリックリンクにすれば、参照先がどこに移動したって再生環境側は気にする必要がないんですよね。仮に再生側で再インストールしたとしても、ストレージ側の iTunes ライブラリをシンボリックリンクしなおせばすぐ元通りだし、今回のようにストレージ側が変わっても、これまた同じようにシンボリックリンクしなおせばすぐ参照できるようになる。

まずは現行の再生側の iTunes ライブラリフォルダをバックアップなどに移して、iTunes から認識できるライブラリフォルダが存在しないようにしときます。Windows ならば「マイミュージック」内に iTunes がない状態に。一方、実際の iTunes ライブラリフォルダがどこか別のところにある状態にします。ここでは仮に d:\music\iTunes あたりとします。

Windows 環境では通常シンボリックリンクをはる手段がないものの、MS の TechNet でシンボリックリンクを作る junction コマンドのプログラムが配布されているようなのでコレを使うとOK。windows フォルダや system32 フォルダあたりの実行パスが通っているところにコピーしたあと、コマンドプロンプトを立ち上げて以下のように junction コマンドを発行してあげればOK。

c:\Documnets and Setting\username> cd "My Documnets\My Music"
c:\Documnets and Setting\username\My Documnets\My Music > junction iTunes d:\music\iTunes

ちなみに Cygwin 環境があれば ln コマンドで同じことができます。

これで、見かけ上はマイミュージックに iTunes フォルダがあるように見えるものの、実際その中身は d:\music\iTunes という状況に。

再生側は全般的に c:\Documnets and Setting\username\My Documnets\My Music\iTunes として見えているので、これのシンボリックリンク先がネットワーク越しの異なるマシンなんてこともOKでしょう。複数マシンが1つの iTunes ライブラリを参照する状態になるので、どのマシンでもライブラリへの楽曲追加ができるし、共通の再生リストも利用できますね。

Movable TypeにおいてSQLiteからMySQLへ手動でデータ移行する

うちの Blog で利用している Movable Type は SQLite でデータ保存を行っていたのですが、どうもその SQLite データファイルが、利用しているホスティングであるさくらサーバの容量に対して到底無視できない割合（1/4）を利用しているということが判明。事実、容量の空きが非常に苦しいものとなってきていました。
その一方、さくらでは別途 MySQL も用意されており、ユーザは www 用サーバとは別に準備されたいくつかの MySQL サーバのうちの1つを選択し利用できるというサービス体系になっています。

そんな利用状況なさくらサービス、ひょっとすると使用可能なホスティングデータ量ってば、利用可能なサーバ容量の範囲とは別でないかという甘い考えが思いついたことはさておき、そもそも SQLite よりも MySQL サーバを利用するほうが保持するデータ容量は少なくなるであろうという考えの元、SQLite から MySQL へデータ移行することにしました。

その際、当方の SQLite におけるデータ構造や SQL 内容の理解がないので、1つ1つ確認しながら出来るよう、大よそを手動で事を進めていきました。今回のケースは Movable Type におけるお話ですが、他のものにもある程度流用できるのではないでしょうか。なおデータベース、および SQL についての若干ながらの知識が必要になるかもしれません。（SQL エラーが発生した場合に対応できるとか。）


0. 環境

参考までに、今回の環境は以下のとおり。
なお作業はオーソドックスにすべて CLI ベースのクライアントで進めました。

• MySQL 4.0.27
• SQLite 3.3.17
• Movable Type 4.0

1. Movable Typeのデータスキーマを MySQL 側に作成

まず MySQL 上に Movable Type のデータが格納できるよう、スキーマを作成します。
MT の設定ファイル（mt-config.cgi）内に記述されたデータベース接続設定を SQLite から MySQL のものへ変更し保存します。MT はかつて SQLite 環境で動いていたもので問題ありません。むしろこのまま MySQL へ移行しようとするので、へたに新しい MT の管理ページを作成する必要はありません。

続けて MT の管理ページへアクセスします。すると MT は MySQL 上に MT 用データが存在しないため、新規作成を行おうとしますので、これを進めていきます。MTユーザ登録などもあわせて行う流れとなりますが、内容を覚えておく必要はありません。

作成が完了した後、MySQL クライアントを使って、MT 用テーブルのデータを全て消去します。MT 用テーブルは、テーブル名の先頭すべてに「mt_」という接頭辞がついているものです。
テーブルの削除ではなく、データの削除であることに注意しましょう。データ削除コマンドは「truncate テーブル名」です。またその他のテーブルデータも消えぬことのないように…。

これで MySQL 側の受け口ができました。


2. SQLite のデータダンプ

続いて SQLite データをダンプします。

SQLite データは1つのファイルにまとめられている状態となっています。sqlite のコマンドツールはこのデータファイルを指定して実行する仕組みとなっています。またデータダンプは、sqlite の「.dump」コマンドで行います。たとえば SQLite データファイル example.db に対してのデータダンプは、CLI より以下のように実行します。

$ echo '.dump' | sqlite example.db > sqlite.dump.sql

SQLite データファイルの指定、および sqlite コマンドの違いに気をつけましょう。（さくらの場合、「sqlite3」コマンドでした。）

このコマンドの実行で、sqlite.dump.sql というテキストベースの SQL データが出来ました。


3. SQL データを MySQL 向けに編集

SQLite のダンプデータは、SQL 文によるデータベースの情報や操作が記載されています。
SQL は色々なデータベースで利用されているものですが、今回ダンプした直後の内容では一部 MySQL で利用できないものが含まれているので、これを編集します。

• 一行目の「BEGIN TRANSACTION;」を削除
• 最終行の「COMMIT;」を削除
• その直前の「CREATE INDEX～」行をすべて削除

まず以上のことを行うことで、データ内は「CREATE TABLE～」と「INSERT INTO～」のみのものとなります。

本来ならば、ここから「CREATE TABLE～」のSQLもすべて削除し「INSERT INTO～」のみにすることで MySQL への投入準備が整うのですが、私の場合はここから「INSERT INTO～」文を編集する必要がありました。このままデータを INSERT してしまうと、MySQL 上では目的のデータ構造とは異なるものになろうとしていたからです。

例えば、ダンプデータ内の CREATE TABLE 文が

CREATE TABLE mt_placement (
  placement_id integer not null primary key,
  placement_blog_id integer not null,
  placement_category_id integer not null,
  placement_entry_id integer not null,
  placement_is_primary boolean not null
);

というものに対し、実際のこのテーブルへの INSERT 文は

INSERT INTO "mt_placement" VALUES (4,2,2,4,1);

となっていたとします。データベースに対して CREATE TABLE を行った後にこの INSERT を実行すると、以下のようなレコードができます。

mt_placement テーブル
---------------------
placement_id = 4
placement_blog_id = 2
placement_category_id = 2
placement_entry_id = 4
placement_is_primary = 1

一方、既に MySQL 上で準備されている mt_placement テーブルは、先ほどの CREATE TABLE のものと同じとは限りません。同じテーブル内容なものの、カラム順が異なるケースが実際にありました。（以下は一例）

CREATE TABLE mt_placement (
  placement_id int(11) not null auto_increment,
  placement_entry_id int(11) not null,
  placement_blog_id int(11) not null,
  placement_category_id int(11) not null,
  placement_is_primary tinyint(4) not null,
  PRIMARY KEY(id)
)
type = MYISAM;

この場合、同じ INSERT 文を行った mt_placement テーブルはこうなります。

mt_placement テーブル
---------------------
placement_id = 4
placement_entry_id = 2
placement_blog_id = 2
placement_category_id = 4
placement_is_primary = 1

カラム名を指定した INSERT 文ではないため、テーブル定義を行った順に INSERT が行われてしまい、結果違うレコードに仕上がってしまいます。

これを回避すべく、ダンプデータ内に記述されている CREATE TABLE 文のカラム順序どおりに、INSERT 文を編集していくのです。（説明長い！）


先ほどの、

INSERT INTO "mt_placement" VALUES (4,2,2,4,1);

これは、こうします。

INSERT INTO mt_placement
(placement_id, placement_blog_id, placement_category_id, placement_entry_id, placement_is_primary)
VALUES (4,2,2,4,1);

ついでにテーブル名のダブルクオートも排除。なお複数行でなくても一行でOK。

全ての INSERT 文において、対応するテーブルの CREATE TABLE 文で示されているカラム順に従った形で INSERT 文を書き換えていきます。

INSERT 文のすべてを書き換え終わった後に、CREATE TABLE 文をすべて削除します。
　


4. MySQL へデータを投入

編集後のファイルを MySQL へ投入します。
例えば MySQL のデータベース「my_database」に対して投入する状況において、3. のセクションで sqlite.dump.sql ファイルを編集後 mysql.import.sql として保存したのであれば、以下のようなコマンドを実行します。

$ mysql my_database < mysql.import.sql

必要に応じて -u, -p などのオプションをつけて、SQL が正しく実行できるようにしましょう。 またエラーが発生した場合は原因を良く確かめて import ファイルを編集し、truncate でもう一度リセットした上で再投入しましょう。 5. Movable Type 管理へアクセス
投入後再び Web で MT 管理ページへアクセスします。SQLite 環境で稼動していたものと同じものが参照、利用できるはずです。