With the alphabet (uppercase and lowercase) + numbers [a-zA-Z0-9]^5, 916,132,832 possible ways are issued using hashes.
The hash value obtained from the URL corresponds to the variable part of the shortened URL.
The hash function is designed in such a way that the hash value takes as unique a value as possible.
Nevertheless, if the length (information content) of the original string is not limited, conflicts may occur (i.e., the same hash value for different URLs).
There are several workarounds, one of which is to use the following value as the hash value
One of the workarounds is to use the next value as the hash value. “What if the next value is used?” is true, but hash functions are designed to scatter the values as much as possible when similar data is input, so that when a collision occurs, the next value is often free.
When creating a shortened URL, the process is as follows
1. From the URL string, create a hash value that fits into a 5-digit hexadecimal number (916,132,832).
2. Register the hash value and URL in a table with columns (the hash value column is the primary key).
3. If the URL is already registered in the table
a. If the URL has already been registered, the hash value is used.
b. If the URL is not registered, increase the hash value by one and try to register it.
To get the actual URL from a shortened URL, just look it up in a table.
RDBs are designed to speed up the process of identifying records from primary keys.
Since the process is done while looking for free space in the registration table, it will not run out of 916,132,832 until all of them are used up, but if there are many hash collisions, the performance will decrease.
However, this “performance” is only related to the registration of shortened URLs, and has no effect on the search process, so due to the nature of the service, it is sufficient until all 9.1 billion combinations are used up.
Even if the number is exhausted, the number of possible combinations can be increased by adding one more character or one more digit.
