Aikaisemmassa kirjoituksessa käsiteltiin tiedostojen synkronisointipalveluja hajautettujen järjestelmien näkökulmasta. Palveluita luokiteltiin CAP-käsitteen mukaan riippuen missä yhdistelmissä eri hajautettujen järjestelmien ominaisuuksia tuettiin.
Yksi kiinnostavimmista luokista on AP-palvelut, jotka uhraavat jatkuvan yhtäpitäväisyyden (C = engl. consistency) saavuttaakseen muita haluttuja ominaisuuksia (A = engl. availability, P = engl. partition-tolerance). Tähän luokkaan kuuluvat muuan muassa niin kutsutut “lopuksi yhtäpitävät” (engl. eventually consistent) palvelut. Lopuksi yhtäpitävä tarkoittaa tiedostojen synkronisointijärjestelmässä, että vaikka kahden tietokoneen tiedostot hetkellisesti voivat haarautua eri versioihin, erot ennen pitkää kuitenkin ratkaistaan järjestelmällisesti ja yhtenäistetään yhteen sovittuun versioon.
Kiinnostavaa näissä lopuksi yhtäpitävissä järjestelmissä on, mitä algoritmia käytetään erojen ratkaisemiseen. Hankalimmillekin tapauksille, kun esimerkiksi samaa tiedostoa on yhtäaikaisesti muokattu eri tavalla kahdella eri tietokoneella, pitäisi löytää tapa yhdistää haarautuneet versiot. Esimerkkejä lähestymistavoista ovat:
- Jompikumpi versioista heitetään pois, esimerkiksi vanhempi
- Molemmat säilytetään, mutta esim. vanhempi uudella nimellä
- Kysytään käyttäjältä tapauskohtaisesti
Esimerkiksi Dropbox on valinnut ratkaisun jossa vanhempi versio tallennetaan järjestelmään kopiona nimellä, joka viittaa siihen että se on haarautunut versio. Applen iDisk toisaaltaan (tapauksessa jossa ollaan valittu nk. offline synchronization) kysyy käyttäjältä kumpi versio tulee säilyttää kun tiedosto on haarautunut.
Kun tiedostojen synkronisointipalvelujen käyttö yleistyy yhä enemmän, on hyvä ymmärtää niiden ominaisuudet. Mukaan lukien mitä tapahtuu tiedostoille kun haarautuneet versiot tiedostoista yhtenäistetään.
If you enjoyed this article, please consider sharing it!
Amazonin SimpleDB tarjoaa eilisestä lähtien myös Consistent read -vaihtoehdon suorituskyvyn ja latenssin kustannuksella. Tosin varaavat oikeuden pudota eventually consistent -malliin: “Even under extreme failure scenarios, such as complete datacenter failures, SimpleDB is architected to continue to operate reliably. However when one of these extreme failure conditions occurs it may be that the stronger consistency options are briefly not available while the software reorganizes itself to ensure that it can provide strong consistency.”
http://www.allthingsdistributed.com/2010/02/strong_consistency_simpledb.html .
Kiitos linkistä. Tuo vaihtoehtojen antaminen taitaa olla merkittävä kehitys tulevaisuudessa, eli että asiakas voi joustavemmin valita mitä eri yhtäpitäväisyysmalleista haluu käyttää (jopa pyyntökohtaisesti).