길이 7자를 정했습니다. 이제 그 7자를 무엇으로 채울지 고릅니다. 방법이 셋이고 각각 다른 대가가 있습니다.
주소를 해시해 앞자리를 쓴다
원래 주소를 해시하고 앞 7자를 씁니다. 같은 주소면 같은 키가 나오므로 재사용이 저절로 됩니다.
문제는 다른 주소가 같은 앞자리를 낼 수 있다는 것입니다. 그러면 저장 전에 이미 있는지 확인해야 하고, 겹치면 뒤에 무언가를 붙여 다시 해시해야 합니다. 확인 왕복이 쓰기 경로에 붙습니다.
그리고 요구사항이 재사용을 요구하지 않으므로 이 방법의 장점을 쓰지 않습니다. 장점 없이 왕복만 남습니다.
번호를 문자로 바꾼다
7장에서 만든 유일한 번호를 62가지 문자로 바꿔 씁니다. 번호가 이미 유일하므로 키도 유일하고 확인이 필요 없습니다.
번호 1,000,000 을 62진법으로 바꾸면 4자
번호가 커지면 자릿수가 늘어난다
두 가지 대가가 있습니다. 번호가 순차적이면 다음 키를 추측할 수 있고, 초기에는 자릿수가 짧아 길이가 들쭉날쭉합니다. 앞자리를 채우면 길이는 고정되지만 추측은 더 쉬워집니다.
무작위로 뽑는다
7자를 무작위로 뽑습니다. 앞 단계에서 계산한 대로 사용률이 1퍼센트 미만이라 겹칠 일이 거의 없습니다.
| 항목 | 내용 |
|---|---|
| 추측 | 어렵다. 다음 값에 규칙이 없다 |
| 확인 | 필요하다. 다만 거의 한 번에 성공한다 |
| 길이 | 늘 7자로 고정된다 |
이 요구사항에서는 무작위를 고릅니다. 재사용을 포기했으므로 해시 방식의 장점이 없고, 추측 가능성이 남는 것보다 확인 한 번이 낫습니다.
번호 변환도 좋은 선택이 될 때
추측이 문제가 되지 않는 곳이라면 번호 변환이 더 좋습니다. 확인 왕복이 아예 없고, 키가 시간순으로 커져 저장소 삽입도 값쌉니다.
| 상황 | 맞는 방법 |
|---|---|
| 링크가 공개용이고 추측이 무해하다 | 번호 변환 |
| 링크에 접근 제한이 있다 | 무작위 |
| 같은 주소에 같은 키가 필요하다 | 해시 앞자리 |
요구사항이 방법을 정합니다. 세 방법 모두 실제로 쓰이고, 어느 것이 더 좋다고 말할 수 없습니다.
두 방법을 섞지 않는다
무작위와 번호 변환을 함께 쓰면 같은 키 공간에서 두 규칙이 돌아갑니다. 그러면 무작위로 뽑은 값이 번호 변환의 결과와 겹칠 수 있고, 어느 규칙이 그 키를 만들었는지 알 수 없어 문제를 찾기 어려워집니다.
섞어야 한다면 공간을 나눕니다. 예를 들어 첫 글자로 구분해 규칙마다 다른 영역을 쓰게 합니다.