Tiedostojen synkronisointi



Yksi Amazon S3 -talletuspalvelua usein hyödyntävä luokka palveluita on verkkolevyt ja muut tiedostojen synkronisointipalvelut. Eli palvelut, joiden avulla käyttäjä voi lukea ja kirjoittaa omia tiedostojaan usealta eri laitteelta. Esimerkkejä tällaisista ovat Dropbox ja Jungle Disk.

Tiedostojen synkronisointipalvelu muodostaa käytännössä käyttäjän laitteista hajautetun järjestelmän, jossa jokainen synkronisointiin osallistuva laite on oma noodi tätä järjestelmää. Hajautetuissa järjestelmissä on erityisiä haasteita, joista CAP-teoreema kuvaa yhtä: kolmesta ominaisuudesta C, A ja P, hajautettu järjestelmä voi yhtäaikaisesti taata ainostaan kaksi. Mitkä ovat sitten ominaisuudet C, A ja P tällaisessa tiedostojen synkronisointijärjestelmässä?

  • C: näenko täsmälleen samat tiedostot ja sisällöt jokaisella synkronisointiin osallistuvalla laitteella? (engl. consistency)
  • A: ovatko tiedostoni luettavissa ja kirjoitettavissa aina tarvittaessa, olettaen että järjestelmä yleisesti on toimivassa tilassa? (engl. availability)
  • P: ovatko tiedostoni luettavissa ja kirjoitettavissa myös kun verkkoyhteys ei toimi? (engl. partition-tolerance)

Huvin ja hyödyn vuoksi näitä määritelmiä voi nyt käyttää ymmärtääkseen paremmin mitä ominaisuuksia eri palveluilla on. Eli, mitkä yhdistelmät ominaisuuksista C, A ja P ovat eri tiedostojen synkronisointipalveluiden tarjoajat valinneet?

  • Dropbox on palvelu, jossa joukkoa tiedostoja käyttäjän laitteen paikallisessa tiedostojärjestelmässä jatkuvasti päivitetään muutoksilla jotka on tehty muilla synkronisointiin osallistuvilla laitteilla. Palvelua voi luonnehtia AP-palveluna, koska tiedostot ovat jatkuvasti luettavissa ja kirjoitettavissa niin kauan kuin paikallinen tiedostojärjestelmä toimii (A) ja samat tiedostot ovat edelleen luettavissa ja kirjoitettavissa vaikka verkkoyhteys ei toimi (P). Toisaalta kaksi laitetta voi toisistaan riippumatta tallettaa ristiriitaiset versiot samasta tiedostosta, esim. kun verkkoyhteys ei toimi (eli ei C).
  • Jungle Disk on palvelu, jossa tiedostojen sisältö ensisijaisesti elää palveluntarjoajan verkopalvelimella. Palvelua voi luonnehtia CA-palveluna: Jokainen tiedosto-operaatio vaatii synkronisen viestin lähettämistä verkkopalvelimelle (hieman yksinkertaistettuna). Tämä takaa että jokainen laite aina näkee viimeisimmän ja saman version tiedostosta, koska se joka kerta haetaan samasta keskeisestä verkkopalvelimesta (C). Lisäksi tiedostot ovat luettavissa ja kirjoitettavissa, kunhan järjestelmä, eli verkkopalvelin, yleisesti on toimivassa tilassa (A). Tiedostot eivät kuitenkaan ole luettavissa eikä kirjoitettavissa, jos verkkoyhteys ei toimi (eli ei P).

Nämä kaksi (AP ja CA) näyttävät olevan yleisimmät CAP-yhdistelmät tiedostojen synkronisointipalveluissa. Esimerkkiä palvelusta CP-ominaisuuksilla ei tule heti mieleen.

Lisäksi A:n ja P:n eroa voi tosiaan olla hankala hahmottaa. Tästä huolimatta CAP-teoreema auttaa ymmärtämään hajautettujen järjestelmien haasteita ja ominaisuuksia. Ja näyttää että jopa niin näennäisesti triviaalin sovelluksen kuin tiedostojen synkronisoinnin taustalla on merkittäviä suunnitteluperiaatteita.

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

3 kommenttia artikkeliin ”Tiedostojen synkronisointi

  1. Noiden CAP määritelmien mukaan CP on mahdoton, koska jos muut pystyvät kirjoittamaan silloin kun keskinäiset yhteydet eivät toimi, ei data voi myöskään olla konsistenttia.

    Mutta jos pitäydytään CP:ssä ja hyväksytään, ettei tietoja voi kirjoittaa niin sehän vastaa read-only cachea, jossa olevia tietoja muutetaan vain atomisesti kun kaikki tunnetut lukijat ovat yhteyden päässä (koska muuten muutokset eivät olisi konsistentteja.)

    Vai?

  2. Käsittääkseni CP-järjestelmä voisi esimerkiksi olla sellainen, joka verkkoyhteyden ei toimiessa hallitusti ilmoittaa operaation ei olevan suoritettavissa. Eli koska operaatio ei ole suoritettavissa, kirjoitus ei onnistu eikä konsistenssia rikota. Kun verkkoyhteys palautuu, operaatiot alkavat uudelleen sujumaan. Klientin pitäisi siis varautua siihen, että CP-järjestelmä voi hylätä operaation.

    P:n ja A:n eroa voi tosiaan niin kuin artikkelissa mainittu olla hankala hahmottaa, ja loppukäyttäjälle monen mielestä esiintyä melkein samana. Jeff Darcy yrittää hahmottaa eroa käsitteillä “request availability” ja “node availability”.

    Viimeiseksi, CAP-teoreeman A-ominaisuus edellyttää sekä kirjoitus- että lukuoperaatioiden toimivuutta. Tämän muuttamisen pelkästään lukuoperaatioihin muuttaa edellytyksiä huomattavasti, eikä kyseessä enää ole hajautettua järjestelmää CAP-teoreman merkityksessä, vaan jotain muuta.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *