Tiedostojen synkronisointi: lopuksi yhtäpitävä

kirjoittanut codento 23.2.2010 kommentoi

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.

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

Hyvä tiimi

kirjoittanut codento 17.2.2010 kommentoi

Kukapa ei haluaisi ohjelmistoprojektiinsa hyvää tiimiä. Mutta mistä sellaisen saa? Ja mikä erottaa hyvän tiimin keskinkertaisesta? katsotaanpa kahta selitystä, konventionaalista ja vähän yllättävämpää.

Selitys yksi: Hyvä tiimi koostuu hyvistä tyypeistä.

Kooderien tuottavuuserot ovat valtavia. Hyvä kooderi käyttää tehtävään viidesosan siitä ajasta joka keskiverrolta kuluu, ja lopputulos on silti monin tavoin parempi. Sama pätee moniin muihinkin ohjelmistotuotannon osiin: arkkitehtuurisuunnitteluun, käyttökokemussuunnitteluun ja myös laadunvarmistukseen. Tämä erottaa kaikki nämä ammatit vaikkapa heinänteosta tai T-fordien kokoamisesta liukuhihnalla.

Jos pääsee valitsemaan tiimiinsä parhaita mahdollisia ammattilaisia joka hommaan, saanee kasaan ainakin melko hyvän tiimin. Tämä on pelkkää tervettä järkeä. Mutta ei aina riitä. Eikä siihen aina ole mahdollisuutta.

Selitys kaksi: entä… jos sen voi luoda?

Ihan yksilöiden taitotasosta riippumatta, hyvän tiimin pitää toimia yhteen. Se myös tarvitsee kelvolliset tilat ja hyvät työkalut. Joel Spolsky tiivistää tarvittavat työkalut ja työolot 12 kohdan listaansa. Ainakin tämän verran ympäristöllä on väliä.

Parikin astetta pidemmälle ajatuksen vie Alan G. Carter luentosarjassaan Programmers’ stone. Jos lukee hyväntahtoisesti ja ohittaa omituisimmat kohdat, Carterin perusidea on, että hyvän tiimin erottaa huonosta se, että jäsenet löytävät oikeanlaisen keskittymisen ja yhteisymmärryksen, ja sitä kautta itse asiassa ymmärtävät mitä ovat tekemässä tavalla, joka on sitä kokemattomalle lähes käsittämätön.

Tälläisen “Kullatun tiimin” [sic] luomiseen tarvitaan tietysti Joelinkin käsittelemät järkevät tavoitteet, hyvät työkalut, rauhalliset työtilat, tiimin pysyvyys, jne, mutta ennen kaikkea mahdollisuus ylläpitää riittävän matalaa stressitasoa.

Carterin mukaan lähes kuka tahansa ohjelmoija voisi olla kymmenen kertaa normaalia tuottavampi, mutta tätä harvoin tapahtuu, koska normaalissa softafirmassa ei ole yksinkertaisesti mahdollista ylläpitää matalaa stressitasoa. Ainakaan kokonaisen tiimin. Lukekaa koko tarina jos haluatte kattavan selityksen.

Carter sortuu välillä hörhöilyn puolelle, ja vetää neurologian tuloksista melko suoraaviivaisia sosiaalisia johtopäätöksiä, mutta perusideassa on järkeä. Kaikista tuskin voi ikinä tulla super-ohjelmoijia, mutta hyvä ohjelmointikyky ei ole geneettinen ominaisuus, vaan jotakin, mitä voi oppia. Ei helposti, vaan vaikeasti. Eikä vain yksikseen, vaan helpommin oikeassa seurassa.

P.S. Sen hyvän tiimin saa tietysti Codentolta 🙂

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Tiedostojen synkronisointi

kirjoittanut codento 1.2.2010 kommentoi

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.