Android デバイスに FTS 3 テーブルがあります。テーブルの列の 1 つは、32 ビット数値の配列をテキスト形式で保持します。私が FTS を使用しているのは、FTS がそのインデックス システムを考えると、一意でない値を見つけるのに比較的非常に高速だからです。
唯一の欠点は、32 ビットの数値をテーブルに入れるのに 10 ～ 11 個の ascII 文字を使用できることです (例: 1234567890)。これにより、4バイトの数値は基本的にascIIの10〜11バイトになり、サイズが元の250％に増加します。言うまでもなく、同じ値がインデックスに押し込まれ、500％の増加と推定されます。
数字を英数字の一意の組み合わせに変えることで、数字を圧縮できると考えました。
例えば
- シンプルなトークナイザーは 26 文字 (aZ) を認識し、大文字を小文字に変換します。
- また、10 個の数字 (0 ～ 9) も認識します。
これにより、バイトごとに 36 の組み合わせを開始して作業することができます。
つまり、最大 36^6 = 21.7 億の範囲を 6 文字で圧縮できます (32 ビット整数の正の範囲を圧縮するのに十分です)。または、7 文字の全範囲 (正と負)。30% の削減。
しかし、単純なトークナイザーは、コードポイントが 128 以上の Unicode 文字も認識します。つまり、圧縮のために Unicode 文字を優先して、英数字をスキップできます。
toekenizer が 128 を超えるすべてのコード ポイントを認識したと仮定すると、32 ビット整数範囲の 99.6% を 4 バイトで、全範囲を 5 バイトでエンコードできます (例: 2 つの unicode16 ビット文字 + 1 つの 8 ビット英数字)。
しかし、私の質問があります... Unicode 範囲の多くは、予約された値で満たされています。単純なトークナイザーは可能なコード ポイント範囲全体を検索しますか (つまり、予約された値は機能しますか?)、それとも一部の値のみを検索しますか (どちらですか?)。