PostgreSQL-tietokanta PostGIS-laajennoksella sekä GeoServer-palvelinohjelmisto muodostavat monen paikkatietoja käsittelevän ja jakelevan organisaation arkkitehtuurin keskeiset komponentit. Pienimuotoisessa käytössä tämä ohjelmistot toimivat oikein hyvin ilman laajempia konfigurointitarpeita, mutta vaativampi käyttö edellyttää nopeasti syvempää asiantuntemusta ja esimerkiksi klusterointia. Tässä blogikirjoituksessa käydään läpi muutamia vinkkejä, jotka nousivat vahvimmin esille hiljattain toteuttamassamme asiakasprojektissa. 

Niin tylsältä ja ympäripyöreältä kuin se kuulostaakin, parhaat ratkaisut riippuvat aina täysin käyttötapauksesta. Muutamia kysymyksiä kannattaa kuitenkin pohtia etukäteen:

• Käsitteletkö vain rasteri- tai vektoriaineistoja? 
• Onko aineistoa megoja, gigoja vai teroja? 
• Käytetäänkö aineistoja dynaamisesti selainsovellusten kautta vai esimerkiksi satunnaisesti QGISillä aineistoa muokaten? 
• Millaisia ovat aineistojen käyttäjämäärät?
• Millaisella syklillä aineistot päivittyvät?

Nämä ja monet muut tekijät määrittävät optimoinnin askeleet. Tämän blogin tarkoitus on kuitenkin antaa yleiskatsaus aiheeseen ja vinkkejä etenemisen suunnista. 

Paikkatietoaineistot kuntoon 

Suorituskyvyn optimointi kannattaa aina tehdä systemaattisessa järjestyksessä, eli aloittaa helpoista muutoksista, joilla voi saada isoja vaikutuksia aikaan. Käytännössä tämä tarkoittaa, että kannattaa käydä ensin läpi aineistoformaatit ja matalan tason konfiguraatiot huolella, ennen kuin lähtee muokkaamaan esimerkiksi tietokannan tai GeoServerin edistyneitä konfiguraatioita. 

Rasteriaineistojen osalta esikäsittely on tärkeää. Yleisenä hyvänä käytäntönä voi seurata Cloud Optimized Geotiff (COG)-määritystä. Se mahdollistaa aineistojen tehokkaan tallennuksen objektivarastoihin (esim. Amazon S3) ja tehokkaan kyselyn, mutta samaan aikaan se näyttäytyy aivan samankaltaisena aineistona kuin normaali GeoTiff. Tärkeintä rasteriaineiston suhteen on muistaa seuraavat seikat:

1. Aineisto on kompressoitu käyttötarkoitukseen sopivalla tavalla.
2. Aineisto on tiilitetty käyttötarkoitukseen sopivalla tavalla.
3. Aineistolle on generoitu sisäiset overview-kuvat.

Vektoriaineistojen kanssa on hyödyllistä muistaa seuraavat asiat:

1. Vektoriaineistot tulee varastoida paikkatietokantaan (PostgreSQL/PostGIS).
2. Aineistojen kaikille geometriatiedoille on luotu tietokantaan spatiaaliset indeksit.
3. Aineistoille on luotu muilta osin järkevät tietokantaindeksit ml. primääriavaimet.
4. Aineistot on tallennettu yleisimmin käytettyihin koordinaattijärjestelmiin, joten koordinaattimuunnoksia ei tarvitse tehdä lennossa.
5. Mittakaavarajoja kannattaa hyödyntää GeoServerin tyyleissä tietokannasta kyseltävien kohteiden lukumäärän rajoittamiseksi.

Esimerkiksi aineistojen yleistysoperaatio on yksi esimerkki suuresta suorituskykyhyödystä, joka on täysin riippuvainen käyttötapauksesta. Jos aineistoilla tehdään tarkkaa laskentaa, ei mahdollisuuksia yleistyksiin juurikaan ole. Jos sen sijaan käyttökohteena on vain karkean tason visualisointi, voi aineistoja yleistämällä saavuttaa merkittäviä suorituskykyhyötyjä. 

Rasterit tietokantaan? 

Edellä mainitut vektoriaineistojen käsittelyvinkit ovat hyvä lähtökohta PostGISin optimointiin. Suorituskykyhyötyjen hakeminen rasteriaineistojen tallennuksella kokonaan tietokantaan on järkevää vain harvoissa erityistapauksissa. 

PostGISin rasteriaineistojenhallinta on versiosta 3 ylöspäin siirretty jälleen omaan laajennokseensa. Jos rasteriaineistoille tehdään paljon analyysejä ja niiden käyttötapaukset ovat monipuolisia sekä ne liittyvät muihin samassa tietokannassa sijaitseviin vektoriaineistoihin, voi rasterilaajennoksen käyttö olla tarkoituksenmukaista. Jos sen sijaan rasteriaineistoja vain tallennetaan ja jaetaan eteenpäin, ei rasteriaineistojen tallentamisesta tietokantaan ei ole juurikaan mainittavaa hyötyä suhteessa niiden käyttämiseen suoraan levyltä. Tästä syystä rasteriaineistojen suorituskyvyn parantamisen näkökulmasta keskeiset tekijät ovat aineistojen tiilitys ja  tallennus välimuistiin mahdollisuuksien mukaan.

Rasteriaineistojen tallennusmenetelmissä PostGISin näkökulmasta puhutaan in-DB ja out-DB ratkaisuista. 

• in-DB:n tapauksessa rasteri tallennetaan objektina tietokantaan byte stream -muodossa. Käytännössä tässä ei tapahdu pakkausta. Hyvänä puolena tässä ratkaisussa on, että kaikki rasterit tallentuvat yhteen paikkaan. Kuitenkin jos käyttötapauksiin ei liity rastereiden analyysiä (esim. useat ilmakuvat), ei tällöin ole tarvetta hyödyntää esimerkiksi PostGISin rasterianalyysifunktioita, ja konkreettiset hyödyt tietokantaan tallentamisesta jäävät vähäiseksi. Lisäksi jos tarkoitus on vain hakea rasteridataa, ei PostGIS ole tähän nopein ratkaisu. 
• Out-DB on huomattavasti tyypillisempi tapa tallentaa rastereita PostGISiin. Tällöin tietokantataulu sisältää rasterin rajauksen (bounding box) ja viittauksen ulkoiseen tiedostoon levyjärjestelmässä.

Enemmän irti PostgreSQL:stä shardauksella

Jos tietokannassa käsitellään valtavia aineistomassoja, voivat aineistojen peruskäsittelyn jälkeen tietokannan optimoinnin ratkaisut tulla ajankohtaisiksi. Kannattaa siis siirtää katse PostGISistä PostgreSQL:n suuntaan. Optimoinnin keinoja ovat esimerkiksi PostgreSQL-konfiguraatiotiedostojen kautta tehtävät muutokset tai koko ympäristön skaalaus.  

Vertikaalinen skaalaus (scaling up) tarkoittaa yhden palvelimen muistin, prosessoritehon tai levytilan lisäämistä.  Yhden palvelimen sisällä tietokanta voidaan myös osioida (partitioning), jolloin data kirjoitetaan uudelleen pieniin kokonaisuuksiin yhden tietokantapalvelimen sisällä. Horisontaalinen skaalaus tarkoittaa tietokannan hajauttamista useammalle palvelimelle.  Suoraviivaisin ratkaisu on tehdä replikoituja tietokantoja, joiden lukua ja kirjoitusta hallinnoi yksi master-kanta.

Koko tietokannan replikoinnin sijaan data voidaan myös hajauttaa osiin useammalle tietokantapalvelimelle. Tällöin puhutaan optimointimenetelmästä nimeltään sharding. Siinä valitaan yksi avainsarake, jonka mukaan tiedot hajautetaan eri tietokantanoodeille.  Shardaus tuo suorituskykyhyötyjä, mutta myös yhden abstraktiokerroksen lisää kokonaisuuteen. Shardaus ei välttämättä sovi parhaalla tavalla analyyttisiin kyselyihin, jossa haetaan kerralla lähes kaikki taulun data. Tällöin kyselyn pitää käydä hakemassa ja yhdistämässä datat eri palvelimilta. Datalle pitää myös tehdä ajoittain uudelleenshardaus, jossa data hajautetaan palvelinten välille. 

Yksi esimerkki PostgreSQL:n shardaukseen on avoin klusterointiratkaisu Citus, josta on tarjolla oma avoin PostgreSQL-laajennusosa. Cituksen rakenteessa yksi koordinaattori (Coordinator node) jakaa kyselyitä eteenpäin toisilla palvelimilla sijaitseville tietokannoille (Worker node). Citus mahdollistaa myös automaattiseesti replikoinnin kautta high availability -ympäristön, jossa yhden palvelimen ongelmatilanteessa kyselyt ohjautuvat automaattisesti muille klusterin noodeille. Citusta on hyödynnetty juuri paikkatietoaineistojen ja PostGISin kanssa.

GeoServerin optimointi ja klusterointi

Klusteroinnilla voi parantaa myös GeoServer-ympäristön suorituskykyä ja toimintavarmuutta. Klusteroinnilla tarkoitetaan usean GeoServer-instanssin pyörittämistä rinnakkain jaetulla konfiguraatiolla. Klusterointiin on kaksi eri ratkaisuvaihtoehtoa; aktiivinen ja passiivinen. 

• Passiivinen klusterointi tarkoittaa useamman GeoServer-instanssin toimintaa klusterissa jaetun datahakemiston kanssa. Valtaosa GeoServerin asetuksista, kuten julkaistut tasot ja tietolähteet, varastoidaan nk. datahakemiston sisällä oleviin XML-tiedostoihin. Passiivisessa klusterissa kaikki klusteriin osallistuvat GeoServer-instanssit lukevat konfiguraationsa samasta datahakemistosta, joka voi sijaita esim. verkkolevyllä. Täten tehdyt konfiguraatiomuutokset vaikuttavat kaikkiin klusterin instansseihin tietyin varauksin, joista lisää myöhemmin.
• Aktiivisessa klusterissa jokainen klusteriin osallistuva GeoServer säilyttää oman paikallisen datahakemistonsa ja täten oman konfiguraation. Tiettyyn instanssiin tehdyt konfiguraatiomuutokset eivät täten vaikuta muihin klusterin instansseihin. Eri instanssien konfiguraatioiden synkronoinnista vastaa erityinen middleware-ohjelmisto, joka vastaa konfiguraatiomuutosten havaitsemisesta ja migraatiosta instanssien välillä.

Eräiden GeoServerin kehittäjien mukaan passiivinen klusterointi sopii aktiivista klusterointia paremmin 90% eri käyttötapauksista. Passiivisen klusteroinnin etuna on verrattainen yksinkertaisuus, sillä sen toteuttaminen ei edellytä ylimääräistä middleware-kerrosta.

Klusterointi on järkevintä toteuttaa kontitusratkaisuja hyödyntäen (esim. Docker). Sovelluskonttiin voidaan asentaa GeoServerin lisäksi kaikki sen tarvitsemat riippuvuudet. Mukaanpakattujen riippuvuuksien myötä kontitus helpottaa myös järjestelmän ylläpidettävyyttä. Useissa valmiissa imageissa on lisäksi esikonfiguroitu GeoServeriä ja Tomcatia yleisten hyvien käytäntöjen mukaan. 

Yksittäisen GeoServer-instanssin suorituskykyä voidaan parantaa Java Virtual Machinen (JVM) konfiguraatiolla sekä GeoServerin omien asetusten optimoinnilla. On kuitenkin huomioitava, että tätä kautta ei monissakaan käyttötapauksissa saavuteta merkittävää parannusta suorituskyvyssä. Keskeinen seikka GeoServerin optimoinnissa on myös välimuistikerros ja karttatiilien hyödyntäminen mahdollisuuksien mukaan esimerkiksi GeoWebCachen avulla. Dynaamiseen WMS-tasoon verrattuna tiilitetty WMTS-karttataso latautuu 10 – 100 kertaa nopeammin, mikäli taso on kokonaan välimuistissa. 

Optimaaliset ratkaisut asiakaskohtaisesti

Ei ole olemassa yleisesti parhaita käytäntöjän aineistojen käsittelyyn tai optimaaliseen paikkatietoarkkitehtuuriin. Englanniksi puhutaan usein termistä “low hanging fruit”, jonka kautta voi ajatella optimoinnin askelmerkkejä. Nämä matalalla roikkuvat hedelmät tarkoittavat helposti tehtäviä muutoksia, joilla saa eniten muutosta aikaan. 

Jos haluat syventyä edistyneempien konfiguraatioiden maailmaan tai kuulla mikä voisi olla paras ratkaisu juuri sinun tarpeisiisi, otathan meihin yhteyttä!

Gispo

Gispo on suomalainen avoimen lähdekoodin paikkatietotalo, jonka palveluihin kuuluu paikkatietokonsultointia, sovelluskehitystä, koulutusta sekä ylläpitoa ja tukea.