3

これは、チャットの種類のアプリケーション用の私の cassandra テーブルです。

CREATE TABLE tax_keyspace_dev.chat_messages (
  message text,
  when timestamp,
  from_id text,
  to_id text,
  read boolean,
  participants text,
  PRIMARY KEY(participants, when, to_id)
);

このクエリは次のように機能します。

select * from tax_keyspace_dev.chat_messages where participants='caone@one.com_shashank_shrivastava@acme.com' order by when;

ただし、次のクエリは機能しません。

select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when;

エラーは「Bad Request: PRIMARY KEY part to_id cannot be restricted (先行部分が制限されていないか、非 EQ 関係による場合)」です。

update tax_keyspace_dev.chat_messages set read=true where participants = 'caone@one.com_shashank_shrivastava@acme.com' and when = '2014-04-10 17:44:22+0530';

エラーは「Bad Request: Missing Required PRIMARY KEY part to_id」です

複合キーから「to_id」を削除し、次のように別のインデックスを作成すると:

CREATE TABLE tax_keyspace_dev.chat_messages (
 message text,
 when timestamp,
 from_id text,
 to_id text,
 read boolean,
 participants text,
 PRIMARY KEY(participants, when)
);
CREATE INDEX idx_chat_messages_to ON tax_keyspace_dev.chat_messages (to_id);

その後、他のクエリは機能しますが、これは失敗します:

select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when;

エラー「不正な要求: 2 番目のインデックスを使用した ORDER BY はサポートされていません。」

これらすべてのユースケースが機能するようにテーブルを設計するにはどうすればよいですか?

select * from tax_keyspace_dev.chat_messages where participants='caone@one.com_shashank_shrivastava@acme.com' order by when;
update tax_keyspace_dev.chat_messages set read=true where participants = 'caone@one.com_shashank_shrivastava@acme.com' and when = '2014-04-10 17:44:22+0530';
select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when;
4

1 に答える 1

5

cassandra を使用する場合、主キーの最初の部分がパーティション キーになります。したがって、行を取得するために特定のパーティションに移動するには、常に等しい制約を持つ主キーを指定する必要があります。

select * from tax_keyspace_dev.chat_messages where participants='caone@one.com_shashank_shrivastava@acme.com' order by when;

次のクエリは、「participants」という名前の行パーティションに到達し、ASC の既定の順序付けを使用するときに並べ替えることを示唆しています。列は既定で昇順で並べられているため、この並べ替えも必要ない場合があります。

select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when; 

select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when;

値を見つけるための行パーティションを提供していないため、次のクエリは機能しません。デフォルトでは、データを含むSSTableを識別するために行パーティション キーが使用されます。したがって、デフォルトでは、cassandra はこのコストのかかる操作をサポートしていません。

何が起こるかは簡単です。この行パーティション キーが見つからない場合、cassandra はすべての SSTable をスキャンして、そこからデータを取得する必要があります。これはALLOW FILTERINGを使用して実行できますが、ブルーム フィルターを使用しないため、クエリのコストが高くなります。

update tax_keyspace_dev.chat_messages set read=true where participants = 'caone@one.com_shashank_shrivastava@acme.com' and when = '2014-04-10 17:44:22+0530';

Cassandra の更新の場合は、挿入と変わりません。マップを操作する場合を考えてみましょう。値を変更しようとしていますが、マップの完全なキーがありません。内部的に、cassandra は値を "participants_when_to_id": value に格納します。

于 2014-04-11T12:39:21.900 に答える