מחולל UUID v1, v6 ו-v7

Universally Unique Identifier (UUID) הוא אבן יסוד במערכות מבוזרות: מפתח ייחודי בלי תיאום מרכזי. גרסה 4, שנשענת רק על מספרים אקראיים, היא המוכרת ביותר, אבל כמפתח ראשי ב-RDBMS יש לה מחיר. אקראיות טובה לאי-צפיות ורעה לאינדקס. הכנסת UUID אקראי לאינדקס B-tree גורמת לפיצולי עמוד ולפרגמנטציה, ומהירות הכתיבה יורדת עם הזמן. כאן נכנסים מזהים מבוססי זמן — גרסאות 1, 6 ו-7 — שמשלבים ייחודיות עם סדר כרונולוגי.

גרסה 1 הייתה הניסיון הראשון לחבר ייחודיות לזמן: חותמת, רצף שעון וכתובת MAC של הצומת. ה-MAC נתן ייחודיות מרחבית בין מכונות, והחותמת ייחודיות בזמן. החולשה לאינדקס: הסיביות המשמעותיות מייצגות את הגרנולריות הנמוכה של הזמן. ככל שהזמן רץ, תחילת המחרוזת משתנה מהר ולא צפוי, ואין מיון סדרתי. חשיפת ה-MAC גם העלתה חשש פרטיות, ורבים נטשו את v1.

גרסאות 6 ו-7 פותרות את זה. v6 הוא בעצם v1 מאורגן מחדש: רכיבי החותמת מסודרים כך שהסיביות המשמעותיות מייצגות את הגרנולריות הגבוהה (שנים, חודשים, ימים) ויורדות לשברי שנייה. לכן v6 ניתן למיון לקסיקוגרפי לפי זמן. מזהה של מחר ימוין אחרי מזהה של היום, בדיוק כמו שאינדקס B-tree מצפה. זה מסיר את הפרגמנטציה של v4 ואת חוסר המיון של v1, ונשאר תואם למבנה UUID המסורתי.

v7 הוא תקן הזהב למפתח ראשי מודרני. במקום האפוק הגרגוריאני של v1 ו-v6, הוא משתמש ב-Unix Epoch (אלפיות שנייה מחצות 1 בינואר 1970 UTC). החותמת תופסת את 48 הסיביות הראשונות, והשאר אקראיות קריפטוגרפית חזקה. יש גם מיון סדרתי להכנסות מהירות וגם פרטיות של נתונים אקראיים. המחולל החינמי והפרטי בדפדפן יוצר את המזהים האלה מיד, עם אפס העלאות לשרת.

כשמתכננים יישום ווב או מיקרו-שירות חדש, מפתחים בוחרים לעיתים קרובות ב-UUID גרסה 4 כמפתח ראשי במסד. הפיתוי ברור: קל לייצר אותם, הם ייחודיים גלובלית, והם מבטלים את הצורך ברצף מספר שלם שעולה אוטומטית, שיכול להפוך לצוואר בקבוק בארכיטקטורה מבוזרת. אבל הנוחות הזו באה בעלות נסתרת תלולה לביצועי המסד. כדי להבין למה, צריך לבחון איך מסדים יחסיים כמו PostgreSQL, MySQL ו-SQL Server שומרים ומאנדקסים נתונים מתחת למכסה. רוב מערכות ה-RDBMS משתמשות בעצי B ‏(B-tree, עץ מאוזן) לאינדקסים הראשיים. עצי B מותאמים מאוד להכנסה סדרתית. כשמכניסים רשומה חדשה עם מזהה שעולה אוטומטית, המסד פשוט מצרף את המפתח החדש לעלה הימני ביותר של העץ. זו פעולה מהירה ויעילה מאוד, עם תקורה מינימלית.

לעומת זאת, כשמכניסים רשומה עם UUID v4 אקראי לחלוטין, המסד חייב למקם את המפתח החדש במיקום אקראי בתוך עץ ה-B הקיים. כשהטבלה גדלה והעלים מתמלאים, הכנסת ערך אקראי מכריחה את המסד לפצל את הדף — ליצור שני דפים חדשים ולהעביר חצי מהנתונים כדי לפנות מקום לרשומה. התהליך נקרא פיצול דף. פיצולי דף יקרים חישובית. הם צורכים מחזורי מעבד, מגבירים את הגברת הכתיבה ומנפחים את גודל האינדקס. חשוב מכך, הם הורסים את המקומיות הפיזית של הנתונים על מדיית האחסון. כשמנסים לקרוא טווח של רשומות אחרונות, המסד קופץ על פני הדיסק (או דפי הזיכרון) כדי לאסוף נתונים מפוצלים, וכך עולה דרמטית קלט-פלט הדיסק וביצועי הקריאה קורסים. במערכות בקנה מידה גדול, פיצול האינדקס הזה יכול להאט את מהירות הכתיבה עד זחילה.

זו בדיוק הבעיה ש-UUID גרסה 6 וגרסה 7 נועדו לפתור. כי v6 ו-v7 מקודדים חותמת זמן בדיוק גבוה בתחילת המזהה, הם ממוינים באופן טבעי לפי סדר כרונולוגי. כש-UUID מבוסס זמן חדש נוצר ומוכנס למסד, הוא מתנהג דומה למספר שלם שעולה אוטומטית. הוא מצטרף בנקיון לסוף אינדקס עץ ה-B, כמעט מבטל פיצולי דף ושומר על אינדקס קומפקטי ויעיל. מדדים מראים בעקביות ש-UUID שניתן למיון סדרתי יכול לשפר את תפוקת הכתיבה עד 50% לעומת UUID אקראי, ובמקביל להפחית את הזיכרון שנדרש למטמון האינדקס. באמצעות מחולל ה-UUID החינמי לחלוטין אפשר לאמץ את המזהים עתירי הביצועים האלה מיד. הכלי פרטי לחלוטין ורץ בדפדפן, עם אפס העלאות לשרת, בזמן שמייעלים את ארכיטקטורת המסד.

אחרי שקהילת ההנדסה זיהתה את החיסרון החמור בביצועים של UUID אקראיים לאינדוקס מסד, השיחה עברה לחלופות מבוססות זמן. עם הופעת UUID גרסה 6 ו-UUID גרסה 7, מפתחים ניצבים בפני דילמה חדשה: איזו גרסה לממש ביישום? שתי הגרסאות פותרות את פיצול אינדקס המסד באמצעות מזהים שניתנים למיון לקסיקוגרפי, אבל הן מגיעות למטרה במבנים שונים ונשענות על תקופות זמן (epoch) שונות. הבנת הניואנסים הטכניים קריטית להחלטה ארכיטקטונית שתגדל עם היישום.

UUID גרסה 6 תוכנן במיוחד כתחליף ישיר למערכות שכבר נטועות עמוק באקוסיסטמה של UUID גרסה 1. הוא משתמש באותו epoch גרגוריאני של 100 ננו-שניות (החל מ-15 באוקטובר 1582) ושומר על חלק גדול ממבנה הסיביות, כולל רצף השעון ושדה מזהה הצומת (כתובת MAC). החידוש המבריק היחיד של v6 הוא סידור מחדש של שדות חותמת הזמן — העברת הסיביות המשמעותיות ביותר לתחילת המחרוזת — כך שהמזהים ממוינים באופן טבעי לפי זמן. בעבודה על בסיס קוד ישן או על סכמת מסד ותיקה שמצפה לעיצוב ההיסטורי הנוקשה של מזהה v1, UUID v6 הוא הבחירה המתאימה. הוא נותן את קפיצת הביצועים של מיון סדרתי, ושומר על תאימות לאחור חלקה עם התשתית הקיימת.

לכל פרויקט חדש, יישום מודרני ופיתוח משדה ירוק, UUID גרסה 7 היא ההמלצה החד-משמעית. UUID v7 נוטש את ה-epoch הגרגוריאני הארכאי לטובת Unix Epoch הנפוץ (מילישניות מאז 1 בינואר 1970). כך חילוץ חותמת הזמן מ-UUID v7 פשוט להפליא כמעט בכל שפת תכנות מודרנית, בלי הזזות סיביות מורכבות ובלי חישובי תאריך היסטוריים. בנוסף, UUID v7 זונח לגמרי את כתובת ה-MAC ואת שדות רצף השעון, שפוגעים בפרטיות. אחרי הקצאת 48 סיביות לחותמת הזמן של Unix, הוא ממלא את 74 הסיביות הנותרות בנתונים פסאודו-אקראיים מאובטחים קריפטוגרפית. המבנה ההיברידי נותן את הביצועים הטובים ביותר להכנסות למסד, ובו-זמנית עמידות חזקה להתנגשויות ושמירה על פרטיות המשתמש. בין אם בוחרים ב-v6 לתאימות ישנה ובין אם ב-v7 לפרויקט חדש, המחולל החינמי והפרטי בדפדפן נותן גישה מיידית למזהים המתקדמים האלה. עם אפס העלאות לשרת אפשר לשלב אותם בביטחון, בלי לפגוע באבטחה.

בעידן שבו פרטיות דיגיטלית תחת איום מתמיד, ומפתחים נזהרים יותר ויותר משיתוף נתונים טכניים רגישים, אופן הפעולה של כלי עזר מקוונים חשוב מאי פעם. האינטרנט מוצף בכלי מפתחים 'חינמיים' — כולל מחוללי UUID, מעצבי JSON ומחשבוני גיבוב — שפוגעים בחשאי בפרטיות. במחולל מקוון טיפוסי, הדפדפן שולח לעיתים קרובות בקשת API לשרת מרוחק. השרת מעבד את הבקשה, מייצר את המזהה ומחזיר אותו. הארכיטקטורה הזו פותחת פרצות אבטחה משמעותיות. ראשית, היא חושפת את כתובת ה-IP ואת דפוסי השימוש לעוקבי אנליטיקה של צד שלישי. שנית, היא מאפשרת לספק לרשום את הנתונים שנוצרו, וליצור מאגר מרכזי של מזהים שעלולים להיות רגישים. לבסוף, הכלים שתלויים בשרת נעולים בדרך כלל מאחורי מגבלות מתסכלות: תקרת יצירה יומית, הרשמת דוא״ל כפויה או חומת תשלום אגרסיבית שנועדה לגבות כסף על הזרימה.

ב-Utiliome אנחנו מאמינים שכלי מפתחים יסודיים צריכים להיות חינמיים לחלוטין ונטולי חיכוך. מחולל UUID v1, v6 ו-v7 נבנה על ארכיטקטורה שונה מהיסוד, שפרטיות בראשה. כשטוענים את הכלי, כל לוגיקת היישום יורדת ישירות למכשיר. כשלוחצים על 'יצירה', ה-UUID נוצרים מקומית בתוך הדפדפן באמצעות ממשקי קריפטוגרפיה ילידיים של JavaScript. יש אפס העלאות לשרת. הנתונים לא עוזבים את המחשב, ואנחנו לא רואים את המזהים שנוצרים. העיבוד האמיתי בדפדפן מבטיח שהזרימה נשארת פרטית לחלוטין ומוגנת מיירוט או מרישום לא רצוי.

כי אין צורך בשרתי עיבוד יקרים בצד האחורי, אפשר להציע את הכלי כמשאב חינמי לחלוטין, בלי תנאים נסתרים. אין מכסה יומית, אין דמי מנוי נסתרים ואין הרשמת חשבון כפויה. אף אחד לא יתבקש למסור כתובת דוא״ל או לעבור חומת תשלום רק כדי לייצר מפתח למסד. בין אם מפתח יחיד שבונה אב-טיפוס ובין אם מהנדס בארגון שבודק אינדוקס עתיר ביצועים עם UUID v7, אפשר להסתמך על הכלי ליצירה בלי תקרה ובלי חיכוך. השילוב של העליונות הטכנית של UUID מבוססי זמן וניתנים למיון, עם מחויבות עיקשת לפרטיות ולגישה פתוחה, הופך את הפלטפורמה למשאב מרכזי לארכיטקטורת תוכנה מודרנית.