בפעם הראשונה ש-UUIDs באמת חשובים לי, העברתי SaaS צמוד לוורדפרס מתיבה בודדת של MySQL להגדרה עם העתק קריאה ותוכנית לרסיס מאוחר יותר. מזהי הגדלה אוטומטית היו בסדר במשך שנים - עד ששני שירותים התחילו להכניס למה שיהפוך לאותה טבלה הגיונית, ופתאום id = 42 התכוון לשתי שורות שונות. That's ברגע שהגידול האוטומטי מפסיק לעבוד בשקט, ו-UUIDs הם התשובה הרגילה.
UUID הוא ערך של 128 סיביות שאתה יכול ליצור בכל מכונה, בכל עת, ללא תיאום, ועדיין לסמוך על היותו ייחודי. That "no coordination" חלק הוא כל העניין: אפליקציה לנייד במצב לא מקוון במטוס, שלושה שירותי מיקרו ועובד רקע יכולים כולם להטביע מזהים בו זמנית ולעולם לא להתנגש. הגיבוי המתמטי לביטחון הזה הוא באמת אבסורדי, ו-I' יראה לך עד כמה אבסורדי בשנייה.
ה מחולל UUID ב-Toolz.dev יוצר UUIDs בודדים או בתפזורת במספר גרסאות באופן מיידי, ממש בדפדפן שלך - שימושי כאשר אתה' זורעים טבלה או צריכים מזהה זרוק לבדיקה. מדריך זה מכסה את המשמעות של הגרסאות בפועל, איזו מהן לבחור בשנת 2026, כיצד לאחסן אותן מבלי להרוס את אינדקס מסד הנתונים שלך, ואת הטעויות שעשיתי כדי שתוכל לדלג עליהן.
TL;DR: עבור מפתחות ראשיים חדשים של מסד נתונים בשנת 2026, צור UUID v7- it's מסודר בזמן כך שהוא אינדקס היטב, והוא 't מדליף חומרה כמו v1. להשתמש v4 כאשר אתה רוצה חוסר חיזוי טהור אחסן אותם כילידים
uuidסוג אוBINARY(16), לעולם לאVARCHAR(36). הפוך אותם בכמויות גדולות עם מחולל UUID, ושלב אותו עם ה ממיר חותמת זמן לקריאת הזמן האפוי לתוך v7. הכל בצד הלקוח, הכל בחינם.
מהו UUID, בדיוק?
UUID (Universally Unique Identifier) הוא מספר של 128 סיביות המשמש לזיהוי משהו מבלי שרשות מרכזית תחלק מזהים. מיקרוסופט קוראת לאותו דבר GUID (Globally Unique Identifier); הם' זהים בכל דרך שחשובה. צורת הטקסט הקנונית היא 36 תווים - 32 ספרות משושה מפוצלות לחמש קבוצות מקוף של 8-4-4-4-12:
550e8400-e29b-41d4-a716-446655440000
שניים מאותם מיקומי hex הם 't נתונים אקראיים - they're metadata. ספרת המשושה ה-13 מקודדת את גרסה (איזו אסטרטגיית דור עשתה את זה), והספרה הראשונה של הקבוצה הרביעית מקודדת את וריאנט (באיזה תקן פריסה הוא עוקב - 8, 9, a, או b עבור UUIDs הסטנדרטיים). אז בדוגמה למעלה, ה 4 בקבוצה השלישית אומר לך את זה 's a v4.
עד כמה ייחודי "ייחודי," בֶּאֱמֶת?
לאחר שמירת סיביות הגרסה והגרסה, ל-v4 UUID יש 122 סיביות אקראיות. That's 2^122 ערכים אפשריים, או בערך 5.3 undecillion:
5,316,911,983,139,663,491,615,228,241,121,400,000
כדי להפוך את זה לקונקרטי: אם יצרת מיליארד UUIDs בכל שנייה, אתה ' צריך בערך 86 שנים לפני שתגיע אפילו לסיכוי של 50% ל-a סינגל התנגשות בכל מקום במונחים הנדסיים מעשיים, התנגשויות v4 לא קורות, ואתה יכול לעצב כאילו הם לעולם לא יקרה.
מה 's ההבדל בין UUID v1, v4 ו-v7?
המפרט - במקור RFC 4122, מעודכן כעת על ידי RFC 9562 (2024)- מגדיר מספר גרסאות שלושה עניין לעבודה היום יומית.
UUID v1 - חותמת זמן + כתובת MAC
v1 תופר יחד חותמת זמן של 100 ננו-שניות (בספירה מ-15 באוקטובר 1582, התאריך שבו התחיל הלוח הגרגוריאני - אחד מקטעי הטריוויה הספציפיים האהובים עלי) עם כרטיס הרשת 's כתובת MAC. זה ו#39; מסודר באופן טבעי בזמן ותוכל לחלץ ממנו את זמן היצירה.
הבעיה נמצאת ממש שם בהגדרה: היא מטמיעה את כתובת ה-MAC של המכונה שיצרה אותה. זה מדליף את זהות החומרה, ובשילוב עם חותמת הזמן, הופך את המזהים לחיזויים במקצת. דוגמא: 6ba7b810-9dad-11d1-80b4-00c04fd430c8. I'd השתמש רק ב-v1 עבור תאימות מדור קודם כעת.
UUID v4 - אקראי
v4 הוא 122 סיביות של אקראיות ותו לא. It's הגרסה שרוב האנשים מתכוונים אליה כשהם אומרים "UUID," and it's dead simple: no timestamp, no hardware, no order. דוגמא: f47ac10b-58cc-4372-a567-0e02b2c3d479.
היתרון הוא שהוא לא דולף כלום והוא בלתי צפוי, וזה בדיוק מה שאתה רוצה עבור כל דבר שצריך 't להיות מנחש החיסרון הוא שזה 's אקראי, אז תוספות עוקבות מתפזרות על כל האינדקס שלך - שכפי שגיליתי, יש לו עלות ביצועים אמיתית בקנה מידה.
UUID v7 - מסודר בזמן + אקראי
v7 היא הפשרה המודרנית, סטנדרטית ב-RFC 9562. 48 הסיביות הראשונות הן חותמת זמן של יוניקס באלפיות שניות; השאר אקראי. דוגמא: 018e4880-d4d0-7b9c-8c37-2a5c0f1e3d8a.
פריסה זו פירושה שמזהי v7 ממוינים באופן כרונולוגי - שורות חדשות נוחתות ב-"end" של אינדקס עץ B במקום פיזור - תוך שהוא עדיין ייחודי בעולם וללא קואורדינציה. זה דולף זמן יצירה משוער (בדרך כלל בסדר) אבל לא חומרה. עבור פרויקטים חדשים, זהו המפתח הראשי המוגדר כברירת מחדל שלי, והוא ' זה הכיוון שגם ה-IETF מצביע כעת.
Here's הפשרה במבט חטוף:
| גרסה | הוזמן? | דליפות | הטוב ביותר עבור |
|---|---|---|---|
| v1 | כן (זמן) | כתובת MAC + זמן | מערכות מדור קודם בלבד |
| v4 | לא (אקראי) | שום דבר | אסימונים בלתי-נחש, תעודות זהות כלליות |
| v7 | כן (זמן) | זמן יצירה משוער | מפתחות ראשיים חדשים של מסד נתונים |
קיימות גם הגרסאות הפחות בשימוש: v3 ו-v5 הן גיבוב דטרמיניסטי של מרחב שמות בתוספת שם (v5 משתמש ב-SHA-1 ומועדף על פני v3's MD5), v6 הוא v1 מסודר מחדש, ו-v8 שמור עבור מותאם אישית יישומים.
האם עליך להשתמש במזהי UUID או במזהי הגדלה אוטומטית?
זה הדיון I' היו לי יותר ביקורות עיצוב מכל אחר, אז הנה' המסגרת שבה אני משתמש בפועל ולא תשובה דתית.
היצמד להגדלה אוטומטית כאשר יש לך מסד נתונים בודד, הביצועים והאחסון צפופים, ובני אדם צריכים לקרוא את המזהים. מספר שלם הוא 4–8 בתים לעומת UUID's 16, השוואות מספרים שלמים מהירות יותר, ו-"order #12345" הרבה יותר קל לקרוא בטלפון מאשר UUID בן 36 תווים. בקופסה בודדת ללא רסיסים, הגדלה אוטומטית היא באמת הבחירה הפשוטה והמהירה יותר - don' לא להגיע ל-UUIDs מחוץ לאופנה.
עבור אל UUIDs כאשר כל אחד מאלה נכון: you're מופץ (מספר שירותים או שרתים מטביעים מזהים באופן עצמאי), you' מודאגים מספירה (ניתן לנחש מזהים בהגדלה אוטומטית וחושפים בשקט את ספירת הרשומות שלך - /users/1234 אומר לתוקף שיש לך פחות מ-1,235 משתמשים), עליך למזג נתונים ממספר מסדי נתונים ללא התנגשויות, או שאתה רוצה שלקוחות ייצרו מזהים לפני שהם מסתנכרנים. נקודת הספירה הזו היא שיקול אבטחה אמיתי שאנשים מעריכים פחות.
ואמצע v7: UUID v7 נותן לך את הדור המבוזר של UUID ו הסדר הידידותי לאינדקס של הגדלה אוטומטית, ללא ספירת שיא דולפת. עבור רוב הפרויקטים החדשים בשנת 2026 הזקוקים למזהים לא עוקבים, v7 היא התשובה שמסיימת את הדיון.
כיצד אתה מאחסן UUIDs מבלי להרוס את האינדקס שלך?
זה הקטע שנולד מהטעות היקרה שלי, אז שימו לב כאן אם בשום מקום אחר.
בהגירה ההיא שציינתי, אחסנתי את ה-UUID החדשים כ VARCHAR(36) כי זה היה הדבר הברור והקריאה לעשות. זה עבד - ואז הטבלה גדלה, וההוספות וההצטרפות נעשו איטיות יותר למדידה. שתי בעיות הוסיפו: הוצאתי 36 בתים לכל מזהה במקום 16 ו השתמשתי ב-V4 UUIDs אקראיים, אז כל הוספה נחתה בנקודה אקראית באינדקס המפתח הראשי, פיצלה אותו וחבטה במאגר המאגר. התיקון היה אחסון אותם כבינאריים, ובפרויקט הבא, מעבר ל-v7 כך שההוספות נשארו ברצף.
PostgreSQL יש יליד uuid סוג - השתמש בו. הוא מאחסן 16 בתים ומשווה מהר:
CREATE EXTENSION IF NOT EXISTS "pgcrypto";
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
MySQL אין סוג UUID מקורי, אז אחסן BINARY(16) ולהמיר עם UUID_TO_BIN() / BIN_TO_UUID(). הטיעון השני חשוב:
CREATE TABLE users (
id BINARY(16) PRIMARY KEY,
name VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- The `true` swaps the timestamp bytes for better index locality on v1
INSERT INTO users (id, name, email)
VALUES (UUID_TO_BIN(UUID(), true), 'Alice', '[email protected]');
SELECT BIN_TO_UUID(id, true) AS id, name, email FROM users;
הכלל שיש לזכור: יליד uuid הקלד היכן יש לך אחד, BINARY(16) איפה אתה עושה 't, ו VARCHAR(36) בעצם אף פעם לא עבור מפתח אתה'll אינדקס והצטרף.
כיצד ניתן ליצור UUIDs בקוד?
לחד פעמי מהיר, ה מחולל UUID מהיר יותר מפתיחת REPL. בקוד, לכל שפה מרכזית יש את זה מובנה או במרחק צעד אחד.
JavaScript / TypeScript- הדפדפן וה-Node שולחים שניהם מחולל v4 עכשיו:
const id = crypto.randomUUID(); // v4, no dependency needed
// For v7, use the 'uuid' package:
import { v7 as uuidv7 } from 'uuid';
const ordered = uuidv7();
פייתון:
import uuid
uuid.uuid4() # random
uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com') # deterministic (SHA-1)
Java: UUID.randomUUID() נותן לך את v4 מהקופסה; v7 צריך ספרייה כמו java-uuid-generator או מימוש קטן של RFC 9562.
ללכת: github.com/google/uuid נותן לשניכם - uuid.New() עבור v4 ו uuid.NewV7() עבור v7.
שים לב שעוזרים בזמן ריצה מקוריים כמעט תמיד נותנים לך v4. אם אתה רוצה ספציפית v7 להזמנתו, אתה בדרך כלל צריך ספרייה, מכיוון שהוא ' התקן החדש יותר ולא כל stdlib השיג את הפער.
היכן מופיעים UUIDs במערכות אמיתיות?
It' קל לדבר על UUIDs בתקציר, אז הנה המקומות הקונקרטיים I' הסתמכו עליהם, כי הגרסה שאתה בוחר באמת תלויה בעבודה.
מפתחות ראשיים של מסד נתונים בהגדרה מבוזרת. זה המקרה הקלאסי וזה שהתחיל את המאמר הזה בשבילי הרגע שיותר מכותב אחד יכול להכניס לאותה טבלה לוגית - העתקים, רסיסים, או שני שירותים החולקים סכימה - הפסקות הגדלה אוטומטית מפתח ראשי v7 פותר את בעיית הקואורדינציה ועדיין אינדקס בצורה נקייה כי זה 's לפי סדר זמן.
מזהים שנוצרו על ידי לקוח עבור אפליקציות לא מקוונות ראשונות. אפליקציה לנייד או SPA של דפדפן צריכה לעתים קרובות ליצור רשומה לפני שהיא יכולה לדבר עם השרת - חשבו על הערה שנכתבה במטוס, או ממשק משתמש אופטימי שמציג את השורה החדשה באופן מיידי. אם הלקוח מטביע UUID מלפנים, לרשומה יש זהות יציבה מהקשה הראשונה ומסתנכרנת מאוחר יותר ללא שרת הלוך ושוב אל " קבל מזהה." I' השתמשתי בזה כדי לגרום לטפסים להרגיש מיידיים אפילו בחיבורים מתקלפים.
מזהי משאבים שאינם רבים בכתובות URL וממשקי API. לשים /orders/1042 בכתובת URL אומר בשקט לכל אחד שאתה ' קיבלת לכל היותר 1,042 הזמנות, ונותן להם ללכת /orders/1041, /orders/1040, וכן הלאה. החלפה ב-UUID מסירה גם את הדליפה העסקית וגם את הספירה הקלה. לכל דבר שמשתמש יכול לראות בכתובת URL, כדאי לעשות זאת - אם כי זכור ש-UUID אינו מנגנון בקרת גישה; אתה עדיין צריך בדיקות הרשאות אמיתיות מאחוריו.
מזהי מתאם למעקב. כאשר בקשה בודדת מתפשטת על פני חמישה שירותי מיקרו, מצמידה UUID אחד כמזהה מתאם ומתעדת אותו בכל סיבוב הופ " איפשהו בבלגן הזה משהו נכשל" למחרוזת אחת הניתנת לברך על פני כל היומנים שלך. זה מקום אחד שבו אפילו v4 רגיל מושלם - אתה לא ' לא צריך הזמנה, רק ייחודיות.
מפתחות אימפוטנציה. ממשקי API של תשלומים ו-webhook מבקשים לעתים קרובות מהלקוח לשלוח UUID כמפתח אימפוטנציה כך שבקשה שניסתה שוב תעשה ' לא לחייב כרטיס פעמיים. הלקוח יוצר אותו פעם אחת, עושה בו שימוש חוזר בניסיונות חוזרים, והשרת מסיק עליו. It' הוא דפוס קטן שמונע מחלקה יקרה מאוד של באגים.
שאלות נפוצות
למה משמש UUID?
UUID מזהה משהו באופן ייחודי - שורת מסד נתונים, משאב API, הפעלה, קובץ שהועלה, מעקב על פני שירותי מיקרו - מבלי להזדקק לשירות מרכזי כדי לחלק מזהים. It's the go-to בכל פעם שמערכות או לקוחות מרובים חייבים ליצור מזהים באופן עצמאי ועדיין להיות בטוחים שהם זכו 't clash. אתה יכול ליצור אחד באופן מיידי עם מחולל UUID על Toolz.dev.
האם שני UUIDs יכולים להיות זהים אי פעם?
בתיאוריה כן; בפועל לא. ל-v4 UUID יש 122 ביטים אקראיים, מה שנותן כ-5.3 undecillion אפשרויות. You' צריך ליצור בסדר גודל של 2.7 קווינטיליון UUIDs לפני שמגיעים לסיכוי של 50% אפילו להתנגשות אחת. לכל מטרה הנדסית אמיתית, אתה יכול להתייחס ל-UUIDs כאל מובטחים ייחודיים.
באיזו גרסת UUID עלי להשתמש בשנת 2026?
עבור מפתחות ראשיים חדשים של מסד נתונים, UUID v7 - it's מסודר בזמן לאינדקס יעיל תוך שמירה על ייחודיות גלובלית, ו-it' היא המלצת IETF הנוכחית תחת RFC 9562. השתמש ב-v4 כאשר חוסר הניבוי חשוב, כגון מזהים שאסור לנחש. הימנע מ-v1 לעבודה חדשה מכיוון שהוא מטמיע את מכונת הייצור ' כתובת MAC.
האם UUIDs עוקבים?
v1 ו-v7 מסודרים בזמן, כך שמזהים שנוצרו מאוחר יותר ממיינים אחרי קודמים; v4 הוא אקראי לחלוטין ללא סדר. סדר רציף הוא מה שהופך את v7 לידידותי לאינדקסים של עץ B - שורות חדשות מתווספות במקום מתפזרות. אם אתה ' משתמשים ב-v4 אקראי כמפתח ראשי בטבלה גדולה, חוסר הסדר הזה יכול לפגוע בביצועי ההוספה והאינדקס.
כיצד עלי לאחסן UUID במסד נתונים?
השתמש היליד uuid הקלד אם למסד הנתונים שלך יש כזה (PostgreSQL כן). אחרת אחסן BINARY(16), וב-MySQL 8.0+ המר עם UUID_TO_BIN() ו BIN_TO_UUID(). להימנע VARCHAR(36) או CHAR(36) עבור מפתחות - אחסון מחרוזות מבזבז 20 בתים בשורה ומאט כל השוואה, מה שמצטבר מהר על שולחנות גדולים.
What's ההבדל בין UUID ל-GUID?
They'הם אותו דבר. UUID הוא המונח מ-RFC 4122 המשמש ברוב השפות והפלטפורמות; GUID הוא שם Microsoft's עבורו, נפוץ ב-Windows ו-NET. הפורמט והערבויות זהים, כך שתוכל לטפל ב-GUID וב-UUID לסירוגין.
האם אני יכול לחלץ את זמן היצירה מ-UUID?
מ-v1, v6 ו-v7, כן - הם מקודדים חותמת זמן. v7 מאחסן חותמת זמן של יוניקס של אלפיות שניות ב-48 הסיביות הראשונות שלו, אותה תוכל לפענח ולקרוא עם ממיר חותמת זמן. v4 ו-v5 אינם מכילים מידע על זמן, אז אין ' אין מה לחלץ מהם.
האם UUID v4 מאובטח מספיק עבור אסימוני הפעלה?
לא בפני עצמו. v4's 122 סיביות אקראיות אינן ניתנות לחיזוי, אך אסימוני הפעלה ואימות בדרך כלל רוצים לפחות 256 סיביות ממחולל מאובטח מבחינה קריפטוגרפית. השתמש באסימון אקראי מאובטח ייעודי לאישור, ושמור UUIDs לזיהוי משאבים במקום להגן עליהם.
כיצד אוכל ליצור UUID?
השתמש במחולל המובנה בשפה שלך 's: crypto.randomUUID() בדפדפנים מודרניים וב-Node.js, uuid.uuid4() בפייתון, או Guid.NewGuid() ב.NET כל אחד מייצר UUID v4 בשיחה אחת. לחד פעמי מהיר או אצווה, צור אותם באופן מיידי עם מחולל UUID באתר Toolz.dev - אין צורך בקוד.
כמה דמויות זה UUID?
UUID הוא 36 תווים בצורת הטקסט הקנונית שלו: 32 ספרות הקסדצימליות בתוספת ארבעת המקפים המפצלים אותו ל-8-4-4-4-12 קבוצות. הטקסט הזה מקודד 128 סיביות, וזו הסיבה שאחסון אותו כ-16 בתים גולמיים עם BINARY(16) הוא הרבה יותר קומפקטי מהמחרוזת בת 36 התווים.
עוטף
UUIDs הם אחד מאותם יסודות שאתה עושה ' לא חושב עליהם עד שמערכת תצמח מעבר למסד נתונים בודד - ואז הם ' הם הכל. הגרסה הקצרה של 2026: ברירת המחדל היא v7 עבור מפתחות ראשיים חדשים, השתמש v4 כאשר אתה צריך תעודות זהות בלתי ניתנות לניחוש, אחסן אותן כ יליד uuid או BINARY(16), ודלג על v1 לכל דבר חדש. למד ממני VARCHAR(36) אחר הצהריים אז אתה עושה 't חזור על זה.
צור אותם באופן מיידי עם החינם מחולל UUID בToolz.dev - יחיד או בתפזורת, כל גרסה, כל צד הלקוח עם שום דבר לא הועלה.When אתה צריך לקרוא את השעה בתוך v7, להגיע ל ממיר חותמת זמן, ולעיין בשאר ה כלי קידוד- 600+ כלי עזר בחינם - נגמר ב Toolz.dev.
