반응형

데이터베이스를 Scale Out으로 구성하는 경우, auto increment sequence값에 대해 고민을 하게 된다.

 

다음과 같은 시도를 해보았다.

 

1. Unique idx 발급용 Redis를 별도로 두어, increment 명령어만 호출하여 사용한다.

  - 개발환경에서는 잘 사용하고 있었지만, SPOF 이슈가 있고, 별도 머신 세팅을 해야하므로 관리 이슈가 따름. (fail) 

 

2. java 내부에서 제공하는 UUID를 이용하여 randomString을 추출해낸다.

  - 겹칠 확률이 없다고 봐도 되고, 로직에서 처리하는 것이기 때문에 1번보다는 성능이 좋지만, 보통 DB에서 사용하는 unique idx는 long타입인데, 얘는 String타입으로 리턴해준다. 물론, long형태로 리턴해주는 메소드도 있어서 사용해봤고, 어느정보 겹칠 확률도 없었지만.. 좀 껄끄러워서 패스 (fail) 

 

3. 구글링을 하던 중 누군가 Github에 snowflake에서 unique idx발급 시 사용하는 알고리즘을 올려두었다. (트위터에서 올린건지는 모름;;)  

  - 전체적인 로직을 보진 않았지만, timestamp값을 가지고 or연산 등을 이용하여 생성해내는 방식인 것 같다. 이것도 unique idx를 generate하는 메소드는 string형태로 리턴이 되는 구조였지만, 내부적으로 Long으로 만든 후에 toString하는 방식이어서 toString만 없애고, 어느정도 맞게 수정해서 사용. 트위터에서 사용하고 있는 알고리즘이므로 믿고 사용하기로 결정.

링크 : https://github.com/Predictor/javasnowflake  

※ long id generate하는 부분 중에, hardWareAddress 가져오는 코드가 있는데, 이거 centOS에서 잘 안가져와 지는 것 같다. windows에서는 잘되는데, 왜 안되지 찾다가 보니 null을 반환했었다는.... 이럴 경우 getHardWareAddress()를 사용하면 안되고, Iterable한 형태로 리턴해주는 method를 이용하면 해결이 된다. (본인은 귀찮아서, null일 경우 로컬에서 한번 받아온 hardWareAddress를 세팅하도록 변경해서 사용중;; 어차피 중복 확률이 0%니깐 상관없을거 같아서..) 

 

nosql을 주 Storage로 사용하는 경우 2번의 방법도 괜찮다고 한다. 

반응형
,