הגישה הכפולה של Splync: UUID ומספרים שלמים אוטומטיים

בבסיס הנתונים של Splync, כל משתמש וכל פרויקט מזוהים בשני מזהים שונים: UUID ומספר שלם אוטומטי. המספר השלם האוטומטי הוא המוכר ביותר לרוב האנשים — הוא פשוט מונה: 1, 2, 3 וכו'. Splync משתמשת במספרים אלו לניהול כמעט כל טבלה בבסיס הנתונים בשרת, כי הם פשוטים, מהירים ויעילים. אך המספרים הפנימיים האלה לעולם אינם גלויים לאפליקציה. לדוגמה, אם היית המשתמש ה-42 שנרשם, ה-ID הפנימי שלך היה 42, אך האפליקציה ב-iOS לא תראה "42". במקום זאת, האפליקציה משתמשת ב-UUID לייצג אותך. אנו משתמשים באותה גישה גם לפרויקטים — ID של פרויקט עשוי להיות "7" בבסיס הנתונים, אך האפליקציה תמיד תתייחס אליו כ-UUID ארוך.

UUID הוא מזהה ייחודי אוניברסלי. Splync משתמשת בגרסה 4, ווריאנט 1 של UUIDs, בהתאם ל-RFC 4122 — אחד התקנים הנפוצים ביותר. זהו מחרוזת שנוצרת באקראיות, שנראית כמו 949ca11c-a6ed-48a3-b40a-fa9727494917. UUID נכתב בדרך כלל כ-32 תווים הקסדצימליים המחולקים לחמישה קטעים המופרדים במקפים. הוא מתוכנן להיות ייחודי כלל עולמי, כך שלא ייווצרו התנגשויות גם בין שרתים או בסיסי נתונים שונים. מתמטית, יש כ-16^32 = 2^128 אפשרויות. אך מאחר ששישה ביטים שמורים לווריאנט ולגרסה, המספר הכולל של UUIDs גרסה-4, ווריאנט-1 ייחודיים הוא בערך 2^122, או כ-5.3 x 10^36 — מספר אסטרונומי המבטיח ייחודיות מעשית.

הסיכוי ששני UUIDv4 יתאימו הוא בערך 1 ל-5.3 × 10^36. המספר הזה כה קטן שהוא כמעט בלתי ניתן לדמיון אנושי. כדי לדמיין זאת, תחשוב על זריקת 47 קוביות בו-זמנית. הסיכוי שכל הקוביות יראו "1" הוא בערך 1 ל-6^47, או קרוב ל-1 ל-3.7 × 10^36. זה באותו סדר גודל כמו התנגשות ב-UUID. עכשיו, תדמיין שכל אדם בעולם — כ-שמונה מיליארד מאיתנו — זורקים את 47 הקוביות כל מילישנייה במשך טריליון שנים. זה בערך 2.5 × 10^32 ניסיונות. גם לאחר כל זה, הסיכוי שמישהו, איפשהו, יזכה בכל ה-47 בבת אחת עדיין יהיה רק 1 לעשרת אלפים. זו הסיבה שהסיכוי להתנגשות בין שני UUIDv4 אינו רק "נדיר" אלא מצחיק בקוסמיותו — כמו צירוף מקרים שיגרום למתמטיקאים לשפוך את הקפה שלהם ולבדוק אם יש באגים ביקום.

במבט ראשון, יצירת UUID עשויה להיראות פשוטה — אחרי הכל, זו רק מחרוזת אלפאנומרית שנראית אקראית. אבל נסה לכתוב אחד בעצמך עם עט ונייר. אתה יכול לרשום 36 תווים, בטח, אבל אם תחזור על התרגיל אלפי פעמים, יופיעו דפוסים ברורים. אולי אתה מעדיף מספרים כמו 3 או 8, ומשתמש לעתים רחוקות באותיות כמו x. מחשב יכול לזהות את ההטיות האלה באופן מיידי. האקר זדוני יכול לנתח את ההרגלים שלך ולהגיע למחרוזת "אקראית" שלך תוך יום. ואז, מה אם גם תפנה למחשב ותשתמש ב-rand(), פונקציית האקראיות הקלאסית, כדי ליצור כל ספרה. זה טוב יותר — אבל לא מספיק טוב. הרבה גנרטוריים "אקראיים" בסביבות תכנות נפוצות הם פסאודו-אקראיים, כלומר הם עוקבים אחרי רצף מתמטי צפוי המתחיל מזרע פנימי, שלרוב מבוסס על זמן המערכת. אם מישהו יגלה או ינחש את הזרע הזה, הוא יכול לשחזר כל ערך שהגנרטור שלך יצר אי פעם.

אקראיות מוחלטת אינה קיימת באמת — כמו שקובייה מושלמת אינה קיימת, או זריקה אקראית מושלמת של קוביות אינה קיימת. כל תהליך פיזי או דיגיטלי עוקב אחר כללים בסיסיים כלשהם. אף על פי כן, מתמטיקאים ומהנדסים השקיעו עשרות שנים בעיצוב אלגוריתמים שמתקרבים ככל האפשר לאקראיות אמיתית. כש-Splync יוצרת UUID גרסה-4 חדש, היא לא פשוט "בוחרת מספרים באקראי" כמו לזרוק קוביות. היא מבקשת מהמערכת ההפעלה קטעים קטנים של חוסר צפיות — לדוגמה, הרגע המדויק שבו ה-CPU שלך מסיים משימה, רעש חשמלי קל בפנים החומרה, או תנודות רקע בזמני הזיכרון. חלקיקים אלו של אנטרופיה נאספים ומתערבבים ל-128 ביטים של נתונים — רצף ארוך של אחדים ואפסים. התוצאה היא קוד שכמעט בלתי אפשרי לנחש או לשחזר עבור משתמשי האפליקציה או תוקפים פוטנציאליים.

Splync משתמשת ב-UUIDs למזהים רגישים כמו מזהי משתמשים ומזהי פרויקטים, כי הם אקראיים מאוד ומאובטחים. במקביל, בשרת שלה, Splync ממירה את ה-UUIDs למספרים שלמים אוטומטיים לחיפוש מהיר וניתוח על מערכי נתונים גדולים. גישה כפולה זו יוצרת איזון בין בטיחות לנוחות — פרטיות חיצונית עם ביצועים פנימיים. המטרה של Splync היא להיות אפליקציה לניהול תקציב פשוטה, בטוחה וללא מתח. מאחורי הממשק הגלוי, אנו ממשיכים ללטש את הארכיטקטורה שלנו כדי לשמור על הכל חלק, בטוח וחכם בשקט.