tiny_id
tiny_id is a Rust library for generating non-sequential, tightly-packed short IDs.
Most other short ID generators just string together random digits. Due to the birthday problem, that approach is prone to collisions. For example, a four-digit alphabetic code has a 50% of collision after 800 codes.
tiny_id uses a linear congruential generator
to generate codes which do not overlap while retaining only a small, constant-sized piece
of state. For the same four-digit alphabetic code, tiny_id has a 0% chance of collision until all 456,976 possible codes have been generated.
These codes are indended for use-cases where it's desirable to have short, human-readable codes such that two codes generated in a row are no more likely to resemble each other than codes that are not. It should not be used in cases where the codes need to be non-guessable. They also do not guard against a German tank problem-type analysis by someone sufficiently motivated.
How to use it
Basic use
use ShortCodeGenerator;
Alphabets
use ShortCodeGenerator;
Exhaustion Strategies
Eventually, all short code generators reach a point where they run out of codes of a given length. There are three options for what to do when this happens:
- Increment the length. This corresponds to
ExhaustionStrategy::IncreaseLength, which is the default. - Cycle. This repeats the cycle of codes from the beginning. The order of codes
is the same in every cycle. Corresponds to
ExhaustionStrategy::Cycle. - Panic. In the spirit of fail-fast,
this panics when all codes have been used, for cases where exhaustion is unexpected
and assumed by the rest of the program not to happen. Corresponds to
ExhaustionStrategy::Panic.
use ;
Notes
Note that the ShortCodeGenerator object itself contains a small amount of
state, which is updated every time a short code is generated. Short codes must
be generated by the same ShortCodeGenerator object in order to avoid collisions.
With the serde crate option, enabled by default, ShortCodeGenerator objects
can be serialized to any format supported by serde. This
can be used to persist the state of a generator for later use. (If you are using
a custom alphabet, the type of that alphabet must also be serializable.)
The total number of possible codes (alphabet size to the power of length) must
fit in a u64. If you're working
with large enough codes and alphabets that that's a problem, you probably don't need
this library anyway (as random collisions will be more rare).
Randomness is only used during the construction of ShortCodeGenerator.
Code generation itself is entirely deterministic based on the current generator
state.
All operations use constant time and space, except for ShortCodeGenerator
construction. Construction technically has time complexity superlinear to the
cardinality of the alphabet provided. For reasonable alphabet sizes (say, <1000),
this should be negligible.
If you provide an alphabet rather than use one of the built-in alphabets, that alphabet must not contain any repeated entries. This is not enforced by the library, but failure to abide will result in collisions.