CF に配置された Cassandra のセカンダリ インデックスと DSE の solr インデックス作成のパフォーマンスの違いを知りたいです。
セカンダリ インデックスを配置しなかった CF がいくつかあります。これは、セカンダリ インデックスが (最終的に) 重い読み取り/書き込み CF の重大なパフォーマンスの問題を引き起こすという印象を受けていたためです。これらの CF を検索できるようにするために Solr を使用しようとしていますが、インデックス スキーマをロードすると、対象の列にセカンダリ インデックスを持つように CF が変更されるようです。
Solr のインデックス作成が Cassandra のセカンダリ インデックス作成と異なるかどうか知りたいですか? また、最終的には、大規模なデータ セットと大量の読み取り/書き込みを伴う CF のクエリ (挿入/読み取り) が遅くなりますか? もしそうなら、カスタム インデックス作成をアドバイスしていただけますか (これは回避したかったのですが)。ところで、空間検索には Solr も使用しています (使用しようとしています)。
アドバイス/リンクをありがとうございます。
更新: これらの質問をしている理由をよりよく理解し、正しい質問をしているかどうかを確認するため - 使用例の説明:
センサーイベントを収集しています – たくさん！それらを時系列 CF (EventTL) とスキニー CF (イベント) の両方に格納しています。イベント CF に頻繁に書き込み (挿入と更新) を行っているため、2 次インデックスは配置していません。現在、クエリは、Event を介した単一のイベント、または EventTL を介したイベントの時間範囲に制限されています (イベントの他のプロパティに対する範囲クエリを許可する追加のファット CF を作成しない限り)。
そこで、DSE (Solr+Cassandra) が役立つ可能性があります。Solr 検索を活用することで、イベントの他のプロパティを検索できるようにするために余分な CF を作成することを回避し、一度に複数のプロパティ (場所 + テキスト/プロパティ) を検索できるようになると考えました。しかし、Solr 経由でイベントのインデックス スキーマを追加した後、イベント CF の定義がどのように変化するかを見ると、セカンダリ インデックスが作成されていることがわかります。これは、これらのインデックスがイベントでの行の挿入/更新の問題を (最終的には) 引き起こすかどうかという問題につながります。新しいイベントを「すばやく」挿入できることが必要です。イベントは 1 秒あたり 1000 以上のペースで発生する可能性があるためです。