転置インデックスの圧縮技法
転置インデックスは、検索エンジンの実装において、中心的な役割を果たすデータ構造である。 転置インデックスのデータ構造とアルゴリズムは、クエリ処理アルゴリズムとともに、検索エンジンの性能に直結する。とくに大規模な検索エンジンにおいては、キャッシュ効率を高めてクエリ処理を高速化するために、転置インデックスの圧縮は必要不可欠となっている。 この記事では、転置インデックス、とくにポスティングリストの圧縮について、近年の手法を簡単にまとめる。 目次 転置インデックスの基本 転置インデックスのデータ構造と特性 転置インデックスのアクセスパターン 近年のインデックス圧縮技法 Variable-Byte Family VByte Varint-GB Varint-G8IU Masked-VByte Stream-VByte Opt-VByte Simple Family Simple9 Simple16
英語論文執筆のために arXiv からの例文検索サービスを作った話
arXiv の論文から例文を検索する Hyper Collocation というサービスを公開しました． 以下はあまり整理されていない製作の記録です． 英語論文執筆用の例文検索サービス 英語での論文執筆の際に，専門用語を含む例文や言い回しのパターンを知りたいことが多々あります．有用なサービスとしては ライフサイエンス辞書のコーパス検索 Springer Exemplar (2018/2/1頃に終了) がありますが， データがライフサイエンス系の論文に限られている（ライフサイエンス辞書） ソートの基準が頻度順ではないため典型的な例文が上位にこない ストップワードに近い頻出語を検索した際の 検索が重い（Springer Exemplar） 表示可能な検索結果が偏る（ライフサイエンス辞書） という不満点があったので，並行して個人的な資料から検索を行うプログラムを作って使っていました． しかし，個
GitHub - powturbo/TurboPFor-Integer-Compression: Fastest Integer Compression
TurboPFor: The synonym for "integer compression" ALL functions available for AMD/Intel, 64 bits ARMv8 NEON Linux+MacOS/M1 & Power9 Altivec 100% C (C++ headers), as simple as memcpy. OS:Linux amd64, arm64, Power9, MacOs (Amd/intel + Apple M1), 🆕(2023.04) Rust Bindings. Access TurboPFor incl. SSE/AVX2/Neon! from Rust 👍 Java Critical Natives/JNI. Access TurboPFor incl. SSE/AVX2/Neon! from Java as f
連想配列はトライでしょ的な話がでていたので入門記事を書いてみた - EchizenBlog-Zwei
なにやらDan Kogai氏の以下の記事が話題になっている様子。 404 Blog Not Found:Algorithm - 連想配列の実装としてのハッシュはオワコン? 連想配列(キーワードを投げると対応する値が返ってくるデータ構造)はハッシュテーブルで実装するのではなく、これからはトライ(trie)木を使うのがイケてる！(意訳)という内容だった。 連想配列にハッシュテーブルを使うのが良いか悪いかについては色々と意見があると思うので特にこの記事では触れない。 今回は連想配列として使えると話題のトライ木とはなんぞ、という入門的な記事にしようと思う。 トライ木が持つ機能 最初にトライが持つ以下の3つの機能について説明する。 - lookup - common-prefix-search - predictive-searchまずトライは連想配列として利用できる。つまりキーワードと値のペアを登
最近のSuffix Arrayによる全文検索について調べてみた - EchizenBlog-Zwei
ちょっと興味があったので調べてみた。 全文検索には主に転置インデックス(Inverted Index)によるものと接尾辞配列(Suffix Array)/接尾辞木(Suffix Tree)によるものがある。 前者は効率的にデータを扱えるものの、キーワード単位でしかインデックスを付けられないので形態素解析するなどして検索対象のテキストからキーワードを取り出す必要がある。 後者は任意のクエリにマッチすることができるもののデータサイズが大きくなりがちであることと検索結果となる文書にスコア付けができないなどの問題がある。 最近ではSuffix Array/Treeによる全文検索に対して簡潔データ構造(Succinct Data Structure)を導入してデータサイズを小さくしたり、スコアをもたせる方法が提案されたりと何かと話題が多い。 Suffix Array/Treeが持つ文書検索の機能は、
30分でわかる高性能な圧縮符号vertical code - EchizenBlog-Zwei
検索エンジンの転置インデックスなどデータ列を小さいデータサイズで持たせたい、という状況がある。こういう場合圧縮符号を使うのが一般的でunary符号やgamma符号、delta符号など様々な種類がある。 圧縮符号の中でイチオシなのがvertical code(vcode)。これは岡野原(@hillbig)氏によって提案された圧縮符号で単純な仕組みでdelta符号並の性能を誇っている。 本記事ではvcodeのポイントを絞って30分でわかるように解説してみる。 vcodeは本棚に本を並べる作業を連想すると理解しやすい。本棚は予め高さが決まっているので全ての本が入るような本棚を用意する。つまり というようなものを想像する。 この本棚は8冊の本が並んでいるが左から5冊目の本が他よりも背が高い。このため5冊目の本に合わせて背の高い本棚が必要になる。だが他の本は5冊目の本ほどに背が高くないので、5冊目が
(続)LOUDSトライのライブラリの性能を比較してみた - EchizenBlog-Zwei
LOUDSトライを比較した記事を書いたところ@overlast氏からwikipediaタイトルのような偏りの少ないデータでも評価してはどうか、という賢明なアドバイスを頂いたので試してみた。 LOUDSトライのライブラリの性能を比較してみた - EchizenBlog-Zwei http://dumps.wikimedia.org/jawiki/latest/ からwikipediaタイトルを取得した。 $$ wc -l jawiki-latest-all-titles-in-ns0 1231018 jawiki-latest-all-titles-in-ns0約123万件ある。これを用いてトライを作成すると以下のようなデータサイズとなった。 元データ : 26960268 byte marisa-trie : 7,199,728 byte ux-trie : 10,364,932 byte
LCP(Longest Common Prefix)を用いたSuffix Arrayの検索 - EchizenBlog-Zwei
Suffix Arrayは「インデックスの構築」と「キーワードの検索」からなる。それぞれ構築には文字列のsortが、検索には文字列の二分探索が必要になる。 以前にCompressed Suffix Arrayのライブラリtsubomiを実装したときにはsortについてはマルチキー・クイックソート(multikey-quicksort)というアルゴリズムを用いた。一方で二分探索については特に工夫をしていなかった。 さすがにこのまま放っておくのは気が引けたのでSuffix Array論文を読みなおしてみたらLCP(Longest Common Prefix)を用いた二分探索の方法が書いてあった。シンプルだが賢い方法だったのでメモしておく。これはすごい(というか今まで読み飛ばしてたことのほうが問題ですね。はい)。 さて。まずLCP(Longest Common Prefix)とは何かと言うとその
簡潔データ構造(Succinct Data Structure)で最初に読むと良さそうな論文 - EchizenBlog-Zwei
最近、簡潔データ構造(Succinct Data Structure)まわりの論文を色々読んでいる。その中で良さそうなものをいくつかピックアップしてみた。まだ調査中なので他に良いものがあったら教えてもらえると嬉しいです。 (1) Space-efficient Static Trees and Graphs(link) G. Jacobson; IEEE1989 まずはLOUDS論文。簡潔データ構造の元祖なので最初に読むと良さげ。 (2) Succinct Indexable Dictionaries with Applications to Encoding k-ary Trees and Multisets(link) R. Raman, V. Raman, and S. S. Rao; SODA2002 簡潔ビットベクトルは通常n+o(n)なんだけど、これをnH0+o(n)にしたよ、
CCPという新しいデータ圧縮の国際会議が開催されるそうです - EchizenBlog-Zwei
CCP2011(1st International Conference on Data Compression, Communication and Processing)というデータ圧縮の国際会議が新しく開催されるとのこと。 1st International Conference on Data Compression, Communication and Processing データ圧縮は興味のある分野なので、これは気になる。ってことでoverviewを和訳してみた。あと日程、招待講演についてもメモ。 overview和訳。訳し間違っていたらすみません。英語苦手。。。 概略と範囲 このカンファレンスではデータ圧縮、データ通信、データ処理の 理論的、実践的な側面に関連したアイデアや業績について意見交換するために、 欧州をはじめとした国際的な研究者が一堂に会するでしょう。 その構想は、
Burrows-Wheeler変換(BWT)の圧縮率が高い理由 - EchizenBlog-Zwei
Burrows-Wheeler変換(BWT, Burrows-Wheeler Transform)されたテキストは同じ文字が並びやすい。従ってランレングス法等と併用することで大きな圧縮効果を得ることができる。 では、なぜBurrows-Wheeler変換によって同じ文字が並びやすいのか。これについて説明するよ。 BWTは与えられたテキストを1文字ずつずらして並べたものを考える。例えばmississippiなら mississippi# ississippi#m ssissippi#mi sissippi#mis issippi#miss ssippi#missi sippi#missis ippi#mississ ppi#mississi pi#mississip i#mississipp #mississippiという感じ。ここでテキストの先頭と末尾はマーカ#を通じて繋がっていることを記
テキスト圧縮はこれ一冊でOK！？な優良書籍「The Burrows-Wheeler Transform」を読んだ - EchizenBlog-Zwei
以前より気になっていた書籍「The Burrows-Wheeler Transform Data Compression, Suffix Arrays, and Pattern matching」を読む機会を得ることができた。それなりに高額な本だったので購入が躊躇っていたのだけど、これは自分用に購入してもいいかも。というくらいの良書だったので紹介しておく。 本書はタイトルのとおりBWT(Burrows-Wheeler変換)に関する書籍。サブタイトルにあるようにデータ圧縮やSuffixArrayによる全文検索についても充実した内容になっている。最後のPattern matchingはテキストから検索キーとexactにマッチした、もしくは類似した箇所を取り出すよ、という話。2008年の本なので比較的新しい話題も扱っていて満足度が高い。 また本書の特色は圧縮ありきで始まり、そこから全文検索可能な
話題のwat-arrayを使ってBurrows-Wheeler変換(BWT)してみた - EchizenBlog-Zwei
先日PFIの岡野原氏によってwat-arrayというライブラリが公開された。 wat-array : wavelet木を利用した高速配列処理ライブラリ : Preferred Research Blog このライブラリは内部でウェーブレット木(wavelet tree)という簡潔データ構造(succinct data structure)を使っている。このため文字列に対するrank()やselect()などの操作が効率的にできるようになっている。 ・・・といっても馴染みのない人にとっては何が嬉しいのかピンと来ないかもしれない。そこでBurrows-Wheeler変換(BWT, Burrows-Wheeler Transform)を例にとってwat-arrayの使いみちを説明してみる。 Burrows-Wheeler変換というのはテキストを同じ文字が並びやすいように変換したもので、通常ランレ
wat-arrayでラクラク実装☆FM-Indexの作り方 - EchizenBlog-Zwei
というわけで大変便利なライブラリwat-arrayを使ってFM-Indexを簡単に実装してみるよ。本格的なライブラリは既にFM-Index++という良いものがあるので、本記事では仕組みの解説を目的とする。 参考資料: FM-index++を公開しました - tb_yasuの日記 An alphabet-friendly FM-index (P. Ferragina, G. Manzini, V. Makinen, G. Navarro, 2004) なお、本記事では前回の記事で実装した(ってほどでもないけど)text2bwt()とLF()を使っている。 話題のwat-arrayを使ってBurrows-Wheeler変換(BWT)してみた - EchizenBlog-Zwei 今回もテキストとしてmississippi#を使う。まずテキストから任意のキーの出現回数を得る関数get_rows(
CSAを使った全文検索ライブラリtsubomiを公開してみる - EchizenBlog-Zwei
しばらく前から作っていた全文検索ライブラリtsubomiを公開しておく。 本ライブラリは接尾辞配列(Suffix Array)というアルゴリズムを使っていて、入力として与えたキーワードを含む行をテキストデータから探して、その行と出現位置を取得できる。さらに圧縮接尾辞配列(Compressed Suffix Array)による圧縮もサポートしているのでインデックスサイズを小さく抑えることができる。 本ライブラリは検索のためのAPIのほかに、インデックス作成、圧縮、検索を行うツールが付属している。ツールを使うだけでも、ある程度のことができる。 以下、簡単に紹介。 tsubomiはGoogleCodeでコードを管理している。詳細は下記URLを参照。 http://code.google.com/p/tsubomi/ コード管理にはsubversionを使っているので $$ svn checkou
Vertical Codeはunary符号の6倍すごい - EchizenBlog-Zwei
Vertical Codeを実装してみたらunary符号のときよりデータサイズが1/6になった。とても感動したので、この気持ちを伝えるため記事を書いてみるよ。 Vertical Codeを使うことになった経緯は↓を参照 Vertical Codeを調べたよ - EchizenBlog-Zwei Vertical Codeはその名の通り、データをVerticalに持っておく符号形式。デルタ符号くらいのデータサイズで収まる。だったらデルタ符号でいいじゃんと思うのだが、Vertical Codeにはselect()、rank()という操作が簡単に実装できるメリットがある。 select(pos)とはpos番目のデータ値の累計値を求める操作。rank(value)とは累計値がvalue以上になるはじめてのposを求める操作。互いに逆関数の関係にある。(unary符号を用いたときとrank()、se
圧縮接尾辞配列ライブラリ csalibの圧縮率の高さは異常 - EchizenBlog-Zwei
圧縮接尾辞配列の第一人者、定兼先生が開発、公開してくださっているcsalibを試してみたのでメモ。 http://researchmap.jp/sada/csalib/ まずはgooglecodeからcsalibとdbwtを入手。解凍しmakeする。 $$ mkdir csalib/ $$ cd csalib/ $$ wget http://csalib.googlecode.com/file/csalib100810.zip $$ unzip csalib100810.zip $$ make $$ cd .. $$ mkdir dbwt/ $$ cd dbwt/ $$ wget http://csalib.googlecode.com/file/dbwt100730.zip $$ make $$ cd ..このライブラリはdbwtでテキストをBurrows-Wheeler変換し、その後m
5分でわかる(かもしれない)圧縮の基本 - EchizenBlog-Zwei
大規模データを日常的に扱う人にとって、データ圧縮は基本。絶対ないと困るわけではないけど、あると格段に世界が広がる。ドラクエで言うところのルカニみたいなもの。 でも圧縮というとデータをバイナリで持たないといけないとか、なんとなく面倒なので目を背けがち。そこで5分でわかるような感じで説明を書いておく。 基本的な圧縮の方法は差分圧縮というのがある。今回はこれを説明する。 char型のデータが8つ並んでいると考える。 6 3 2 1 7 5 4 8とりあえずバイナリにしてみる。便宜上、縦に書く。 6 3 2 1 7 5 4 8 =============== 1の位:0 1 0 1 1 1 0 0 2の位:1 1 1 0 1 0 0 0 4の位:1 0 0 0 1 1 1 0 8の位:0 0 0 0 0 0 0 1 16の位:0 0 0 0 0 0 0 0 32の位:0 0 0 0 0 0 0 0
Twitter本文と言及URLの圧縮 - kaisehのブログ
最近、Twitterのデータを収集しています。APIで取得したtweet本文や、そこから抽出したURLを片っ端からDBに保存していくと件数が莫大になるので、ディスクスペースを極力節約したいところですが、個別のtweet本文や言及URLは短い文字列なので、普通に1件ずつgzip等で圧縮してもほとんど意味がないか、オーバーヘッドが出て逆効果になってしまいます。 そこで、収集済みのサンプルデータを元にハフマン木を作っておき、それを共通利用してtweetを圧縮してみました。 用意したのは、英語ユーザ/日本語ユーザ/韓国語ユーザ各1000人のtweetサンプルをベースにしたハフマン符号と、tweet本文から抽出したURL文字列をベースにしたハフマン符号の4種類です。 頻度表は次のようになりました。 char (en) freq (en) char (ja) freq (ja) char (ko) f
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
snippets/vc.cc at master · shnya/snippets · GitHub