데이터베이스를 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번의 방법도 괜찮다고 한다.
'개발 > Java' 카테고리의 다른 글
[Java] Primitive Type과 Reference Type의 메모리 (0) | 2016.06.10 |
---|---|
[Gson] TypeAdapter (0) | 2016.06.10 |
[Eclipse] MoonRise Theme (0) | 2016.06.10 |
[Eclipse] Check for Updates에서 Repository를 못찾고 에러가 발생하는 경우 (0) | 2016.06.10 |
[Lambda] collect 함수 사용 시 주의점 (0) | 2016.06.10 |