この表を仮定すると:
create table s4 (a timeuuid primary key, b timeuuid, stuff text);
create index s4_index1 on s4 (b);
これは機能します：
select * from s4 where b = 259300f1-01bb-11e3-89a8-896ab45a266f;
しかし、これは失敗します。なんで？どうすれば回避できますか？
update s4 set stuff='f' where b=259300f1-01bb-11e3-89a8-896ab45a266f;
error->> Bad Request: Non PRIMARY KEY b found in where clause
主キーを指定せずに更新を行うと、Cassandra は最初に分散検索を実行してすべてのレコードを取得する必要があります。次に、これらすべてのレコードの更新を内部的に発行します。実装することは可能ですが、Cassandra 内の現在の書き込みパスとは大きく異なります。
現在の書き込みパスは、挿入/更新を調べて、キーに基づいてどのノードに送信する必要があるかを判断し、それらのノードに要求を送信してディスクに書き込みます。
update X where YY がセカンダリ インデックスであるの書き込みパスは、大きく異なります。すべてのノードに更新要求を送信し、検索/更新プロセスが完了するのを待つ必要があります。通常の書き込みよりもはるかに時間がかかりますが、Cassandra は高速書き込みに優れています。
そうは言っても、Cassandra プロジェクトは常に新しい機能の貢献と議論にオープンです。 http://wiki.apache.org/cassandra/HowToContribute
「それを回避するにはどうすればよいですか」について。唯一の方法は、選択ステートメントを自分で実行してから、自分ですべての行を更新することです。または、実行する更新が主キーに基づくように、データ モデルを再設計します。