couchdb文書では、自動生成されたIDまたは手動IDの割り当てはどれが良いですか？

Question

CouchDBでドキュメントのIDを生成する必要がありますか、それを生成するにはCouchDBに依存する必要がありますか？これらのアプローチのメリットとデメリットは何ですか？これらのオプションにパフォーマンス上の影響はありますか？

Answer 1

CouchDBに関する限り、違いはありません。 Frederickは、順次IDがわずかに速いことは間違いありません。 /_uuids?count=10を照会すると、UUIDが順次（デフォルト）であることがわかります。

しかし、ランダムIDを使用しても、圧縮を実行すると、すべてが.couchファイルの内部で「正しい」順序になり、その時点で違いはありません。だから、長期的には、私は通常それについて心配していません。

Answer 2

主な点は、主に順次IDを使用することです。 this articleとcouchdb bookのこのビットは説明しているように、ランダムIDを使用すると、内部的には効率が非常に低い構造になります。スピードもディスク上のスペースも同じです。

Answer 3

あなたのアプリを2つ以上の別々のインスタンスに分けた場合、自己生成IDはほとんど処理できません。異なるインスタンス間の同期は瞬間的ではないためです。このための解決策は、SQLデータベースを使用するなど、IDの生成（または利用可能性の確認）専用のサーバーを1つ作成し、文書作成のゲートとして機能させることです。

一方、サーバーが1つしかなく、これ以上必要ない場合は、自己生成uidに興味があるという利点が1つあります。一意でなければならないため、URLで使用できます。たとえば、ブログ投稿のタイトルのスラッグを_idとします。

パフォーマンス面では、CouchDBの生成されたIDはかなり長いので、独自のIDが短ければ、かなりのディスクスペースを節約できます（ドキュメントが不足していると仮定します）。

Answer 4

上記の両方の回答は、順次IDのPROSについて説明しています。 ここでは、順次IDによって発生する大きな問題があります。

単一のIDを使用するドキュメント内の他のIDの予測可能性。

このため、我々は、他のIDが1つのIDを使用して、予測可能であること、およびURLの認証も可能ではないとして使用。（ファイル共有サービスによって行われたよう）に識別子としてアプリケーションURL内の連番IDを使用することはできません。