これが状況です
CFから約10kのキーをフェッチしようとしています。クラスターのサイズ：10ノードノード上のデータ：250 GB割り当てられたヒープ：12 GB使用されたスニッチ：同じデータセンターに2つのラックがあるプロパティスニッチ。番号。ノードごとのcfのsstablesの数：約8〜10
私はスーパーカラムアプローチです。各行には約300のスーパーカラムが含まれており、これには5〜10のカラムが含まれています。10kの行キーと1つのスーパーカラムを使用してmultigetを起動しています。
初めてコールを起動すると、結果が返されるまでに約30〜50秒かかります。その後、cassandraはキーキャッシュからデータを提供します。その後、2〜4秒で結果が返されます。
したがって、cassandraの読み取りパフォーマンスがプロジェクトの妨げになっています。phpcassaを使用しています。結果をより速く取得できるようにcassandraサーバーを微調整する方法はありますか？
スーパーカラムアプローチは読み取りパフォーマンスに影響しますか？
スーパーカラムの使用は、サブカラムの数が比較的少ないユースケースに最適です。詳細はこちら： http ：//www.datastax.com/docs/0.8/ddl/column_family
まだこれを行っていない場合に備えて、phpcassaライブラリを使用しているので、Thriftライブラリをコンパイルしたことを確認してください。phpcassaライブラリフォルダの「INSTALLING」テキストファイルごとに：
C拡張機能は、phpcassaのパフォーマンスにとって非常に重要です。
C拡張機能を使用できるように構成および作成する必要があります。
cd thrift/ext/thrift_protocol
phpize
./configure
make
sudo make install
php.iniファイルに次の行を追加します。
extension=thrift_protocol.so
このようなことについてRNDの多くを行った後、これを最適に機能させる方法はないと考えました。cassandraがこれらの10k行を初めてフェッチするときは時間がかかり、これを最適化する方法はありません。
1）ただし、実際には、同じレコードにアクセスする可能性が高いため、キーキャッシュを最大限に活用します。キーキャッシュのデフォルト設定は2MBです。したがって、メモリの問題なしに128MBに増やすことができます。データのロード後、予想されるクエリを実行してキーキャッシュをウォームアップします。
2）JVMは8〜10 GBで最適に動作します（それを証明する数値はありません。ただ観察してください）。
3）物理マシン（クラウドや仮想マシンではない）を使用している場合に最も重要なのは、使用しているディスクスケジューラを確認することです。1つのセクションからすべてのキーを読み取るため、ディスクヘッダーの移動を減らすため、cassandraに適したNOOPに設定します。
上記の変更は、許容範囲内でクエリに必要な時間を短縮するのに役立ちました。
上記の変更に加えて、サイズは小さいが頻繁にアクセスされるCFがある場合は、行のキャッシュを有効にします。
上記の情報がお役に立てば幸いです。