開発メモ: 和英辞書の高精度化
英和辞書である英辞郎を使って使いやすい和英辞書機能を作ったという話。EngHelperの辞書検索ルールで実装している。 和英辞郎 英辞郎をには和英辞書として和英辞郎というデータがついているが、これは英辞郎のデータを転置したものをベースとして、多少人間が編集を加えたものらしい。例えば、英辞郎において「波動」を訳語を含む見出し語は以下のものである。 fluctuation [名] 波動、〔波のような〕振動 pulsation [名] 脈拍、拍動、脈動、動悸、波動、振動 surge [名] 大波、うねり、高潮、波動 undulation [名] 波動、うねり、振動、音波、光波、動悸 wave [名] 波動 そして、和英辞郎において「波動」という見出し語の内容は以下のものである。 波動 : fluctuation●pulsation●surge●undulation●wave ということで、たまに
開発メモ: 編集距離による曖昧検索
英和辞書の曖昧検索を実装したという話。それにあたってDB層で編集距離による絞り込みを実装している。 image:1:1331519319-spelling.png 曖昧検索 二つの文字列があったとして、一方をもう一方と一致させるために何回の編集操作が必要かという尺度を編集距離といい、それは二つの文字列の類似性を測るのに利用することができる。最も典型的なのはレーベンシュタイン距離である。 スペルミスをしてしまった場合に最も似た候補を出力してくれると英和辞書の機能としては嬉しい。というか俺はスペルミスをしまくるので俺にとっては必須の機能である。入力されたクエリから数文字分ずれていても検索できる曖昧検索機能が欲しいということだ。EngHelperの辞書機能にもそれを搭載しておきたい。 LとRの区別がつかない日本人としては、「english」を探そうとして「engrish」とか入力しがちである。そ
開発メモ: WordNetで英辞郎を補完する
英辞郎の野良Kindle版を作るにあたり、WordNetのデータを使ってデータの質を向上させてみたら、なかなかうまくいった。品詞タグの補完と収録語の再選定ができた。 英辞郎の品詞タグ 英辞郎の収録語には動詞や名詞などの品詞がタグとしてつけられていてとても便利である。例えばこんなのだ。 drug [名] 麻薬、薬物、覚醒剤、ドラッグ [名] 薬 [自動] 薬物中毒である、麻薬漬けになっている [他動] ...に薬を飲ませる、麻酔をかける、（人）に薬を盛る［一服盛る］ ただ、残念ながら、全ての収録語に付けられているわけではない。マイナーな語や熟語や慣用句には付いてないことが多い。人間が読む分には品詞タグがなくても説明文から品詞を推定でないことはないが、やっぱりタグ付けしてあった方が一目で理解しやすい。Kindleのポップアップ辞書として使うならなおさらだ。また、機械がデータを使う場合にも品詞タ
開発メモ: 辞書検索システムを作ろう （実装編）
永続連想配列の一実装であるKyoto Cabinetを用いた辞書検索システム（仮称：kcdict）の機能について前回の記事で説明した。今回は辞書検索システムの内部の実装について紹介する。 データベースの構造 デフォルトでは検索語の前方一致検索を行うので、前方一致検索が高速に行えるデータ構造が求められる。辞書順の比較関数を使ったB+木はまさにその目的に叶うので、それを採用する。 辞書データには同じ検索語を持つ複数のエントリが存在するという、いわゆる重複キー状態が発生するが、KCのB+木は重複キーを許さない実装になっている。そのため、検索語の末尾に識別用の文字列を連結して、各々のエントリのユニーク性を確保する。同一検索語のエントリ同士の順序をユーザが操作できるようにするためにもこの識別用文字列は利用される。各々のエントリにはユーザが任意の数値を付与することができるようになっており、同一検索語の
開発メモ: 辞書検索システムを作ろう （機能編）
英和辞書や和英辞書などの辞書データは、検索文字列をキーとして使って、その値である説明文を取得するための連想配列である。Kyoto Cabinetを使うと非常に簡単に辞書検索システムを実装できることを2回に渡って示したい。これを読めば、英辞郎やWordNetのデータを使って自分の好みの辞書検索システムを簡単に作れるようになるはずだ。第1回目は、辞書検索システムの仕様策定と実際の機能について説明する。 デモ WordNetを使った英英辞書の検索システムを設置したので、まずは使ってみて欲しい。前方一致検索や完全一致検索はもちろん、曖昧検索や正規表現検索もできるスグレモノである。そして、早い。このサーバは、さくらVPSの一番安いプランで動作させているのだが、それでも大抵の動作がほぼ一瞬で完了するのがおわかりいただけるだろう。 http://fallabs.com/kyotocabinet/dict
開発メモ: さらに並列化したMapReduce
Kyoto CabinetのMapReduceフレームワークは1台のローカルマシンで動作するものだが、マルチスレッドによってマルチCPUコアを使い切ることには重要な意味がある。そういったスレッド関係の機構はフレームワーク内で暗黙的に管理されるので、アプリケーションプログラマはそれらについて考える必要はない。 以前の記事でも述べたが、MapReduceフレームワークは既に2つの並列化オプションをサポートしている。XPARAMAPはmapperを並列化し、XPARAREDはreducerを並列化する。さらに、最新版では2つの工夫でmapperの並列性を向上させている。 並列flusher mapper関数によって出力されたkey-valueペアは内部のオンメモリバッファにキャッシュされ、内部の一時ストレージに一定の頻度でフラッシュされる。従来版では、並列mapperオプションが指定されていたと
開発メモ: memcachedメッセージキューの詳しい使い方
memcachedプロトコルでメッセージキューが実現できるという話を前回したが、今回はその具体的な使用方法を解説してみる。 サーバを起動する まずはサーバを起動しないと始まらない。典型的には以下のコマンドで立ち上げるとよい。 $ ktserver -th 1 -ls \ -plsv /usr/local/libexec/ktplugservmemc.so \ -plex 'port=11211#tout=30#thnum=16#opts=fq#qtout=10' \ 'casket.kct#ktopts=p' 「-th 1」でメインサーバのスレッド数を1にしている。最新版からはデフォルトで16スレッドを立てるのだが、アプリ側からはメインのサーバにはアクセスしないだろうから、1個あればよい。「-ls」はログレベルをSYSTEMに設定。「-plsv ...」では、memachedプラガブルサー
開発メモ: memcachedプロトコルでメッセージキューを実現する
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
開発メモ: オンメモリDB＋スナップショットで爆速永続キャッシュ
Kyoto Tycoonに自動スナップショット機能が実装され、オンメモリDBでも永続化できるによになり、高速性と永続性を両立できるようになったよという話 自動スナップショットとは 「永続化したキャッシュサーバ」としてのコンセプトを掲げるKyoto Tycoonだが、それはメモリ上でなくファイル上でデータベースを表現するからである。今回の自動スナップショットによる永続化は、それとは異なる。オンメモリDBの中にあるレコードを定期的にファイルに書き出すことで永続化するのだ。 ファイルDBの場合、データベース内のレコードは常にファイルに書かれている。よって、サーバプロセスを再起動してもレコードは消えない。その代償として、ファイル上で更新された領域をディスクに書き込むためのIO処理にかかるオーバーヘッドが無視できない。ファイルシステムのページキャッシュによって緩和されるとはいえ、IO処理がランダムア
開発メモ: Kyoto Tycoonを各種スクリプト言語で使う最も簡単な方法
Kyoto TycoonのRESTfulインターフェイスを使って各種スクリプト言語から操作するためのメモ。 背景 Kyoto TycoonはHTTPを喋るデータベースサーバなので、HTTPを喋れるクライアントライブラリを備える全ての言語処理系から利用することができる。とはいえ、HTTPの知識が多少なりとも求められるというのは煩雑である。なので、プロトコルを隠蔽したアクセスライブラリが欲しい。C++版は俺が実装したAPIがKT本体に同梱されているが、その他の言語に関しては、その言語毎の有志に実装をお任せすることにしている。 しかし、そのようなAPI出てきていない環境では生HTTPクライアントライブラリを使うしかない。といっても、KTのRESTfulインターフェイスを使うと、基本的なアクセスライブラリであれば非常に簡単に書くことができる。ここでは、RubyとPython3の例を挙げてみる。 R
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fallabs.com