Show HN: Timeflake, 128-bit roughly-ordered UUIDs

(github.com)

10 points | by amzans 1547 days ago

1 comments

  • amzans 1547 days ago
    Hi everyone! Just wanted to mention the use case for this:

    1) You want to have UUIDs in URLs that are not predictable (vs auto-increment integers).

    2) So they should be random, but roughly-ordered over time so that your MySQL/Postgres indices stay fast and efficient as the dataset grows.

    3) And simple to use across multiple machines (no coordination or centralized system required to generate).

    4) It would be nice if they were compatible with standard 128-bit UUID representations (many libraries in Python handle uuid.UUID, but no third-party types).

    Checkout the "Why?" section in the readme for a comparison to some of the alternatives.

    Also if you don't want to have to use this library:

      import os
      import uuid
      import time
    
      timestamp = int(time.time() * 1000)
      randomness = int.from_bytes(os.urandom(10), byteorder='big', signed=False)
      value = ((timestamp << 80) | randomness).to_bytes(16, byteorder='big')
    
      uuid.UUID(bytes=value)  
      >>> UUID('016fd379-198f-3327-2bf0-d2a0f5d863d7')
    
    
    Feel free to ask me anything.
    • kseistrup 1546 days ago
      When using the .uuid property, flakes will occasionally collide with e.g. UUIDv1, UUIDv4, and UUIDv5 – to mention a few regularly encountered UUID versions – but it won't make any sense to try to parse the information then (except, perhaps for v4).

      Does the UUID specs have a version number that flakes could “naturally” belong to?