서비스의 DB에서 사용 할 사용자 고유 아이디 만들기

서비스의 고유아이디를 만들기 위한 참고용 인스타그램 샤드키 만들기. http://interconnection.tistory.com/25 를 통해서 샤드키와 같은 사용자를 구분하는 고유형식의 아이디를 만드는 것을 보았습니다.

이 부분을 적용해서 우리가 만들고자하는 모바일을 활용한 서비스의 사용자를 구분하는 유일한 ID 키로 사용해보고자 합니다.

사용자를 구분하는 유일한 ID 키를 만드는 방법을 세웠습니다.

단계별로 진행을 하려고 합니다.

1) 현재 사용자를 구분하기 위해 필요한 것이 무엇인가? 와 같은 목적을 정리해야합니다.

2) 1) 과정에서 나온 사용자를 구분하기 위해 필요한 것들을 하나하나씩 분석합니다.

3) 부분부분을 구분하여서 bit를 할당합니다.

일단 단계라고 쓰긴 썼는데 너무 모호한 것 같아서 한번 하나하나씩 진행해 보겠습니다.

1) 현재 사용자를 구분하기 위해 필요한 것이 무엇인가?

- 유일한 사용자에 대한 아이디를 할당해야합니다. 적은 수의 bit를 가지고 사용자를 구분하기에는 한계가 있고 당장은 중복이 안될 수 있지만 언젠가는 사용자가 중복될 수 있는 가능성이 존재하지 않게 만들고 싶습니다.

- 사용자를 우리가 구현할 기능에 맞춰서 하나하나 구분하고 싶습니다. 예를 들면, 남자 여자라든지, 모바일 사용자, PC사용자, 테블릿 사용자 등 구분되어 질 수 있는 사용자를 원합니다.

- 나중에 확장이 될 수 있는 경우가 있으니 그 샤딩에 대한 논리적 물리적 구분이 가능하게끔 하고 싶습니다.

이렇게 ID key의 목적이 정의가 되었습니다.

2) 이제 하나 하나씩 1) 과정에서 제시된 것들을 분석해보겠습니다.

- 유일한 사용자에 대한 아이디를 할당해야합니다. 적은 수의 bit를 가지고 사용자를 구분하기에는 한계가 있고 당장은 중복이 안될 수 있지만 언젠가는 사용자가 중복될 수 있는 가능성이 존재하지 않게 만들고 싶습니다.

:: 유일한 사용자를 만드려고 한다면 여기서 필요한 아이디어는 시간 순입니다. 시간은 계속 지나기 때문에 생성 시간 순으로 다른 아이디를 할당해서 사용하려고 합니다. 시스템의 시간을 이용해서 아이디를 생성한다면 밀리세컨 단위까지 가능하기 때문에 1000분의 1초까지 가능하게 됩니다.

정확한 원리는 아이디 = 현재 시스템 시간 - 기준 시간(원하는 시간) 로 하려고 합니다.

이 정도의 속도라면 아무리 동시에 요청이 들어와도 시스템 레이턴시가 달라서라도 아이디는 중복이 발생할 확률이 아주 미미하게 됩니다.

아주 미미한 확률은 또한 생성시에 이미 그 아이디가 있는 지 확인을 통해서 없는 경우에 등록하는 형식으로 어플리케이션 단계에서 핸들링 합니다.

- 사용자를 우리가 구현할 기능에 맞춰서 하나하나 구분하고 싶습니다. 예를 들면, 남자 여자라든지, 모바일 사용자, PC사용자, 테블릿 사용자 등 구분되어 질 수 있는 사용자를 원합니다.

:: 구분해야할 서비스 사용자는 대략적으로 남자, 여자, 모바일, PC, 테블릿, 가게 등등 앞으로 구분해야할 부분들이 앞으로 많기때문에 넉넉히 구분을 정하는 것이 좋을 것으로 생각됩니다.

- 나중에 확장이 될 수 있는 경우가 있으니 그 샤딩에 대한 논리적 물리적 구분이 가능하게끔 하고 싶습니다.

:: 확장을 고려했기때문에 서버의 논리적 구분과 물리적 구분을 고려해야합니다. 논리적 구분은 상당히 많아 질수 있습니다. 물리적 구분은 상대적으로 그 수가 그렇게 많지 않습니다. 예를 들면 논리적 구분은 대략 천단위, 물리적 구분은 많아야 십단위를 넘을 수 없다라고 생각이 됩니다. 그래서 앞 1) 2) 단계에서 사용한 bits를 제외한 나머지 bit를 모두 할당하려고 합니다.

3) 1) 2) 단계에서 목적을 정의하고 분석한 것을 토대로 bit를 할당을 하는 작업을 하겠습니다.

- 시간으로 구분한다면 bit를 사용해서 내가 표현할 수 있는 시간이 어디까지인가 할당하는 작업이 필요로 합니다. 하나하나씩 수작업으로 계산을 해보겠습니다.

:: 대략적으로 2의 10승이 1024로 밀리세컨드 단위에서 1초정도를 표현한다고 하면 이런 원리로 지수승을 높여보는 작업을 진행합니다.

2의 11승= 2초, 2의 12승 4초, ... 이러한 원리로 진행을 하면 2의 20승은 17.47분 정도를 표현할 수 있고,  2의 30승은 298.26시간, 2의 40승은 34.86년을 표현할 수 있습니다.

생각 같아서는 bit를 1개 더 추가해서 70년을 표현가능하게 하고 싶지만, 적절하게 우리 서비스가 35년정도 살아있다고 가정하고,

40개의 bit를 유일한 id에 할당 하겠습니다. 깔끔하게 40bits=5bytes 로 사용할 수 있습니다.

- 이제 사용자의 기능에 맞춰 구분해보겠습니다.

:: 제가 조사한 현재로써는 추후를 고려하더라도 대략 18가지 구분이 가능하다고로 판단되어서 2의 5승인 32개가 맞다고 생각되어 5bits를 할당합니다.

- 그리고 마지막 확장에 대한 고려를 하기 위한 키는 아직 정확히 서비스에 대한 고려가 없기 때문에 빈부분으로 나누겠습니다.

* 결론

:: 결론적으로, 시간 순으로 유일한 ID를 만들기 위해서 40bits, 사용자를 기능제공에 대한 구분으로 나누기 위해서 5bits를 할당해서, 현재 45bits가 총합적으로 나왔습니다.

하지만 확장에 대한 구분 고려도 있어야 하기 때문에 bit가 더 필요한 것이 현재 결론입니다.

그래서 결론은 2의 배수의 고려를 했을때, 32bit와 64bit가 고려되어야 하는데,

현재 필요한 bit가 45개를 넘어갔기때문에 64bits가 적절하다고 결정하였고,

45bit는 할당이 되었고 나머지 19bits는 확장과 다른 목적을 위해서 idle상태로 두겠습니다.

총 64bits

0 : idle - 19bits

1 : 사용자 구분 - 5bits

2 : 유일한 아이디 - 40bits

(MSB) 0000000000000000000111112222222222222222222222222222222222222222 (LSB)

로 최종 구성 되었습니다.