英辞郎とStanford subtitle corpusを全文検索するソフトを作った話 #Rust

セットアップ

https://cmder.app/ のフルバージョンをダウンロードして適当なところに解凍。ここではcmdrフォルダを作成してそこに解凍した。
https://booth.pm/ja/items/777563 英辞郎 Ver.144.8（2015年3月20日版）のテキストデータ (2023年3月現在495円)を購入して解凍、cmdrフォルダ内にEIJIRO-1448.TXTをコピー。(英辞郎を使わないなら無くても良い)
https://booth.pm/ja/items/2092290 例文データ『例辞郎』Ver.144.1 (2023年3月現在495円)を購入して解凍、cmdrフォルダ内にREIJI-1441.TXTをコピー。(例辞郎を使わないなら無くても良い)
私が作成したeiji-sub.exeをダウンロードしてcmdrフォルダにコピー。なお、スタンフォード大学字幕コーパスを組み込んであるので230MBある。
Cmder(λって書いてある緑のアイコンのやつです)を起動して右下の三本線マークをクリック。設定が開かれるので『Choose your setup task:』を『{bash::bash}』にする。

使用

Cmder上でeiji-subと打ってエンターキーを押せば自分のソフトが開かれます。
初回起動時はEIJIRO.TXTを整形してEIJIRO.tsv.gzを作成するので検索できる状態になるまで時間がかかります。
初回起動時はREIJI.TXTを整形してREIJI.tsv.gzを作成するので検索できる状態になるまで時間がかかります。
適当に検索ワードを打ってエンターキーを押せば、まず英辞郎(とEdict)内で検索された結果が表示され、次に字幕コーパス内で検索された結果が表示され、次に例辞郎で検索された結果が表示されます。
結果が表示されているときにqを押すと、次の画面に遷移します。
結果が表示されているときにdまたはctrl+dを押すと、画面が下にスクロールします。
反対にuまたはctrl+uでは上にスクロールします。
検索ワードを打ち込む画面でctrl+cを押すとeiji-sub.exeが終了します。
そしてCmder上でexitと入力してエンターキーを押せば、このコンソール画面も閉じられます。

補記

EIJIRO.tsv.gzがあればもうEIJIRO.TXTはいりません。
REIJI.tsv.gzがあればもうREIJI.TXTはいりません。
ビデオの最後にあるように、起動からデータの読み込みが終わるまでに少しラグがあるので、スピード入力した場合には入力文字が説明が表示される前に来てしまうこともありえますが、それでも問題なく入力されています。
EDICTはフリーなプロジェクトです。 http://www.edrdg.org/jmdict/edict.html
EDICTに発音記号が添えてありますが、それはケンブリッジ大学のフリーな成果物です。 https://www.openslr.org/14/
購入した英辞郎のデータ EIJIRO-1448.zipはChrome拡張の高速な英語辞書ツールをつくりました(Mouse Dictionary)でも利用できるのでお得
自身の経験から言って絶対使いみちがないと思うが、Wordnet-Webster1913版もある。wn-webster.exe

開発後記

結局のところ、ただのcat|grepなのだが、英辞郎と字幕コーパスを合わせると400MBあるのでRustとrayonを使い、できる限りメモリの再アロケーションを少なくするよう配慮した。見ての通りページャーの機能はlessにおまかせした。https://github.com/growingspaghetti/websters-1913-console-dictionary/blob/eiji-sub/src/main.rs

ngram索引sqlite版

も作成した。実用には耐えない。

利点
- Core2DuoでもRaspberry Pi Zero Wでも索引データさえあれば全文検索を現実的に利用できる。
欠点
- ビデオにある通り索引データは元データの10倍くらいの大きさがあり、これだけの索引データをコンパイルできるマシンがあれば、トリックを使わなくとも腕力にまかせて全文検索できる。
- 一瞬でデータの所在が分かっても、ディスクの読み込みで時間がかかってしまい、体感時間はずっと遅い。元データを全てメモリ上に読み込んだほうがよろしい。

EIJIRO_NGRAM	EIJIRO_INDEX
文セグメント 12バイトを1ブロック	出現行番号 4バイトを1ブロック
12 bytes	4 bytes

索引ファイルが2GBあっても二分探索しながら24バイト読み取っているだけなので本当に一瞬 https://github.com/growingspaghetti/websters-1913-console-dictionary/blob/eiji-sub-ngram/src/main.rs#L466

eijiro.db (SQLite)

id 行番号 (primary key)	line その行そのもの

メタデータ的な問題、つまり一文一文が可変長であることを脇においても、ハードディスクの読み込み帯域がメモリほどないからとにかく遅い。一文一文をある種のドキュメントであるとみなしてidにぶら下げている。 https://github.com/growingspaghetti/websters-1913-console-dictionary/blob/eiji-sub-ngram/src/main.rs#L377

全ての行が領域的に非連続に所在しているとして、もし読み込みの最小単位がブロックで2KiBだとすると、千件該当したら嵩は2Mになるから、数百クエリがあるならもう全部メモリに載せてしまったほうがいいよね

ngram索引fs版

sqliteを使うものと比べて圧倒的に速くなった。kernelのドライバがファイル読み出しのクエリをうまいことまとめているのだと思う。原理はメディアプレーヤーがマルチメディアファイルを特定の時間位置から再生するのと同様。 https://github.com/growingspaghetti/websters-1913-console-dictionary/blob/en-ja-ngram-no-sql/src/search.rs#L73

EIJIRO_NGRAM	EIJIRO_INDEX
文セグメント 12バイトを1ブロック	EIJIRO_TEXT内の該当行開始位置 4バイト EIJIRO_TEXT内の該当行専有距離 4バイト
12 bytes	8 bytes