QDBMでもTCでも各種の圧縮アルゴリズムをDBに適用できるようにしているが、KCでも任意の圧縮アルゴリズムを後付けで組み込んで利用できるようになっている。その使い方と性能について紹介する。 圧縮アルゴリズムのプラグイン CacheDB、GrassDB、HashDB、TreeDB、DirDB、ForestDBのいずれも、tune_optionsおよびtune_compressorの2つのメソッドがある。tune_options(BasicDB::TCOMPRESS) とするとデータベースの圧縮が有効になり、デフォルトではZLIBの生フォーマットが適用されるようになる。任意の圧縮アルゴリズムを適用するには、さらにtune_compressorでCompressorクラスを継承して作った派生クラスのオブジェクトを登録する。Compressorクラスはcompressメソッドとdecompres

英辞郎から作った和英辞書にWordNetを組み合わせて、精度と再現率の双方を向上させたという話。 和英辞書の課題 日本人が英和辞書を引く時には、所望の単語の綴りがわかっていて調べる場合がほとんどなので、精度も再現率もほぼ100%である。言葉の定義や用法の説明の良し悪しが辞書の優劣を決めることになるだろう。一方で、和英辞書を引く時には、検索語としてどんな言葉を選べばよいか迷うことが多く、結果として不適切な言葉を引いてしまったり、所望の言葉が見つけられなかったりすることがある。つまり、和英辞書では精度や再現率が課題となり、それが辞書の使用感の優劣に大きく影響することになるということだ。 今回の開発のそもそもの発端は、英辞郎を転置して作ったEngHelperの辞書検索ツールで「叫ぶ」という言葉を前方一致検索した時に「scream」が出てこなかったことである。英辞郎における「scream」の訳語は

WordNetのデータを使って、Kindleで利用できるフリーの英和辞書を作ってみた。ここで言うフリーとは、無料かつ誰かに特別な許可をとることなく再配布したり改変したりできるということである。 ダウンロード 以下にデータを置いておく。これをUSB経由かネット経由でKindleに転送すれば辞書として利用できるようになる。 wordnet-ja.prc 背景 ここのところ、EngHelperプロジェクトで英辞郎を使ったKindle用辞書を作っていたのだが、ライセンスの制約上、生成したデータの再配布はできない。手前味噌ながら、EngHelperの辞書の使い勝手はかなり良いのだが、より手軽にKindle上で英和辞書を試したいという人達のために再配布可能な辞書を作ろうと思い立った。で、WordNet日本語版を使うとそこそこうまくできそうな気がしたので、実際やってみた。 WordNetはプリンストン大

永続連想配列の一実装であるKyoto Cabinetを用いた辞書検索システム（仮称：kcdict）の機能について前回の記事で説明した。今回は辞書検索システムの内部の実装について紹介する。 データベースの構造 デフォルトでは検索語の前方一致検索を行うので、前方一致検索が高速に行えるデータ構造が求められる。辞書順の比較関数を使ったB+木はまさにその目的に叶うので、それを採用する。 辞書データには同じ検索語を持つ複数のエントリが存在するという、いわゆる重複キー状態が発生するが、KCのB+木は重複キーを許さない実装になっている。そのため、検索語の末尾に識別用の文字列を連結して、各々のエントリのユニーク性を確保する。同一検索語のエントリ同士の順序をユーザが操作できるようにするためにもこの識別用文字列は利用される。各々のエントリにはユーザが任意の数値を付与することができるようになっており、同一検索語の

英和辞書や和英辞書などの辞書データは、検索文字列をキーとして使って、その値である説明文を取得するための連想配列である。Kyoto Cabinetを使うと非常に簡単に辞書検索システムを実装できることを2回に渡って示したい。これを読めば、英辞郎やWordNetのデータを使って自分の好みの辞書検索システムを簡単に作れるようになるはずだ。第1回目は、辞書検索システムの仕様策定と実際の機能について説明する。 デモ WordNetを使った英英辞書の検索システムを設置したので、まずは使ってみて欲しい。前方一致検索や完全一致検索はもちろん、曖昧検索や正規表現検索もできるスグレモノである。そして、早い。このサーバは、さくらVPSの一番安いプランで動作させているのだが、それでも大抵の動作がほぼ一瞬で完了するのがおわかりいただけるだろう。 http://fallabs.com/kyotocabinet/dict

前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定

いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以

Google has released LevelDB, which is a fast persistent key-value store. Although I think that typical use cases of Kyoto Cabinet and LevelDB are different, I have no dought that LevelDB is promissing and useful. BTW, Kyoto Tycoon can embed arbitrary DBM-style databases by the plug-in mechanism. I explain how to use LevelDB on Kyoto Tycoon. Installation of LevelDB As preparation, you have to insta

Overview Kyoto Tycoon is a lightweight database server with auto expiration mechanism, which is useful to handle cache data and persistent data of various applications. Kyoto Tycoon is also a package of network interface to the DBM called Kyoto Cabinet. Though the DBM has high performance and high concurrency, you might bother in case that multiple processes share the same database, or remote proc