Kun tarvitsemme uuden avaimen, voimme ottaa yhden jo luoduista tunnuksista. Tämä lähestymistapa voi nopeuttaa asioita, sillä uuden pyynnön tullessa meidän ei tarvitse luoda tunnusta, varmistaa sen ainutkertaisuutta jne. UGS varmistaa, että kaikki tunnukset ovat yksilöllisiä, ja ne voidaan tallentaa tietokantaan, jotta tunnuksia ei tarvitse luoda joka kerta.

Koska tarvitsemme yhden tavun yhden merkin tallentamiseen, voimme tallentaa kaikki nämä avaimet:

6 (merkkiä) * 68.7B (yksilölliset avaimet) ~= 412 GB.

★Saatavuus & Luotettavuus:

Jos säilytämme yhden kopion UGS:stä, se on yksi vikapiste. Meidän on siis tehtävä kopio UGS:stä. Jos ensisijainen palvelin kuolee, toissijainen palvelin voi käsitellä käyttäjien pyynnöt.

Jokainen UGS-palvelin voi tallentaa välimuistiin joitakin avaimia key-DB:stä. Se voi nopeuttaa asioita. Meidän on kuitenkin oltava varovaisia; jos yksi palvelin kuolee ennen kuin se on käyttänyt kaikki avaimet, menetämme nämä avaimet. Voimme kuitenkin olettaa, että tämä on hyväksyttävää, koska meillä on lähes 68B uniikkia kuusikirjaimista avainta.

Käytettävyyden varmistamiseksi meidän on varmistettava, että järjestelmästä poistetaan yksittäinen vikapiste. Replication for Data poistaa yksittäisen vikapisteen ja tarjoaa varmuuskopion. Voimme pitää useita replikaatioita tietokantapalvelimen luotettavuuden varmistamiseksi. Lisäksi keskeytymättömän palvelun varmistamiseksi myös muut palvelimet tarvitsevat kopioita.

★DataStorage:

Tässä järjestelmässä meidän on tallennettava miljardeja tietueita. Jokainen säilyttämämme objekti on mahdollisesti alle 1 KB. Yksi URL-tieto ei liity toiseen. Voimme siis käyttää NoSQL-tietokantaa, kuten Cassandraa, DynamoDB:tä jne. NoSQL-valinta olisi helpompi skaalata, mikä on yksi vaatimuksistamme.

★ Skaalautuvuus:

Tukeaksemme miljardeja URL-osoitteita meidän on partitioitava tietokantamme, jotta voimme jakaa ja tallentaa tietomme eri tietokantapalvelimille.

i) Voimme partitioida tietokannan hash-avaimen ensimmäisen kirjaimen perusteella. Voimme laittaa A-kirjaimella alkavat avaimet yhdelle palvelimelle ja B-kirjaimella alkavat avaimet toiselle palvelimelle. Tätä kutsutaan nimellä Range Based Partitioning.

Tämän lähestymistavan ongelmana on, että se voi johtaa epätasapainoiseen osiointiin. Esimerkiksi sanoja, jotka alkavat kirjaimella ’Z’, on hyvin vähän. Toisaalta; meillä voi olla liikaa URL-osoitteita, jotka alkavat kirjaimella ’E’.

Voimme yhdistää harvemmin esiintyviä kirjaimia yhdeksi tietokantaosioinniksi.

ii) Voimme myös osioida tallentamiemme objektien hashiin perustuen. Voimme käyttää avaimen hash-arvoa määrittääksemme osion, johon voimme tallentaa tieto-objektin. Hash-funktio luo palvelimen numeron, ja tallennamme avaimen kyseiselle palvelimelle. Tämä prosessi voi tehdä jakelusta satunnaisemman. Tämä on Hash-Based Partitioning.

Jos tämä lähestymistapa johtaa edelleen ylikuormitettuihin osioihin, meidän on käytettävä Consistent Hashingia.

★ Cache:

Voidaan tallentaa välimuistiin URL-osoitteita, joita käyttäjät käyttävät usein. Ennen kuin UGS-palvelimet tekevät kyselyn tietokantaan, ne voivat tarkistaa, onko välimuistissa haluttu URL-osoite. Silloin sen ei tarvitse tehdä kyselyä uudelleen.

Mitä tapahtuu, kun välimuisti on täynnä? Saatamme korvata vanhemman käyttämättömän linkin uudemmalla tai suositulla URL-osoitteella. Voimme valita järjestelmäämme LRU (Least Recently Used) -välimuistin häätämiskäytännön. Tässä politiikassa poistamme vähiten hiljattain käytetyn URL-osoitteen ensimmäisenä.

★ Kuorman tasaaja:

Voitamme lisätä kuorman tasauskerroksen järjestelmämme eri paikkoihin URL-osoitteiden lyhentämispalvelimen, tietokannan ja välimuistipalvelimien eteen.

Voitamme käyttää yksinkertaista Round Robin -lähestymistapaa pyyntöjen jakamiseen. Tässä lähestymistavassa LB jakaa saapuvat pyynnöt tasaisesti taustapalvelimien kesken. Tämä LB:n lähestymistapa on yksinkertainen toteuttaa. Jos palvelin on kuollut, LB lopettaa kaiken liikenteen lähettämisen sille.

Ongelma: Jos palvelin on ylikuormitettu, LB ei tässä lähestymistavassa lopeta uuden pyynnön lähettämistä kyseiselle palvelimelle. Saatamme tarvita älykästä LB:tä myöhemmin.

★ Linkin vanhentuminen keston jälkeen:

Jos URL-osoitteen vanhentumisaika saavutetaan, mitä linkille tapahtuisi?

Voidaan etsiä tietovarastoista ja poistaa ne. Ongelma tässä on se, että jos päätämme etsiä vanhentuneita linkkejä poistaaksemme ne tietovarastostamme, se aiheuttaisi paljon painetta tietokantaamme.

Voisimme tehdä sen toisella tavalla. Voimme poistaa vanhentuneita linkkejä hitaasti määräajoin. Vaikka jotkut vanhentuneet linkit elävät pidempään, niitä ei pitäisi koskaan palauttaa käyttäjille.

Jos käyttäjä yrittää käyttää vanhentunutta linkkiä, voimme poistaa linkin ja palauttaa käyttäjälle virheilmoituksen. Tietokannastamme voidaan poistaa vanhentuneet linkit säännöllisin väliajoin suoritettavalla siivousprosessilla. Koska tallennustila halpenee, jotkin linkit saattavat jäädä tietokantaan, vaikka jättäisimme siivouksen väliin.

Poistettuamme linkin voimme laittaa sen takaisin tietokantaamme uudelleenkäyttöä varten.

★ Tietoturva:

Voidaan tallentaa käyttöoikeustyyppi (julkinen/yksityinen) jokaisen URL-osoitteen yhteyteen tietokannassa. Jos käyttäjä yrittää käyttää URL-osoitetta, johon hänellä ei ole oikeuksia, järjestelmä voi lähettää virheilmoituksen (HTTP 401) takaisin.