mongodbのObjectIdを理解する

Posted in nosql on 3月8 th,2011 by kafka 0102 mongodbでサポートされているデータ型のうち,ObjectIdは独自の生成物であり,本稿では簡単に紹介する.
mongodbコレクションに格納されている各ドキュメントには、デフォルトのプライマリ・キーがあります.id、このプライマリ・キー名は固定されており、mongodbがサポートする任意のデータ型であり、デフォルトはObjectIdである.リレーショナル・データベースschema設計では、プライマリ・キーの多くは、一般的に使用されるintやlongなどの数値型であり、より一般的には、プライマリ・キーの値はデータベースによって自己増加され、このようなプライマリ・キーの数値の秩序性は、ある論理を示す場合もある.逆にmongodbは、設計当初から分散型ストレージシステムに位置していたため、自己増加プライマリ・キーをサポートしていなかった.現実の世界では,予測可能な時空に大量に応用するには分布式のmongodbは必要ないため,mongodbの自己増加主鍵法を実現する文章がネット上に大量に現れている.うん、私も前にこんなことをしたことがあります.
やはりObjectIdの詳細を見てみましょう.ObjectIdは,マシンにまたがる分散環境におけるグローバル一意のタイプとして設計され,長さは12バイトである.友达がつぶやいているかもしれませんが、これはintより2倍大きく、longよりもintが1つ増えているので、経済的ではありませんが、今のハードウェア構成では、多く出たバイトがシステムのボトルネックになる理由が難しいので、できるだけ安心して使用してください.ObjectIdの12バイトは、0−3の4バイトがタイムスタンプ(timestamp)、4−6の3バイトがマシンコード(machine)、7−8の2バイトがプロセスid(pid)、9−11がプログラム自己増加id(increment)で構成されている.Java driverのObjectIdの実装コードを見ることができます.

public
 class
 ObjectId implements
 Comparable<
ObjectId>
 , java.io
.Serializable

 
ObjectIdの構成については、1、ObjectIdがタイムスタンプで始まるため、近似的に秩序化されているため、_idのインデックス挿入効率は通常のインデックスよりずっと高い.2、ObjectIdの最初の9バイト(timestamp+machine+pid)は、異なるプロセスで生成されたObjectIdが重複しないことを保証し、その後の3バイトのincrementは、同じプロセスで生成されたObjectIdが重複しないことを保証するので、ObjectIdのグローバル一意性を疑う必要はありません.3、ObjectIdストレージは12バイトですが、読み取り可能に表現する必要がある場合は文字列に変換する必要があります.24バイト(1バイト当たり2バイトの16進数表現に変換)が必要です.この長さの文字列は、ある_を追跡すると、少し不快に見えます.idによるバグは、copy+pasteの殺し技が必要です.4、ObjectIdに初めて関わった友人が犯しやすい2つのエラー:1)クエリー時にdbのようなものを直接使用する.collection.find({_id:"xx"})式のコードは、結果としてどうしても存在する文書が見つからず、正しい書き方はdb.collection.find({_id:new ObjectId(“xx”)}).2)集合間に外部キーの関連付けがある場合も、24バイトのstringを直接使用せずに、外部キーをObjectIdタイプにする必要があります.mongodbとのCRUDコードを書く場合は、ObjectIdとstringの変換コードに注意する必要があります.5、ObjectIdの生成はアプリケーション側でもmongodb側でも可能であり、様々な言語のdriverはプログラム側でObjectIdを生成する方法を提供しているが、多くの人は手間を省いてmongodbに直接渡している.しかしmongodbの設計哲学から言えば、ObjectIdはクライアントによって生成されるべきである.結局、アプリケーション層はストレージ層よりも拡張しやすく、mongodbの挿入速度を向上させる.
 
原文:http://www.kafka0102.com/2011/03/435.html