사실 원리를 분석하면 답을 쉽게 얻을 수 있습니다. 당신의 손에 아래와 같이 1부터 100까지의 숫자 더미가 있다고 가정해 보겠습니다.
한 남자가 와서 전화번호를 달라고 하면 당신이 그 사람에게 전화번호를 주면 문제가 되지 않습니다.
두 분이 함께 오셨는데 둘 다 번호를 물어보셨어요. 천천히 하나씩 오고, 하나씩 보내고, 천천히 가도 도착할 거예요
10명이 동시에 와서 번호를 물어보면 100명은 어떨까요?
동시 요청으로 오는 사람의 수를 상상해 보면, 빠른 번호 할당이 병목 현상이 된다는 것을 어렵지 않게 발견할 수 있습니다. 따라서 자체 증가 ID는 실제로 RDBMS에 좋지 않습니다. 하지만 다행스럽게도 기존 데이터베이스는 자체적으로 잠금을 추가하여 메모리 경쟁을 처리하므로 큰 문제는 없습니다. MongoDB는 분산 데이터베이스입니다. 여러 시스템이 서로 조정해야 합니다. 당신은 1을 얻고, 나는 2를 얻고, 그는 3을 얻습니다. 이 잠금은 네트워크를 통해 조정되어야 하는데 이는 매우 비효율적입니다. 배포의 목적 중 하나는 동시성을 향상시키는 것이므로 자동 증가 ID와 높은 동시성은 실제로 서로 상반됩니다. 분산 환경에서는 올바른 증분을 보장하는 것이 필연적으로 효율성에 영향을 미칩니다. 게다가 자체증가형 ID는 실제로 보기에 깔끔하다는 점 외에는 별 장점이 없어 부득이하게 폐기하게 되었습니다. (ObjectID는 실제로 정렬이 가능하다는 점, 즉 삽입 시간 순서를 기억하세요)
사실 원리를 분석하면 답을 쉽게 얻을 수 있습니다. 당신의 손에 아래와 같이 1부터 100까지의 숫자 더미가 있다고 가정해 보겠습니다.
한 남자가 와서 전화번호를 달라고 하면 당신이 그 사람에게 전화번호를 주면 문제가 되지 않습니다.
두 분이 함께 오셨는데 둘 다 번호를 물어보셨어요. 천천히 하나씩 오고, 하나씩 보내고, 천천히 가도 도착할 거예요
10명이 동시에 와서 번호를 물어보면 100명은 어떨까요?
동시 요청으로 오는 사람의 수를 상상해 보면, 빠른 번호 할당이 병목 현상이 된다는 것을 어렵지 않게 발견할 수 있습니다. 따라서 자체 증가 ID는 실제로 RDBMS에 좋지 않습니다. 하지만 다행스럽게도 기존 데이터베이스는 자체적으로 잠금을 추가하여 메모리 경쟁을 처리하므로 큰 문제는 없습니다. MongoDB는 분산 데이터베이스입니다. 여러 시스템이 서로 조정해야 합니다. 당신은 1을 얻고, 나는 2를 얻고, 그는 3을 얻습니다. 이 잠금은 네트워크를 통해 조정되어야 하는데 이는 매우 비효율적입니다.
배포의 목적 중 하나는 동시성을 향상시키는 것이므로 자동 증가 ID와 높은 동시성은 실제로 서로 상반됩니다. 분산 환경에서는 올바른 증분을 보장하는 것이 필연적으로 효율성에 영향을 미칩니다. 게다가 자체증가형 ID는 실제로 보기에 깔끔하다는 점 외에는 별 장점이 없어 부득이하게 폐기하게 되었습니다. (ObjectID는 실제로 정렬이 가능하다는 점, 즉 삽입 시간 순서를 기억하세요)
https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field/#considerations