UUID, скорочення від Universal Unique Identifier - це 128-бітний формат ідентифікатора, широко розповсюджений у комп'ютерних системах. Нижче наведено приклад з використанням його найпоширенішого представлення: a73ba12d-1d8b-2516-3aee-4b15e563a835. Я на власному досвіді переконався, як використання UUID шкодить зручності використання комп'ютерних систем, і хочу, щоб ви зрозуміли, чому він вам точно не потрібен.
Візьмемо Amazon. Що, на вашу думку, є посиланням на один з їхніх продуктів?
- amzn.to/3c6n63N
- amzn.to/a73ba12d-1d8b-2516-3aee-4b15e563a835
Простого ідентифікатора на кшталт 3c6n63N більш ніж достатньо для представлення будь-якого продукту, при цьому він залишається читабельним і полегшує комунікацію. Альтернативний UUID на кшталт a73ba12d-1d8b-2516-3aee-4b15e563a835 є просто марнотратним з точки зору користувача.
У конкретному випадку, я був свідком того, як об'єкти, які мали бути доступними кінцевим користувачам, використовували зручні для користувача ідентифікатори, в той час, як UUID використовувалися для внутрішніх потреб. Для того, щоб це працювало, необхідно або зіставлення "один до одного", або окремий список унікальних ідентифікаторів для ваших сутностей.
З таким же успіхом ви можете отримати комбінацію найгіршого з двох світів: UUID + послідовно згенеровані (автоінкрементовані) числові ідентифікатори.
Я бачив всілякі комбінації у багатьох системах: деякі сутності використовують лише дружні ідентифікатори, деякі - лише послідовні, а більшість - і ті, і інші.
Наприклад, сутність, яка використовується лише всередині системи, може використовувати UUID. Тоді з'являється потреба виставити його назовні, і розробники додають новий дружній ідентифікатор, щоб користувачі не стикалися зі сміховинно довгими посиланнями.
- При використанні UUID важко використовувати, відстежувати та порівнювати дані вручну.
- Використовуючи послідовні ідентифікатори, ви можете передати важливі бізнес-метрики конкурентам або досягти обмежень масштабованості та синхронізації.
- Якщо ви використовуєте обидва способи одночасно, вашим внутрішнім користувачам може бути складно зіставити ідентифікатори з UUID і навпаки.
Отже, після всього сказаного, я думаю, що я навів аргументи на користь того, щоб намагатися використовувати більш доступні ідентифікатори скрізь і всюди! Далі, подивіться це відео, і розглянемо практичну альтернативу.
Колізії та унікальність
Текстове представлення UUID має довжину 36 символів, включаючи чотири дефіси та 32 шістнадцяткові цифри. Існує чотири версії. Версії 1 і 2 базуються на даті-часі та MAC-адресі. Версії 3 і 5 базуються на імені простору імен. Версія 4 генерується повністю випадковим чином (отже, вона має більшу ентропію) і, схоже, використовується у більшості веб-систем.
Вона має 16^32 = 2^128 біт, що гарантує унікальність і має незначний ризик колізій.
Шістнадцяткова система числення широко використовується в обчисленнях як компактне представлення двійкової системи числення. У шістнадцятковій системі числення 10 - це 0xA, 11 - 0xB, 12 - 0xC, 13 - 0xD, 14 - 0xE, 15 - 0xF, 16 - 0x10 і так далі. Якщо ви хочете дізнатися або переглянути, як це працює, прочитайте статтю Двійкова система числення.
Практичні рішення
Як показує Том Скотт у своєму відео, 11 символів, закодованих у base58, достатньо для того, щоб YouTube обслуговував контент, навіть якщо врахувати, що відео, які не потрапили до списку, не можна буде знайти.
Розглянемо, яким простим та елегантним може бути рішення для генерації таких символів у Go:
// NewID generates a random base-58 ID.
func NewID() string {
const (
alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" // base58
size = 11
)
var id = make([]byte, size)
if _, err := rand.Read(id); err != nil {
panic(err)
}
for i, p := range id {
id[i] = alphabet[int(p)%len(alphabet)] // discard everything but the least significant bits
}
return string(id)
}
Це рішення використовує зрозумілу для людини схему кодування base58. Я трохи схитрував, використавши лише молодші біти для створення ідентифікатора замість того, щоб намагатися підвищити продуктивність, оскільки цього достатньо.
Існують і інші можливості. Base58 - це лише один з варіантів. Наприклад, у вас можуть бути інші потреби:
- Використання лише малих літер, щоб уникнути двозначності
- Обмеження кількості комбінацій символів, щоб уникнути слів ("поганих слів"), які виводяться як ідентифікатори.
Вам просто потрібно зробити деякі базові обчислення, щоб переконатися, що у вас є щось надійне для вашого варіанту використання.
Коли використовувати UUID?
UUID був розроблений з думкою про розподілені системи, але не всі розподілені системи однакові. Якщо ви говорите про веб-систему, що складається з архітектури мікросервісів, які працюють в одному центрі обробки даних, можливо, з однією базою даних, я б сказав, що вам взагалі не потрібні UUID, навіть якщо ви маєте справу з великими даними.
З іншого боку, якщо ви отримуєте дані, згенеровані системами, які ви не контролюєте, це може бути хорошим вибором. Я використовував його при написанні системи метрик і діагностики для інструментів CLI (кліматичні дані). У цьому конкретному випадку інструмент CLI, який я підтримував, додавав записи до файлу, що пересилається на наші сервери за допомогою фонового процесу, який виконується в кінцевому підсумку після деяких евристик.
Ще немає коментарів