3

MongoDBのObjectIDよりも親しみやすいID（つまり、Youtubeスタイル：/ posts / cxB6Ey6）が必要です。

スケーラビリティのために_idをObjectIDのままにしておくのが最善だと読んだので、2つの解決策について考えました。

1）各ドキュメントにインデックス付きのpostidフィールドを追加します

2）_idとpostidの間にマッピングコレクションを作成します

どちらの場合も、https：//github.com/dylang/shortidのようなものを使用して短いIDを生成し、生成中にデータベースにクエリを実行してIDが一意であることを確認します。（このquery-generate-insertは不可分操作である可能性がありますか？）

これらのソリューションはパフォーマンスに顕著な影響を及ぼしますか？

これを行うための最良の戦略は何ですか？

4

3 に答える 3

5

これを行う通常の方法は、一意の ID を base64 でエンコードすることですが、次のようになります。

インデックス付きの postid フィールドを各ドキュメントに追加する

あなたは間違いなくこの方法に行きたいです。2 つのうち、この方法は簡単に最もスケーラブルでパフォーマンスが高いと言えます。1 つは、短い URL の詳細を取得するのに 1 回の往復で済みますが、2 番目のオプションでは 2 回かかります。もう 1 つの考慮事項は、インデックスのオーバーヘッドの不足です。追加のコレクションを維持するのは簡単なことです。

ドキュメント内のフィールドも置き換えません。近い将来_id、デフォルトObjectIdが引き続き役立つ可能性があるからです。

したがって、これは、URL の短いコードの個別のフィールドとインデックス (一意のキー) に制限されます。

次のことは、すべての挿入の前にデータベースに一意性を照会することを強制する ID が必要ないことです。これがObjectId輝くところです。は、データベース内で一意でありながら、クライアント アプリケーション内で作成するのObjectIdが得意であり、これらの仮定を具体的に照会する必要はありません。

最初にデータベースにクエリを実行する必要のない一意の ID は、通常、時間ベースです。PHP ( http://php.net/manual/en/function.uniqid.php ) と MongoDB ドライバー ( http://docs.mongodb.org/manual/core/object-id/ ) で、さらにはプラグインで-github ( https://github.com/dylang/shortid/blob/master/lib/shortid.js#L50 ) にリンクした場合、それらはすべて一意であるための基礎として時間を使用します。

リンクしたプラグインがデータベースにクエリを実行して独自のIDの一意性を確認しないことを考えると、このプラグインはおそらく非常にパフォーマンスが高く、最初のソリューションで使用する場合、それから良いベンチマークを取得する必要があると言えます.

于 2013-01-05T16:16:37.847 に答える
3

ObjectIDbuild-inをカスタムのユーザーフレンドリーな短い IDに置き換えたい場合は、それを行ってください。組み込みフィールドを使用するか、カスタム ID 用に_id新しい一意のインデックス付きフィールドを追加できます。idビルドインを使用する利点はObjectID、データベースが非常に大きい場合でも重複しないことです。したがって、それらを短いIDに置き換えると、IDが重複するリスクがあります。

次に、パフォーマンスについて。IDの長さを適切に調整すると、重複の可能性が非常に小さくなるため、DBにIDを照会しないことが最善の解決策だと思います。したがって、このモデルで ID の重複を処理する最善の方法は、Mongo の応答を確認することです。「重複キーエラー」で応答した場合は、新しいキーを生成する必要があります。

そして今、スケーリングについて。カスタム ID をスケーリングするには、さらにいくつかのシンボルを追加するだけです。「重複キーエラー」は、その変更を行うトリガーとなります。通常、このようなエラーは発生しません。したがって、それらが表示され始めた場合は、スケーリングする時が来ました。

于 2013-01-05T09:57:06.657 に答える
1

ObjectIdフィールド用に生成することは、_idスケーラビリティやパフォーマンスに直接影響するとは思いません。それによってこれが起こる可能性がありますか？

主な違いは、ObjectIdはMongoDBによって作成され、これに対する責任を自分に負わせないことです。_idそれ以外の場合は、IDの最適なサイズを決定し、コレクションに格納されているドキュメントの各フィールドに一意の値を確保する必要があります。_id主キーとして使用されるため、必須です。これは、コレクションがそれほど大きくなく、識別子のカスタム値が必要な場合に正当化できます。

_idただし、ObjectId値を格納するフィールドには、時間からオブジェクトIDを作成し、このファクトをクエリで有利に使用する機会など、追加の利点があります。また、 getTimestamp（）メソッドを使用してObjectIdの作成のタイムスタンプを取得できます。この場合の並べ替え_idは、作成時間による並べ替えと同じです。

ただし、URLまたはHTMLでObjectIdを使用する場合は、セキュリティ上の懸念から暗号化できます。情報の漏洩やオブジェクトの作成時間へのアクセスを防ぐため。セキュリティ上のリスクがある可能性があります。

ソリューションについて：

1）これは非常に便利で柔軟なソリューションだと思います。この場合、postIdに直接依存しない任意の値を指定できます_id。

ただし、このソリューションのほとんどの欠点は、追加のフィールドが必要であり、追加のインデックスを作成する必要があることです。_id自動的にインデックスが作成されます。

2）パフォーマンスとnoSQLアプローチの哲学の観点から、これは良い解決策ではないと思います。

于 2013-01-05T15:52:12.380 に答える