objectID가 12 바이트에 저장되어 있고 샤드 키가 좋지 않은데 _id 대신 완전히 무작위로 int64 (8 바이트)를 사용하는 것이 좋지 않은지 스스로에게 묻습니다.MongoDB : _id에 int64 또는 ObjectID를 사용하는 것이 더 좋습니까?
내 생각에 무작위로 int64를 만들고 컬렉션에 아직없는 경우 (주로 의사 랜덤 생성기가 정상적으로 작동하지 않는지 확인),이 _id로 문서를 만든다. 그래서 우리는 8 바이트 만 사용하고 샤드 키에는 잘 작동합니다.
당신은 어떻게 생각합니까?
임의로 생성 된 번호를 고유 ID로 사용하지 마십시오. 고유 한 난수를 생성 할 수 없으므로 새 레코드를 삽입 할 때 항상 존재 여부를 확인해야합니다. 또 다른 명백한 이유는 int64에는 한계가 있기 때문입니다.
당신의 _id에 대한사용 ObjectId가, 그것은 그가 무엇인지, 또는 당신이 아주 좋은 이유가있는 경우,
여기를 참조하십시오 GUID를 사용하지 :
하지만 objectID는 샤드 키로 사용할 수 없기 때문에 메모리에 다른 인덱스가 있어야합니다 (객체 ID 해싱 어쩌면 해시) – loki
무작위로 생성 된 숫자로 다른 필드에 스탬프를 찍은 다음이를 샤드 키로 사용하십시오 정말로 원하거나 숫자가 아닌 문자를 포함하고 독특한 키를 생성하는 더 독특한 방법을 고안해야합니다. 샤드 키는 단일 필드 일 필요는 없으며 복합 샤드 키를 사용할 수 있습니다. 나는 당신의 _id에 임의의 숫자를 사용하지 않을 것입니다. 샤드 키에 대한 링크를 포함하도록 답변을 업데이트했습니다 – pieperu
@loki 샤드 키로 사용할 수는 있지만 매우 나쁜 것입니다. –
우수한 솔루션을 가지고있다 ObjectID() 및 처음 4 바이트를 ObjectID의 끝으로 이동합니다. 이 새로운 ObjectID는 절대적으로 유일하며 선형으로 증가하지 않기 때문에 샤드 키로 사용할 수 있습니다.
에서이 링크를 공유하는 이유는 어떤 종류의 오버 헤드입니다. '_id' 필드는 _anything_이 될 수 있습니다. 왜 주변을 뒤적 거리며 귀찮게합니까? UUID는 좋을 것입니다. –
하지만 uuid는 16 바이트입니까? 그건 중요하지 않아? – loki
내 의견으로는 이것이 설계상의 결정이며 왜 Shard에 ObjectID를 선택해야하는지 확신 할 수 없습니다. 샤딩이라는 개념이 부하에 퍼져 있습니다. 따라서 어느 분야가 설계에 부하를 분산시키는 지 이해할 수 있습니다. – Elyasin