問題タブ [secondary-indexes]

Debian を実行している VM 上の Cassandra 3.7 の単一ノード インストールでは、約 2,000 万行のテーブルがあります。ここ数日間に挿入されたデータを選択できるようにするために、Datastax DevCenter 1.6.0 を使用してステートメントを実行し、挿入日を含む列にセカンダリ インデックスを作成しました。

ステートメント自体はすぐに実行され、私が理解しているように、コアの 1 つでほぼ 100% の CPU 負荷がかかり、バックグラウンドでインデックス作成プロセスが開始されました。問題は、この CPU 負荷が 24 時間以上高くなっていることであり、仮想マシンを複数回再起動した後でも再び開始します。

インデックス作成プロセスを確認するために、実行しました

しかし、ほとんど最初から 5.78% で止まっているようで、過去 24 時間はまったく変化していません。

テーブルからは SELECT できますが、データを INSERT することはできません。他のテーブルにさえもできません。

インデックスを削除しようとすると、

私は得る

を使用してインデックス構築を停止しようとしました

しかし、それは何の違いもありません。

インデックスの作成を停止して再開するにはどうすればよいですか? それとも、私が考えていない他の何かが実行されていますか?

2017-01-12 更新

インデックスの作成プロセスが停止することはなかったので、インデックスを作成する前に作成したバックアップから仮想サーバーを復元することになりました。

また、Cassandra 3.4 ( http://www.doanduyhai.com/blog/?p=2058 ) で導入された新しい SASI インデックスについても知りました。特に、SPARSE インデックス作成モードは、次のような一意に近いデータを格納するために作成されています。ミリ秒のタイムスタンプ。実際、最大 5 つの同一の値が許可されます。だから私はSASIインデックスを作成しました

作成には約 20 分かかりましたが、問題なく動作しているようです。今では次のようなクエリを作成できます。

メッセージングシステムのdynamodbmessage_tblのように名前が付けられたテーブルがあります。

特定のconversation_idに関連するすべてのメッセージ項目を取得する目的で、次のようにテーブルを設計しました。

属性は次のとおりです。

プライマリ ハッシュ キー=>conversation_id

プライマリソートキー=>date_time

その他の属性=> sender_id、message

conversation_id date_time sender_id message 123456 2016-12-27 06:00:39 pm 10 hai how are you..? 123456 2016-12-27 06:01:00 pm 11 I am fine 123456 2016-12-27 06:01:12 pm 10 ok 123456 2016-12-27 06:01:12 pm 14 Hai man. How are you.?

=> 10 & 14 によって同時に送信される最後の 2 つのエントリは、正しく発生する可能性があります。sender_idその場合、 は属性値を同じ主キーに置き換え、データの損失が発生します。一意のランダムな 6 桁の文字列をセカンダリ ローカル インデックスとして使用しますか?

セカンダリインデックスをソートキー（一意のランダム文字列）として設定すると、同じconversation_idとdate_timeでアイテムをdbに入れても受け入れられます.? 私が間違っている場合は、テーブルを設計するように処方してください。

注: PHP Codeigniter MVC フレームワークを使用しています。