2009-11-24

Google App Engine-kokeilun tulokset täällä

Päivitys 20.5.2010: Google on nyt päivittänyt GAE:n huomattavasti paremmat profilointiominaisuudet kuin mihin tässä kommentissa viitataan, eikä 1000 hakutuloksen raja ole enää voimassa.

Asiaan vihkiytymättömille: Google App Engine on Googlen oma tuote, jonka tehtävä on ajaa päivittäiskäytössä kehittäjien rakentamaa ohjelmistoa, joka tuottaa verkkosivuston, ja tallettaa käyttäjien tiedot.

Se on suunnattu cloud-markkinoille, joka on hieno tapa sanoa että tietojenkäsittelykapasiteettia ostetaan kevyellä, joustavalla prosessilla, tilastollisen tarpeen mukaan, vähän kuin sähköä tai maitoa.

Jutun juju on siinä, että cloud-myyjä osaa ennustaa tilastollisesti, kuinka paljon kapasiteettia tarvitaan ensi kuussa, ja cloudia käyttävät yksittäiset projektit voivat hankkia kapasiteettia vakiotuotteina, vähän kuin litran maitoa kaupasta, sen sijaan että pitäisi tietää kyseisen lehmän nimi ja lempiruoka kolme kuukautta etukäteen. Kun projektit saavat nopeata joustoa yllättäviin tarpeisiin, ne onnistuvat edullisemmin, ja lähempänä aikatauluaan.

Google App Engine kilpailee cloud-markkinoilla Amazon Web Services-palveluperheen kanssa, ja Mansikki-markkinoilla PHP/MySQL-konseptin ja sitä käyttävien superhalpojen laaduttomien alustatuotteiden kanssa.

No niin, itse asiaan!

Olen testannut GAE:ta pari kuukautta aika simppelillä sovelluksella, jota olen käyttänyt päivittäin.

Aloitin kehityksen vielä silloin, kun GAE ei tukenut Javaa, joten sovellus on Pythonia.

Kehitysprosessi on varsin kömpelö. GAE-työkalut sisältävät paikallisen kehityspalvelimen, mutta siinä ei ole valmista tapaa synkronoida tietokantaa Googlen palvelimilta paikalliseen ympäristöön, joten tuotantodatasetin saaminen kehitykseen on varsin hankalaa.

Suurin ongelma minulle on kuitenkin se, että kaikki sovelluksen tieto tallennetaan Googlen omaan tietokantajärjestelmään, jonka luku/kirjoituslatenssia on erittäin vaikea ennustaa. Heidän tietokantansa ei tue SQL JOIN-rakennetta, ja se ei voi palauttaa vastauksena yhteen kyselyyn kuin 1000 tietuetta.

Toinen ongelmallinen kohta on koodin suorituskyky ja profilointi. Pääsivun luominen kestää melkein 2 sekuntia, vaikka cachetan suurimman osan datasta. Googlen profilointimetodit eivät palauttaneet mitään olennaisen hyödyllistä tietoa jonka perusteella voisin tehdä johtopäätöksiä. Lisäksi osa Googlen palvelurajapinnoista ei toimi dokumentaation mukaisesti, ja tietysti myös ihan olennaisesti eri tavalla paikallisessa kehityspalvelimessa, ja Googlen tuotantopalvelimessa.

Siirrän sovelluksen GAE:sta paikallisesti pyöriväksi Java-sovellukseksi. En suosittele GAE:ta vielä otettavaksi käyttöön, ilman varsin kattavaa tietokantahakujen testausta todellisilla tuotantotietomäärillä.

Powered by Google App Engine

Addendum: Paras tapa saada data ulos GAE:sta on http://code.google.com/appengine/articles/remote_api.html. Heillä on roadmapissa parempi importti/exportti, mutta näkee sitten.

4 comments:

  1. Hyviä ajatuksia, gae on vielä vauhdikkaasti kehittymässä ja kyllä siitä ihan kelvollinen ympäristö tulee. Tiettyihin juttuihin paremmin kuin toisiin, eli kaikkeen web ohjelmointiin tämä ei todellakaan ole paras ratkaisu.
    Yksi huomion arvoinen pointti jota ymmärtämättä ei GAE avaudu. Taustalla ei ole relaatiotietokantaa. Eli GAE, tai tarkemmin google datastore ei tule koskaan tukemaan esim SQL JOINia.
    Syy tähän on yksinkertaisesti relaatiotietokantojen huono suorituskyky. Google tuntee tämän alan hyvin, heillä on huikea määrä dataa ja siihen on päästävä käsiksi todella suurella volyymillä ja nopeasti.
    Koko GAE avautuu siis paremmin kun ymmärtää key-value storen periaatteet. Osittainhan tämä tarkoittaa perinteisten opinkappaleiden romuttamista, tietokantoja ei enää normalisoida tai suunnitella oliomalleina. Datastore ei siis myöskään ole oliotietokanta.
    ReplyDelete
  2. Sittemminhän GAE on alkanut tukea yli 1000 tietueen hakemista kerralla. Googlen infran relaatiottomuuteen ei syynä ole relaatiokantojen "huono" suorituskyky, vaan se, että heidän infransa on optimoitu map-reduce mallin tiedonkäsittelyä varten, mitä kuitenkaan GAE ei tue.

    En tiedä tarkoitatko oliotietokannalla object databasea (kuten esim. db4o) vaiko entity storea. GAE:n dokumentaatiossa kuvataan varsin yksiselitteisesti, että datastoren käyttötavaksi suositellaan entity store-mallia. Minä koen ongelmaksi sen, että datastoren latenssia on niin vaikea ennustaa, jopa varsin yksikertaisten kyselyiden tapauksessa. Yhtä lailla, sovelluksen profilointi oli varsin hedelmätöntä.
    ReplyDelete
  3. Meta: Ei paha, tää on etusivulla google-haulla "google app engine" heti google.com:n tulosten jälkeen kun google suosii suomenkielisiä sivuja (eli kun googlen käli on suomeksi)

    Varsinainen asia: Oletko huomannut, että yksittäisen haun latenssi olisi mitenkään ajasta (viikko/viikonloppu/vuorokaudenaika) riippuvainen?

    Viljo Viitanen
    ReplyDelete
  4. Viljo, en ole huomannut tälläistä. Siinä skaalassa, jossa Google toimii, on jossain päin maapalloa aina ruuhka-aika tai kahvitunti.

    Sitten tämän kokeilun, heille on tullut merkittäviä päivityksiä. Harmi kyllä, tiedon importointi ja eksportointi on yhä varsin hankalaa.

    Merkittävänä plussana kyllä toisaalta koen sen, että jätin sovelluksen pyörimään GAE:n itsekseen moneksi kuukaudeksi, ja siellä se on vaan huomaamatta pörrännyt ilman ylläpitotarvetta, ja dataa on kerääntynyt itsestään. Ilmaisen quotan cappi tullee ennen pitkää vastaan kerääntyneessä datassa, mutta aika vaivatonta sovelluksen tuotantokäyttö siellä on.
    ReplyDelete