Mongodb : 컬렉션 내의 짧은 기본 키로 사용되는 개체 ID

Question

MOngoDB에서 생성하는 objectId를보다 잘 활용하는 방법. 나는 전문적인 사용자는 아니지만, 지금까지 나는 객체 ID (userid, postid) 등을 위해 별도의 ID를 만드는 것을 끝냈다. 왜냐하면 객체 ID가 너무 길어서 주 ID로 사용한다면 URL이 추악 해지기 때문이다. 색인 생성 등을 돕기 위해 _id 그대로 유지합니다. 더 나은 전략에 대해 궁금해서, 친숙하고 쉽게 기억할 수있는 열쇠로 mongo objectId를 사용할 수 있습니다. 나는 열쇠가 날짜 등의 조합 이었기 때문에 부품의 어떤 것도이 목적을 위해 컬렉션 내에서 유일하게 사용될 수 있도록 읽었다.

덕분에,
BSR/

Answer 1

는, 그것은 당신이 가지고있는 하나 _id를 오버라이드 (override) 할 수 있도록 완벽하게 OK입니다. 그것으로 _id 그대로 기본적으로 인덱싱 등

MongoDB를 인덱스에게 _id 필드를 도와 keeo

.... _id 필드에 정수를 넣기 시작하면 다른 모든 것과 마찬가지로 색인이 생성됩니다.

그래서 대부분의 RDBM은 "자동 증가"ID를 제공합니다. 작은 데이터 세트에는 좋지만 확장 성 측면에서는 좋지 않습니다. 한 번에 20 대의 서버에 데이터를 삽입하려는 경우 어떻게 "자동 증가"를 그대로 유지합니까?

정상적인 대답은 그렇지 않다는 것입니다. 대신, 그 ID에 대한 GUID와 같은 것을 사용하게됩니다. MongoDB의 경우 ObjectId가 이미 제공됩니다. 하나의 키를 기억하기 위해 더 많은 URL을 친절하고 쉬운으로 몽고 OBJECTID을 사용할 수 있도록

내가 더 나은 전략에 대해 궁금

그래서 여기에 문제는 ID하지 않습니다 "기억하기 쉬운" 실제로 "고도로 확장 가능한 데이터베이스"와 맞물린 다. 10 억 개의 문서가있을 때 ID는 실제로 "기억하기 쉽지 않습니다".

여기에서 절충해야합니다. 테이블 크기가 커질 경우 ObjectId를 사용하는 것이 좋습니다. 상대적으로 작고 자주 업데이트되지 않는 테이블 (예 : "조회"테이블)이 있으면 자체 증가를 구축 할 수 있습니다.

정말 선택해야합니다.

Answer 2

당신은 _id 직접를 덮어 쓸 수 있습니다. 자동 생성 객체 ID를 사용할 의무는 없습니다. 자신의 필요에 따라 앱 내부에서 _id를 재정의하는 문제는 무엇입니까? 당신이 기존 ID를 (기존 데이터가 설정에서 말)이 경우