OBJECTID는 12 바이트, 4 개의 구성 요소 타임 스탬프 + machash + PID + INC
_id 내에서 기본의 MongoDB를 수집 독특합니다. 이 독특한 보장 할 수있는 문서에 삽입 할 때 고객은 자동으로 생성 _id 드라이버에 의존?
자동 OBJECTID의 고유성
자동으로 생성 된 몽고 데몬이 생성되지 않지만 드라이버 생성합니다.
mongoshell 및 javaclient 클라이언트가 OBJECTID 생성되어보고 실험에서 발견 OBJECTID 생성 아무 소용이 서버 측이 없습니다. 프로세스의 시작에 임의의 값이 전반적인 상황을 결정하기 때문에 즉, 마지막 세 바이트는 항상 연속 같은 클라이언트 프로세스를 생성 찾을 수 업-에 따라, 그리고 서버 측의 일반적인 서비스까지 긴 시간 동안 실행, 서버 측 이후 인 경우 여러 클라이언트가 제공 OBJECTID 경우 접미사는 연속되지 않을 수도 있습니다,하지만 사실은 연속이다.
분명히 컴퓨터 이름 + pid는 동일 할 수 독특하고 서로 다른 시스템의 MAC 주소를 OBJECTID 보장하지 않습니다 밖으로 해시이지만, 가능성이 상대적으로 작다, 현재 프로세스의 ID가 갈등의 해시 될 수있다, 가능성은 상대적으로 낮다 이러한 임의의 값으로부터 임의의 값으로 로딩 시간이 현재 프로세스의 ObjectId가 다른 프로세스의 증가 값은 건너 발생할 수 시간 동안, 카운트 업되지만 가능성은 매우 낮다.
충돌이 발생하는 경우에, 당신은 일반적으로 단지에이 드라이버의 표준 사용을 따르 개 이상의 치수 작은 동시 발생의 가능성이 있지만,이 충돌의 가능성 때문에 최소한의 필요합니다.
이 알고리즘 드라이버가 UUID의 구현으로 볼 수 사실, ID는 항상 고유의 전체 타임 라인에 여러 클라이언트에서 생성됩니다. 방법 ID 발생기 그래서 서버는 유지 보수가 필요하지 않습니다.
자동 OBJECTID 저장 시간을 추가 DB 때 OBJECTID가있는 경우, 기존의 삽입이 실패합니다. 이 이유없는 문서의 확률이 매우 작은 경우, 일반적으로 응용 프로그램 계층 삽입 아이디 충돌이 발생합니다 생각하지 않습니다.
왜 ID와 UUID 좋은 증분 정수보다 OBJECTID?
동시 삽입에 영향을 미칠 수밖에 정수 단위로는, 여러 클라이언트가 가장 최근의 ID를 알 수없는 경우, 모두의 고유성은 서비스 측면, 순서는 문서의 삽입을 처리 할 수 있도록합니다. 용액으로서 구성 MySQL의 증분 단계가 있지만 ID 생성 다중 작업 기계 부하 분산 유연하지 않다. OBJECTID 모든 구동 본질적 고유 보장이 사양에 따라 생성 objectID에 12 바이트로 구성된다.
ObjectId가 UUID 다른 구현으로 볼 수있다.