問題タブ [secondary-indexes]

私は Mnesia のドキュメントと 3 つの有名な Erlang の本に目を通しました。単一列のプライマリ インデックスとセカンダリ インデックスのみを作成して使用できるようです。それとも、例がカバーしているだけなのでしょうか? 各列に個別のインデックスを作成した場合、Mnesia は複数列のキー インデックス検索をシミュレートするためにそれらをインテリジェントに使用できますか? もしそうなら、パフォーマンスは単純なテーブルスキャンよりもはるかに優れていますか?

複数列のインデックス作成が Mnesia でサポートされていない場合、そのネイティブ dbms を考えると、Erlang でこの機能をシミュレートした人がいます。

2 番目の質問: 制約 (参照、チェック)、トリガー、およびイベントベースの通知をシミュレートするのはどうですか?

Thrift API を使用して cassandra db の新規または既存の列にセカンダリ インデックスを作成する方法の例を探しています。Thrift に関するドキュメントは非常にまばらです。誰か兄弟を助けることができますか？

私が疑問に思っていた 2 番目の質問は、cassandra へのインターフェイスとして phpcassa を使用することにマイナス面はありますか? 私の理解では、Thrift の上にあるので、このシナリオにパフォーマンス上の欠点はありますか?

Cassandra 0.8、Thrift 2.0、および php 5.2.9 を使用しています。

Name1、Name2、およびタイムスタンプの2つの文字列で構成される複合主キーを使用しています（例：'Joe：Smith：123456'）。Name1またはのいずれかの等式条件を指定して、タイムスタンプの範囲を照会したいと思いますName2。

たとえば、SQLでは次のようになります。

SELECT * FROM testcf WHERE (timestamp > 111111 AND timestamp < 222222 and Name2 = 'Brown');

と

SELECT * FROM testcf WHERE (timestamp > 111111 AND timestamp < 222222 and Name1 = 'Charlie);

私の理解では、複合キーの最初の部分はパーティションキーであるため、2番目のクエリは可能ですが、最初のクエリではName2に何らかのインデックスが必要になります。

複合キーのコンポーネントに個別のインデックスを作成することは可能ですか？それとも私はここで何かを誤解していますか？

従来のRDBMSシステムには主キーの概念があることを私たちは知っています。この主キーは基本的に、この特定のキーのテーブル内のレコードにインデックスを付けて、より高速に取得するために使用されます。Cassandraのように二次キーのインデックスを提供するNOSQLストアがあることは知っていますが、従来のRDBMSシステムとまったく同じスキーマに従う方法または既存のDB（つまり、さまざまな種類のデータを保持するためにさまざまなテーブルに分割されたDB）がありますが2つ以上のキーのインデックスを提供します。

同じユースケースの例は次のとおりです。

10人の異なる人の名前と年齢の間には1対1のマッピングがあります。ここで、この情報を主キーとして人の名前を含むテーブルに保持すると、人の名前を指定して年齢を取得する方が、人の年齢を指定して名前を取得するよりも比較的高速になります。両方の列にインデックスを付けることができれば、2番目のケースも高速でした。従来のRDBMSでこれを行う代わりに、同じデータを持つ2つのテーブルを作成しますが、一方の主キーは名前であり、もう一方の主キーは年齢ですが、それは無駄になります。レコード数が多い場合は、大量のスペースが必要です。

OrientDB でセカンダリ インデックスを指定する方法はありますか?

指定されたフィールド ( など) を持つすべてのドキュメント参照を含むものが必要ですindexable=true。

永続層を Riak から DynamoDB に移行しています。私のデータ モデルには、オプションのビジネス ID フィールドが含まれており、キーの代わりにクエリできるようにする必要があります。

DynamoDB のセカンダリ インデックスは範囲キーではなくnull、レンジ キーが必要なようです。そのため、Riak のセカンダリ インデックスと名前が似ているにもかかわらず、これはまったく別物に見えます。

外部検索インデックスにデータを投げる以外に、オプションのフィールドを効率的にクエリするエレガントな方法はありますか?

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 以上のペースで発生する可能性があるためです。