로컬 UUID 대 네트워크 고유 카운터 ID

Question

대리 키 구현으로 어떤 것을 선택 하시겠습니까?

• 지역 UUID 응용 프로그램에서 로컬로 생성
  • , 어떤 네트워크 여행 그것을
  • 를 검색 없습니다하지만 길이가 길고 스토리지 크기를 사용
  • 길고 URL의 크기에 영향을 미칠 수 긴 UUID
  • UUID 충돌이 일어날 것을 가장 작은 두려움
• 또는 .. 네트워크 고유-counte R 아이디 나는 $ INC
• 훨씬 짧은 네트워크 여행의 비용으로 원자 INC 또는 몽고와 원격 레디 스 상상
  • (이에 대한 적절한 용어는 무엇인지에 대한 확실하지가) 덜 차지 심지어 클러스터 응용 프로그램에 낮은 동시성 앱

Answer 1

공간 및 훨씬 더 짧은 URL

충돌에 대한 두려움의 결과는, 당신은 아마 네트워크 카운터 ID를 사용할 수 있습니다. 그러나 url을 제외하고 낮은 동시성 (= 많은 데이터가 아님)에는 관심이 없습니다.

많은 동시 데이터 액세스의 경우 데이터가 너무 많으므로 클러스터를 많이 사용하면 엔진 + 관련 네트워크가 빨라집니다.

결론 : - 네트워크 카운터는 섹시하지만 쓸모없는 것 같습니다. 내 의견으로는, MongoDB입니다.

MongoDB 충돌시 생성 알고리즘으로 인해 충돌이 거의 없습니다. uuid의 일부분은기계 주소로 빌드되며 고유해야하며 클러스터를 생산하기 전에이 주소를 얻을 수 있습니다. 당신이 MongoDB를를 사용하는 경우

Answer 2

, 당신은 BSON하며 Object를 사용하여 조사한다 :

http://www.mongodb.org/display/DOCS/Object+IDs

별도로 지정하고 _id 필드를 직접 작성하지 않는 한 그들은 _id 필드와 기본적으로 생성됩니다 ( 하는 수도 있습니다 그냥 당신이 만든 ObjectID가 되십시오). 충돌에 대한 두려움이 없으며 응용 프로그램에서 사용할 수있는 DB에 기본적으로 지원되는 ID 유형을 얻을 수 있습니다. 물론 MongoDB를 사용한다면 win-win처럼 보일 것입니다.)

Answer 3

두 가지 방법을 결합 할 수 있습니다. 트위터의 SnowFlake 알고리즘을 찾아보십시오. 이 알고리즘은 전역 고유 정수 (64 비트)를 생성하지만 조정이 없으면 순수 로컬 앨트토리입니다.