2. Who am I?
• Co-Founder and CTO of AppSharp, makers of Site Booster
• I’ve been using redis since 2010 in some capacity or another
3. What’s a unique ID?
“A unique identifier (UID) is a numeric or alphanumeric string that is
associated with a single entity within a given system. UIDs make it possible
to address that entity, so that it can be accessed and interacted with.”
4. Coordinated Unique ID
• Requires coordination:
• Central Location - Example: MySQL AUTOINCREMENT
• Or each instance knows about others, etc
• Pros:
• Easy to make sure its unique
• Usually doesn’t involve additional services/servers
• Usually sortable (like AUTOINCREMENT), newer IDs are usually bigger, older are
smaller
• Cons:
• Usually a Bottleneck in high load environment
• If generated from a service - service can be a single point of failure
5. Uncoordinated Unique ID
• Generated from multiple locations
• Example: GUID, KSUID, ULID, etc
• Can be generated from multiple places while guaranteeing uniqueness*
• Pros
• No coordination needed (between multiple ID generation code)
• Can be generated ahead of data insert (like in the case of MySQL
AUTOINCREMENT)
• Can be generated in multiple places/services/servers
• Cons
• May require an additional service/server
• Generated outside “regular” flows such as INSERT
• (usually) requires time synchronization (depending on impl can be susceptible
to time skew)
6. GUIDs are great. But….
• Its size is 128 Bit and sometimes you need less
• the ASCII representation includes dash (“-”) which can cause text
indexing to consider it a delimiter
• Its uniqueness is (mostly) dependant on the randomness source
• UUIDv1 can expose host information
• Not k-sortable (excluding UUIDv1)
7. What do we want from Unique IDs?
• Be Unique! (Duh!)
• K-sortable - roughly sortable, with just a bunch of IDs
• Uncoordinated (or Semi-coordinated)
8. The structure of a new Unique ID
• Timestamp part allows sorting
• Timestamp granularity depends on its bit size (usually up to 1ms)
9. Examples of Unique ID structures
• Snowflake
• time - 41 bits (millisecond precision w/ a custom epoch gives us 69 years)
• region_id - 4 bits - gives us 16 different region or data centers to work with
• worker_id - 10 bits - gives us up to 1024 workers per region_id
• sequence_id - 8 bits - gives us up to 256 IDs per worker in the same millisecond
• KSUID
• 32-bit unsigned integer UTC timestamp
• 128-bit randomly generated payload
• ULID
• 48 bits UNIX-time in milliseconds
• 80 bits User defined entropy source.
11. What is RedisUnqiue?
• Redis module with multiple Unique IDs implementations ready to be
used
• Why should I use it?
• If you already have Redis, save adding another service/server
• Integrate it with your object generation flow for Redis ORM usage
• If you choose a k-sortable implementation IDs are easily sortable
12. Why I created RedisUnique?
• Experiment further with Redis modules (first one was redissnowflake -
the inspiration to RedisUnique)
• Unique IDs are fun (and useful)
• Hate to run a dedicated service just for IDs, monitor it, manage it, etc
• Easily pick from multiple Unique IDs implementations
• Because I can :-)