예를 들어 Youtube를 사용하고 싶습니다. 이들은 형식으로 ID를 사용합니다 PEckzwggd78.

왜 간단한 정수를 사용하지 않습니까?

또는 imgur.com- 9b6tMZS이미지 및 갤러리와 같은 ID도 사용합니다 . 순차 정수가 아닙니다.

• 왜 정수 (특히 순차 정수)를 사용하지 않습니까?

• 어떤 경우 에 정수 대신 그러한 문자열 ID를 사용하는 것이 현명한 결정입니까?

YouTube는 다음과 같은 두 가지 이유로 순서 ID를 사용할 수 없습니다.

1. 데이터베이스는 거의 확실하게 배포되어 순차 번호 매기기가 복잡합니다.

2. 개인 정보 보호 옵션 '비공개 동영상'이 있습니다. 검색 결과에 표시되지 않지만 ID를 알고있는 경우 사용할 수 있습니다.

따라서 비디오 ID는 합리적으로 임의적이고 예측할 수 없어야합니다. ID가 숫자로만 표시되는지 문자와 숫자의 조합으로 표시되는지는 관계가 없습니다. 한 표현에서 다른 표현으로의 사소한 매핑이 있습니다.

• ID의 형식에 : 그들은 Base64로를 사용하고 (문자를 사용하여 a- z, A- Z, 0- 9, -및 _). 따라서 문자 당 6 비트의 정보를 가질 수 있습니다. YouTube는 11 자 동영상 ID를 사용하므로 2 ^{6 * 11} 또는 7 * 10 ¹⁹ 개 이상의 ID를 생성 할 수 있습니다 . 으로 톰 스콧 넣어 , 그 "주위 18,000년에 대한 비디오를 매 순간을 업로드 지구상의 모든 단일 인간만큼."입니다 64는 2의 거듭 제곱이므로 모든 문자가 정확한 비트 수를 나타내므로 Base64도 쉽게 작업 할 수 있습니다. 같은 이유로 16 진법 (16 진법)을 사용합니다.

• ID의 비 순차적 특성 : ID를 비디오에 할당하는 모든 서버간에 동기화 된 카운터가 필요하지 않음을 의미합니다. 그들은 임의의 숫자를 생성하고 이미 사용중인지 확인하고 거기에서 갈 수 있습니다. 또한 각 서버에 ID 블록을 할당하여 중복 검사를 선택하지 않아도됩니다. 그들이 그렇게하고 있는지 모르겠지만 그들은 할 수있었습니다.

• 비 순차 ID의 또 다른 이유는 "비공개"비디오가 작동하기 때문입니다. 검색 결과 나 제안으로 표시되지 않지만 링크가 있으면 액세스 할 수있는 동영상입니다. 순차적 계산을 사용하는 경우 동영상으로 이동하여 ID를 1 씩 늘리면 미등록 동영상에 대한 아이디어가 깨집니다.

• 비 순차 ID는 또한 총 비디오 수 또는 시간당 업로드 된 비디오 수와 같은 경쟁 업체의 정보를 숨기는 데 도움이됩니다.

Tom Scott의 비디오를 강력히 추천 할 수 있습니다 . 그의 정보는 거의 항상 재미 있고 정확합니다.

• 정수는 그 정도를 잘 확장하지 못합니다. "정상"32 비트 부호없는 정수는 40 억을 초과 할 것입니다.

• 그들은 당신이 얼마나 많은 아이템을 온라인에 가지고 있는지 또는 그들이 증가하고있는 비율을 추적하기를 원하지 않을 수도 있습니다.

• 문자는 숫자보다 많은 정보를 보유 할 수 있으므로 동일한 "숫자"를 표현하기 위해 더 적은 문자가 필요합니다. 큰 인덱서 데이터베이스의 경우 이것이 더해질 수 있습니다.

1) 일부 웹 사이트는 왜 ID에 문자를 사용합니까? 그들은 끈입니까?

이러한 웹 사이트가 데이터베이스에 ID를 문자열로 저장하는지 여부는 알 수 없습니다. 숫자와 문자열은 컴퓨터와 동일합니다. 문자열은 숫자 일 뿐이며 다른 밑줄로 표시됩니다. 'A' = 0x41 = 65 = 0b1000001, 컴퓨터는 모두 동일합니다. 그러나 표시하면 기본이 클수록 표현이 짧아지고 URL이 더 짧아서 쉽게 읽고 공유 할 수 있습니다. YouTube 및 Imgur와 같은 사이트는 기본 62 자 (문자, 대소 문자 및 숫자를 더한 숫자) 이상 (대시 또는 기타 유효한 URL 문자 추가)을 사용하므로 숫자가 비교적 짧습니다. 당신은 무엇을 사용하는 것을 선호 것 youtu.be/23489234892348234933나 youtu.be/B9k6KMrv8vh?

2) 왜 비 순차 ID가 사용됩니까?

IMil의 대답은 다음과 같이 잘 설명합니다.

YouTube는 다음과 같은 두 가지 이유로 순서 ID를 사용할 수 없습니다.

• 데이터베이스는 거의 확실하게 배포되어 순차 번호 매기기가 복잡합니다.

• 개인 정보 보호 옵션 '비공개 동영상'이 있습니다. 검색 결과에 표시되지 않지만 ID를 알고있는 경우 사용할 수 있습니다.

또한 ID가 너무 큰 이유도 설명합니다 (YouTube는 23,489,234,892,348,234,933 개의 다른 동영상을 호스팅하지 않습니다)

• ID를 생성 할 때 실수로 동일한 ID를 두 번 생성하면 문제가되므로 생일 문제 를 방지하기 위해 큰 ID 공간이 필요합니다.

• 동영상에 유효한 유효한 ID가 사용될 가능성이 그다지 크지 않으면 사람들은 미등록 동영상의 URL을 추측 할 수 있습니다.

왜 정수, 특히 순차적 정수가 아닌가? 그리고 어떤 경우에 정수 대신 그러한 문자열 ID를 현명하게 결정합니까?

• 더 나은 UTF-8 공간-숫자를 문자열로 바꿀 때 문자 당 최대 10 조합 (0-9)을 얻지 만 알파벳 숫자 문자를 허용하면 문자 당 62 조합 (az, AZ, 0-9)을 얻습니다 )이므로 영숫자 문자열을 사용하면 숫자 문자열을 사용하는 경우보다 더 짧은 URL을 생성 할 수 있습니다. 이는 사용자가 Youtube 및 Imgur와 같이 URL을 공유하는 사이트에 중요합니다.
• 순차 정수는 생성하기가 더 어렵습니다. 순차적으로 증가하는 정수를 생성하려면 단일 스레드에서 숫자를 생성하거나 분산 시스템에서 많은 호스트를 조정해야하며, 임의로 생성 된 문자열만큼 확장 할 수없는 Youtube 또는 Imgur와 같은 대량 응용 프로그램을 실행할 때 (그들이 그 말을하지 되어 무작위로 생성)

따로, 내부 표현 이 문자열 인 경우는 아닙니다 . 숫자 식별자를 짧은 URL의 영숫자 문자열로 인코딩했을 가능성이 큽니다.

당신이 지적했듯이, 숫자 만 사용하면 보편적으로 고유 한 ID를 사용하는 것이 쉬울 것입니다. 왜냐하면 후드 아래의 모든 것이 정당 0하고 1128 비트 이상으로 더 정밀하게 숫자를 확장 할 수 있기 때문 입니다.

주된 이유는 uint32(예를 들어) 와 같은 임의의 고정 범위를 가정 할 때 문자를 사용하면 총 ID가 더 짧을 수 있기 때문입니다.

URL의 미학적 이유라고 생각합니다. 대신 갖는 4,129,873,773문자로 훨씬 짧다 Fu837t(내게로 단지 fictious 만든). 사용자는 URL을 친구에게 제공하기 위해 URL을 기억할 수도 있습니다. Youtube 와 같은 플랫폼은 일반적으로 공간이 부족하기 때문에 32 비트보다 긴 UUID를 갖습니다.

짧은 URL은 연결 및 공유가 더 간단 해 지므로 바람직합니다 (예 : SMS에서 링크를 공유 할 수 있고 입력 속도가 더 빠름). Youtube 또는 Imgurl와 같은 서비스는 URL을 부담없이 공유하기를 원하므로 중요한 고려 사항입니다.

숫자 대신 영숫자 ID를 사용하면 동일한 비트 크기의 ID를 표현하기 위해 더 적은 문자가 필요합니다. 예를 들어 6 자리 숫자는 백만개의 고유 ID를 제공하지만 6 개의 영숫자 문자 (base64 세트 사용)는 680 억 개의 고유 식별자를 제공합니다 .

우리가 아는 한, 영숫자 식별자는 base64와 같은 영숫자 형식으로 인코딩 된 순차적 숫자 일 수 있습니다. 그러나 종종 상용 서비스는 사람들이 ID를 추측하지 못하도록하고 고객 수와 같은 비즈니스 정보를 공개하지 않도록하기 위해 순차적 코드를 피합니다.

숫자가 아닌 ID를 사용하는 데는 몇 가지 이유가 있지만 알파벳 문자가있는 모든 값이 실제로 문자열이 아님을 이해해야합니다. YouTube는 1 분마다 300 시간 분량의 비디오를 업로드하는 엄청난 수의 비디오로 유명합니다 ( ref ). 해당 비디오를 나타내는 고유 정수는 상당히 길어질 수 있으므로 Base64 URL 인코딩 숫자 ( ref ) 와 같은 것을 사용하십시오 .

식별자 표현의 유형 :

• 단순 정수 : (12345, 981027489382493)
• 기본 16 개의 정수 : 123456789abcdef-16 진수라고도 함
• 기본 64 정수 : 9b6tMZS
• 읽을 수있는 문자열 : 12032017-Read-my-awesome-article-01

그들은 모두 장단점이 있습니다. 식별자에 사용할 수있는 고유 문자가 많을수록 숫자를 나타내는 문자 수가 적어집니다. 기본 64 숫자는 URL에서 작동하고 숫자 6에서 8 (즉, 3/4 크기)을 나타내는 데 필요한 문자 수를 압축하는 기존 변형이 있기 때문에 상당히 타협됩니다.

읽을 수있는 문자열은 검색 가능성을 높일 수 있기 때문에 블로그에서 작동하며 레코드 수가 적을 때 고유 한 제목을 생성하는 것이 훨씬 쉽습니다.

컨텐츠 해시

"해시"라는 단어는 기존의 멋진 답변에서 찾을 수 없으므로 여기로 이동합니다.

종종 독립적 인 인공 ID 대신 콘텐츠 해시로 데이터를 식별 할 수 있습니다. 이는 git콘텐츠 해시를 사용하는 이러한 특정 속성이 데이터를 더 쉽게 만들 수있을뿐만 아니라 (예 : 중복 제거) 사소한 캐싱, 보안 기록, 비트 썩음 감지와 같은 다른 멋진 속성도있는 ZFS 와 같은 소프트웨어 또는 파일 시스템 에서 특히 분명 합니다. 기타

해시는 일반적으로 16 진수 (또는 더 큰 문자 공간)로 제공되므로 정수 ID가 표시되지 않습니다. 단순히 정수 가 없습니다 (이 경우).

데이터 객체를 변경할 수없는 경우 해시가 좋습니다 (ZFS 또는와 같이 git). 예를 들어 큰 CDN에 이미지를 저장하는 것이 좋습니다. 나는 그 특정 ID를 실제로 여부를 알 수없는 입니다 해시,하지만 확실히 나을 (마이클 Kjörling가 주석으로, 짧은 ID를 분명한 이유 해시 아마되지 않습니다 - 비교로는, 자식은 20 바이트 또는 40이다 SHA-1 값을 사용 16 진수).

그 이유 중 하나는 문자가 정수가 아닌 문자로 전송되기 때문입니다. 이것은 HTTP Get의 작동 방식 때문입니다.

"정수를 사용하지 않는 이유는 무엇입니까?" 그러면 정수가 잘리고 모든 숫자가 문자로 보내지고 어쨌든 문자열로 끝납니다. 캐릭터에 대한 모든 옵션을 사용하지 않는 이유는 무엇입니까?

인적 요소도 있습니다.

예를 들어 imgur를 사용하십시오 : https://imgur.com/ ***** / s6UqP

s6UqP,

모든 문자의 범위는 a-z 대문자, a-z 하위 대문자 및 문자열의 모든 위치에 대한 0-9 = 26+ 26+ 10 = 62 옵션입니다. 916132832 개의 가능한 조합 인 5 개의 포지션이 있습니다. 숫자 만 사용하려면 9 자리가 필요합니다.

사람들은 대략 7 개의 객체를 메모리에 담을 수 있고, 9 자리는 너무 많으며 5자는 가능합니다.

마법의 숫자 7