mongoDB에서 unique_id는 뭘로?
mongoDB를 사용하는 게시판은 게시글 id를 사용할 때 주로 _id (object_id)를 사용한다.
자체적으로 unique한 string을 만들어주기 때문인데, 이를 활용하면 별도의 auto_increment를 사용할 필요없이 unique한 id를 얻을 수 있게 된다.
데이터를 캐싱할 때 차지하는 용량은?
만약 이 데이터들을 캐싱해서 활용할 때 용량을 얼마나 차지할까?
_id: Object(id) 에서 사용하는 string은 12bytes 크기다.
게시글 하나당 id를 위한 데이터 12bytes를 차지할 것이고, 약 10만개 정도의 데이터를 캐싱했다고 해보자
120만 바이트, 약 1.2GB 정도를 차지하게 될 것이다. (1kb = 1000으로 단순계산한 값)
만약 내가 auto_increment를 활용해서 post_id를 생성한다고 할때 64bit integer를 사용한다면 8bytes를 차지할 것이다.
이 경우에는 같은 10만개의 데이터를 저장한다고 해도 80만 바이트, 약 0.8GB 정도 될 것이다.
각 게시물의 index의 크기가 12bytes : 8bytes 비율이므로 약 33%의 공간을 절약할 수 있게 된다.
캐싱되는 데이터량이 커지면 커질수록 공간효율이 증가할 것이다.
We don't know reasons why 10gen didn't encourage usage of auto-incremented IDs. It's speculation.
출처: stackoverflow
이 링크에 달린 답변을 읽어보면, mongoDB가 auto-increment를 구현하지 않는 이유는 object_id를 충분히 활용할 수 있기 때문이다 라고 하지만 정확한 근거없는 추측일 뿐이라고 한다.
동시에 수 많은 데이터를 캐싱해야할 때 object_id를 활용한 케이스는, auto-increment를 통한 id를 활용했을 때 보다 더 많은 용량을 잡아먹으므로 비효율적이라는 예시를 들어주기도 한다.
그럼 어떻게 하는게 좋을까?
mongoDB 에서의 auto-increment는 구현되어있지 않지만 그 이유를 임의로 추측하고, 있는 그대로 받아들여서 결국 비효율적인 DB운용을 하는 경우를 보았다.
하지만 마냥 나쁘다고는 할 수 없는게 auto-increment를 통해서 post_id를 지정하면 분산된 DB에서의 각각 auto-increment를 동기화시켜서 충돌이 발생하지 않도록 조율해야 한다.
이렇게 각각의 장단점이 있으니 내가 만들 서비스에서 어떤 측면이 더 중요한지를 파악하고 적절히 필요한 수단을 적용하는게 좋겠다.
오늘의 영단어
- cumbersome: 부담이 되는, 성가신
