私は私のプロジェクトの全文索引システムに取り組んでいます。ページのインデックス作成プロセスの一部として、データを非常に多数の非常に小さな断片に分割します。
私はピースのサイズを一定の 20 ～ 30 バイトと同じくらい小さくしましたが、それよりも小さい可能性があります。実際のデータを構成するのは、基本的に 2 つの 8 バイト整数と float です。
私が探しているスケールとこれが作成するピースの数のために、私の目標をはるかに下回る値セットで重大な問題を示している mysql に代わるものを探しています。
私の現在の考えでは、これにはキー値ストアが最適なオプションであり、それに応じてコードを調整しました。
私はいくつか試してみましたが、何らかの理由でそれらはすべて mysql よりもスケールが小さいようです。
数億、数十億、またはそれ以上のキーと値のペアを保存しようとしているので、サイズによってパフォーマンスが大幅に低下しないものが必要です。
私は memcachedb、membase、および mongo を試しましたが、どれも簡単にセットアップできましたが、どれも私にとってそれほどうまくスケーリングしませんでした。
membase には、必要なキーの数と使用可能なメモリが限られているため、最も多くの問題がありました。これはワークロードに非常に近いため、ここでは書き込み速度が非常に重要です。一度書き込みを行い、それを数回読み返し、最終的な更新のために保存します。
削除のパフォーマンスはあまり必要ありません。最終的にはこれをマシン間でスケーリングできるようにしたいので、うまくクラスター化できるものを好みますが、今のところ単一のマシンで動作する必要があります。
また、このプロジェクトを簡単に展開できるようにしたいと考えています。そのため、セットアップが簡単な方がはるかに優れています。プロジェクトはphpで書かれているので、phpから簡単にアクセスできる必要があります。
行やその他の高レベルの抽象化は必要ありません。この場合、それらはほとんど役に立たず、キー値ストアに到達するために他のテストのいくつかからコードをすでに作成しており、それはおそらく3 番目のキーをオフにした行から取得されるものは 2 つしかないため、キー値ストアを使用するための追加作業はほとんどありません。このようにスケーリングできる使いやすいプロジェクトを知っている人はいますか?
このストアを使用して、3 つの数値の個々のセットを格納しています (サイズは、mysql での格納方法に基づいています。他の格納場所では当てはまらない場合があります)。2 つの 8 バイト整数。1 つはドキュメントの ID 用、もう 1 つは単語の ID と、その単語が文書内で占める割合の float 表現 (作品が出現した回数を文書内の単語数で割ったもの) です。このデータのインデックスは、単語 ID とドキュメント ID が含まれる範囲です。このデータを取得する必要があるたびに、特定の単語 ID のすべての結果になります。私は現在、単語ID、範囲、およびその単語/範囲コンボのカウンターをそれぞれ数値のバイナリ表現に変換し、それらを連結して2桁の数字とともにキーを形成し、保存しているそのキーの値を示します。
パフォーマンス測定は、データをストレージに出し入れするプロセスからの出力を見て、ドキュメントの処理速度を確認し、システムの動作速度のより正確な統計を追跡する統計カウンターを迅速に更新するという、やや主観的なものでした。それぞれの保存方法を使っていたときの違いを見ています。