Ang Dual Identifier Approach ng Splync: UUID at Auto-Incremented Int

Sa database ng Splync, bawat user—at bawat proyekto—ay kinikilala sa pamamagitan ng dalawang magkaibang ID: isang UUID at isang auto-incremented integer. Ang auto-incremented integer ang mas kilala ng karamihan—isang simpleng bilang: 1, 2, 3, at iba pa. Ginagamit ng Splync ang mga integer na ito sa loob ng server database para ayusin halos lahat ng table dahil simple, mabilis, at epektibo ito para sa joins. Gayunpaman, hindi namin inilalantad ang mga internal number na ito sa app. Halimbawa, kung ikaw ang ika-42 na user na nag-sign up, ang internal ID mo sa database ay 42. Ngunit hindi mo makikita ang "42" sa iOS app. Sa halip, ang app ay gumagamit ng UUID para i-represent ka. Ipinapahayag din namin ang parehong approach sa mga proyekto—ang project ID ay maaaring "7" sa loob ng database, ngunit palaging gumagamit ng mahabang UUID ang app para sa pagtukoy dito.

Ang UUID ay nangangahulugang Universally Unique Identifier. Ang Splync ay gumagamit ng bersyon 4, variant 1 UUIDs, na sumusunod sa RFC 4122—isa sa mga pinakaginagamit na pamantayan. Isa itong random na generated string na mukhang 949ca11c-a6ed-48a3-b40a-fa9727494917. Karaniwang isinulat ang UUID bilang 32 hexadecimal na karakter na nahahati sa limang bahagi na pinaghihiwalay ng hyphens. Dinisenyo ito upang maging globally unique, ibig sabihin ay hindi ito magkakaroon ng parehas kahit sa iba't ibang server o database. Matematika, mayroong humigit-kumulang 16^32 = 2^128 na posibleng kombinasyon. Gayunpaman, dahil anim na bits ang nakalaan upang tukuyin ang variant at bersyon, ang kabuuang bilang ng natatanging version-4, variant-1 UUIDs ay humigit-kumulang 2^122, o mga 5.3 x 10^36—isang napakalaking bilang na tumitiyak ng praktikal na pagka-unique.

Ang bawat pares ng UUIDv4 ay may humigit-kumulang 1 sa 5.3 × 10^36 na tsansa na magtugma. Napakaliit ng numero na halos hindi ito umiiral sa imahinasyon ng tao. Upang maipakita ito, isipin mo na nagrorolyo ka ng 47 dice nang sabay-sabay. Ang tyansa na makuha ang lahat na uno—bawat die ay nagpapakita ng "1"—ay mga 1 sa 6^47, o humigit-kumulang 1 sa 3.7 × 10^36. Iyan ang parehong order ng magnitude gaya ng UUID collision. Ngayon, isipin ang bawat tao sa mundo—mga walong bilyon sa atin—na nagrorolyo ng 47 dice bawat millisecond sa loob ng isang trilyong taon. Iyan ay mga 2.5 × 10^32 kabuuang pagsubok. Kahit na pagkatapos ng lahat ng iyon, ang tsansa ng isang tao, sa kahit saan, na makakuha ng 47 uno nang sabay-sabay ay magiging isa lamang sa sampung libo. Iyan kung gaano kaimposible para sa dalawang UUIDv4 na magtugma. Hindi ito "bihira." Ito ay kosmikal na katawa-tawa—isang uri ng pagkakataon na magpapabagsak sa mga mathematicians ng kanilang kape at paiimbestigahan ang uniberso para sa mga bug.

Sa unang tingin, maaaring mukhang madali ang pagbuo ng UUID—pagkatapos ng lahat, ito'y parang random na alphanumeric string. Pero subukan mong isulat ito gamit ang panulat at papel. Maaari mong isulat ang 36 na character, oo, ngunit kung uulitin mo ang gawain libu-libong beses, lilitaw ang malinaw na pattern. Baka pabor mo ang partikular na mga numero tulad ng 3 o 8, at bihira mong gamitin ang mga letra tulad ng x. Ang computer ay kayang agad matukoy ang mga bias na iyon. Ang isang masamang hacker ay maaaring suriin ang iyong mga ugali at paliitin ang iyong "random" na lihim na string sa loob ng isang araw. Pagkatapos, paano kung lumapit ka rin sa isang computer at tinawag ang rand(), ang klasikong random function, para bumuo ng bawat digit. Mas mabuti iyon—pero hindi pa rin sapat. Maraming "random" na number generator sa karaniwang programming environments ay pseudorandom, ibig sabihin ay sumusunod sila sa mahuhulaan na matematikal na pagkakasunod mula sa isang internal seed, na karaniwang batay sa oras ng sistema. Kung may makakaalam o makahula ng seed na iyon, kaya nilang ulitin ang bawat value na kailanman ay nakuha ng iyong generator.

Walang perpektong randomness—tulad ng walang perpektong die, o perpektong random na roll ng dice. Ang bawat pisikal o digital na proseso ay sumusunod sa ilang batayang patakaran. Gayunpaman, ang mga mathematician at engineer ay gumugol ng mga dekada sa pagdidisenyo ng mga algorithm na halos kasing lapit sa tunay na randomness. Kapag ang Splync ay lumilikha ng bagong version-4 UUID, hindi lang ito basta "pumipili ng mga numero nang random" tulad ng pagro-roll ng dice. Humihingi ito sa operating system ng maliliit na bakas ng kawalang katiyakan—halimbawa, ang eksaktong sandali na ang iyong CPU ay natapos sa isang gawain, mahinang ingay ng kuryente sa loob ng hardware, o mga pagbabago sa oras sa memorya. Ang mga fragment na ito ng entropy ay kinokolekta at hinalo sa 128 bits ng data—isang mahabang sunod-sunod ng mga uno at sero. Ang resulta ay isang code na halos imposible hulaan o ulitin para sa mga user ng app o potensyal na mga masamang attacker.

Gumagamit ang Splync ng UUIDs para sa mga sensitibong identifier tulad ng user IDs at project IDs, dahil napaka-random at secure nito. Kasabay nito, sa loob ng server nito, kino-convert ng Splync ang mga UUIDs na iyon sa auto-incremented integers para sa mas mabilis na paghahanap at analytics sa malalaking datasets. Ang dual-identifier approach na ito ay naghahanap ng balanse sa pagitan ng kaligtasan at kaginhawahan—external privacy na may internal performance. Ang layunin ng Splync ay maging isang stress-free, simple, at secure na budget-tracking app. Sa likod ng nakikitang UI, patuloy naming pinapaganda ang aming arkitektura upang mapanatiling maayos, ligtas, at matalino ang mga bagay.