Google App Engine, Datastore ja Firestoreen
Tutustutaan Google App Engineen, Googlen datastoreen ja Firestoreen.
Google App Engine
Google App Engine (GAE) on Googlen tarjoama pilvipalvelualusta web-sovellusten kehittämiseen ja julkaisuun.
- Sovellukset suoritetaan useilla palvelimilla
- Automaattinen resurssien skaalaus: Appengine luo tarpeen mukaan yhden tai useampia instansseja sovelluksesta. Mitä enemmän sovelluksella on käyttäjiä/verkkoliikennettä tai mitä hitaammin sovellus vastaa pyyntöihin, sitä herkemmin App Engine ottaa käyttöön useampia instansseja. Mitä enemmän instansseja on käytössä sitä nopeammin sovellus vastaa, mutta sitä enemmän sovellus myös kuluttaa palvelinresursseja ja google laskuttaa enemmän. Sovelluksen toteutuksessa on osattava huomioida useamman instanssin mahdollisuus.
- Ilmainen vähäisessä käytössä
- Standardiympäristö on käytettävissä ilmaiseksi
- Joustava ympäristö ei ole ilmainen
- Tukee useita ohjelmointikieliä: Python, Java, Go jne.
- Ei salli kirjoittamista tiedostoihin vaan on pakko käyttää tietokantaa.
- Ilmaiseksi voi käyttää vain hajautettua Datastore- tai Firestore-tietokantaa. Relaatiotietokannan ja SQL-tuen saa maksusta (Google Cloud SQL).
- Voi kehittää ja testata omalla koneellaan jos käyttää Google App Engine SDK:ta
- Katso Ohjaustehtävä 4
Google Datastore
- Datastore on NoSQL-tietokanta
- Datastore on väistymässä ja korvautuu Firestore-tietokannalla. Firestore on toiminnoiltaan hyvin samankaltainen, mutta tuo uusia ominaisuuksia
- Liitoksia ei voi käyttää Datastoren kyselyisessä. Vrt. sql-kyselyt
- Datastorea käsitellään vähän samaan tapaan kuin sql-tietokantaa käsiteltäisiin sql-alchemyn kautta
- Lisätietoja: Ohjaus 4
- Datastorea voi myös emuloida omalla koneella
- Datastoren kyselyt ovat aina casesensitiivisiä
- Datastoren rakenteessa määritelty entiteettin vanhempi-lapsi-suhde on pysyvä eli sitä ei voi jälkikäteen muuttaa
- Datastore queries
Firestore
Keskustellakko Firestore-tietokannan kanssa palvelimella vai suoraan selaimesta javascriptilla? Tämä on monesti ihan oma valinta. Ei voi sanoa kumpi olisi parempi. Firestoren kohdalla voi itse päättää kirjoittaako enemmän koodia palvelimelle vai selaimeen. Jos on kriittisempää dataa, niin palvelinpuolen koodilla on ehkä helpompi hallita kuka pääsee käsiksi. Viikkotehtävässä on kuitenkin määritelty mitkä asiat on tehtävä palvelimella ja mitkä selaimessa.
Firestore-tietokannan suunnitteleminen. Tehdäkkö yksi valtaisa dokumentti vai useamman dokumentin hierarkia? Tässä pitää viikkotehtävän yhteydessä tarkkaan miettiä miten mikäkin asia liittyy toiseen ja erityisesti mitä operaatioita näille täytyy tietokantatasolla tehdä. Mitä vähemmän on dokumentteja ja mitä vähemmän on kirjoitus- ja lukuoperaatioita, sitä halvempi Firestore on käyttää. Jokaisen dokumentin lukeminen maksaa. Jaatko tiedot kymmeneen vai yhteen dokumenttiin? Kustannuksissa on helposti kymmenkertainen ero. Välimuistilla voidaan helpottaa kustannuksien kertymistä, mutta sitä ihmetellään vasta viimeisissä tehtävissä. Yrittäkää nyt miettiä hyvä ratkaisu ilman välimuistin apua.
Jos kaiken ymppää yhteen dokumenttiin riittääkö dokumentin maksimikoko (1 Mt). Viikkotehtävän tapauksessa ei varmasti tule riittämään. Viikkotehtävätietokannan mallidatalle ehkä riittäisi, mutta jos ajatellaan, että järjestelmä olisi käytössä esim. vuosia, niin hajoaminen on vääjäämätöntä. Älkää tehkö tätä virhettä.
Lisäksi on muistettava Firestoren rajoitukset kirjoitusnopeudelle. Maksimi on 1 per sekunti per dokumentti. Ajatellaan tilannetta, jossa olisi oikea rogaining-tapahtuma menossa: Joukkueet lähtevät liikkeelle yhteislähdössä. Useita joukkueita saapuu letkassa rastille 1. Joukkueet leimaavat aivan yhtäaikaa. Jos kaikki rastileimaukset ovat yhdessä dokumentissa, yhden kirjoituksen rajoitus per dokumentti saavutetaan erittäin helposti. Tämä on Firestoressa ns. soft limit eli sen voi ylittää hetkellisesti, mutta ongelmat ovat mahdollisia. Vähintään kunkin joukkueen leimaukset täytyy tallentaa omaan dokumenttiinsa.
Joukkueen tietoja, sarjojen tietoja ja kilpailun tietoja muutetaan harvakseltaan, mutta saatetaan lukea usein. Minkälaisia kyselyjä joutuu tekemään? Onko helpompaa pitää tiedot yhdessä vai useammassa dokumentissa ja kuinka monessa? Millainen hierarkia? Tässä riittää pientä pohdittavaa.
Viikkotehtävän tietokanta kannattaa jakaa useampaan dokumenttiin. Samaan tapaan kuin reseptitietokanta. Kannattaako ihan kaikesta tehdä oma dokumenttinsa? Kustannuksien takia ei kannata. Miettikää järkevä kompromissi.
Firestoressa kannattaa myös käyttää Firestoren itse kehittämiä id:tä. Sarjassa olevia peräkkäisiä id:tä, kuten käytetään malliksi ohjaustehtävässä, kannattaa välttää.
Käyttäjien kommentit