0

申し訳ありませんが、私は MongoDB を初めて使用します。シャードの概念と、ハッシュされたシャード キーを介してサーバー間でデータを分散する方法を理解していると思います。

たとえば、シャードされたユーザーのコレクションがあり、_id_hashed のインデックスがあります (これまでのところ、ユーザーのデータベースが均等に分散されています)。その後、一定時間非アクティブだったユーザーをタイムアウトにする必要があります。

    $c->update(array('session.lastLogged'=>array('$lt'=>$time - ($timeout*60))), array('$set' => array('session'=>'') ));

次のエラーが表示されます。

For non-multi updates, must have _id or full shard key ({ _id: "hashed" }) in query

ただし、クエリするIDがわからず、セッションデータが変更されるため、シャードキーとして機能できません

これは、データの構造またはクエリの問題ですか?

4

2 に答える 2

1

これは、MongoDB シャード クラスターの単なる制限です。セッションで_idを保持しないのはなぜですか? あるいは、ユーザーの userId/loginId をドキュメントの _id またはシャード キーとして使用することもできます。

于 2014-04-25T11:02:37.490 に答える
1

ただし、クエリするシャードをどのように知るかはわかりません。

ハッシュ_idインデックスの利点は、クエリ対象のシャードを知る必要がないことです。MongoDB はハッシュを使用して、ドキュメントをクラスター内のどこに配置するかを認識しますが、ドキュメントをクエリする方法は認識しません。

つまり、通常どおりにクエリを実行するObjectIdと、適切なシャードとそのシャード上の適切なドキュメントに自動的にルーティングされます。

次のエラーが表示されます。

上記の@helmyの回答で述べたように、_id制限のためにシャードキーまたはドキュメントのいずれかが必要です(基本的に、それ以外の方法で知ることができますか?)。

実際にはすべてのユーザーを更新しようとしているので、代わりに次を追加します。

array('multiple' => true)

あなたのクエリに。

ただし、スキャッター アンド ギャザー オペレーションを実行します。つまり、すべてのシャードにアクセスして結果を要求し、その結果に基づいて処理を行います。そこで思い当たることがあります。

于 2014-04-25T14:55:43.323 に答える