2

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

CREATE INDEX srsdata_datetimeinserted ON ccp.srsdata(datetimeinserted);

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

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

nodetool compactionstats

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

pending tasks: 1
- ccp.srsdata: 1

id                                   compaction type       keyspace table   completed total    unit  progress
2616e5d0-c217-11e6-bbed-073889a74ba2 Secondary index build ccp      srsdata 655814    11350989 bytes 5.78%
Active compaction remaining time :   0h00m00s

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

"Cassandra timeout during write query at consistency ONE 
(1 replica were required but only 0 acknowledged the write)"

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

DROP INDEX srsdata_datetimeinserted;

私は得る

"Timed out waiting for server respones".

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

nodetool stop INDEX_BUILD

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

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

2017-01-12 更新

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

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

CREATE CUSTOM INDEX srsdata_datetimeinserted ON ccp.srsdata (datetimeinserted) USING 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = { 'mode': 'SPARSE' };

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

select * from ccp.srsdata where datetimeinserted >= '2017-01-01 00:00:00+0000' AND datetimeinserted < '2017-01-01 15:00:00+0000';
4

0 に答える 0