Api-muutos aggregaatti-haussa

Lajitietokeskus
1

Vastikään API:ssa on tapahtunut muutos, jossa https://api.laji.fi/v0/warehouse/query/unit/aggregate?aggregateBy - haku antaa virheilmoituksen:

{
“status”: 400,
“message”: “Maximum number of aggregateBy fields is 10”
}

mikäli haussa käytettävien parametrien määrä on yli 10.

Onko tämä pysyvä muutos?

2

Moi! Rajaa voisi kyllä nostaa, mutta tuo kymmenen tuntui minusta jo aika korkealta.

Mielenkiinnosta, kuinka monta sinulla on maksimissaan ja mitkä kentät siinä kyselyssä on mukana?

Tämä muutos liittyy siihen, että yritämme jotenkin saada suorituskykyongelmia kuriin. Ryhmittely kovin monella tekijällä on raskaampaa kuin vain parilla.

Esko / Lajitietokeskus

3

Tuotannossa oleva Luontotilastot-sovellukseni käyttää havaintohaussa seuraavia kenttiä, joita näyttää olevan yhteensä 18:

var urlString = “https://api.laji.fi/v0/warehouse/query/unit/aggregate?aggregateBy=” +
“gathering.conversions.wgs84CenterPoint.lat,” +
“gathering.conversions.wgs84CenterPoint.lon,” +
“gathering.interpretations.coordinateAccuracy,” +
“gathering.locality,” +
“gathering.interpretations.finnishMunicipality,” +
“unit.linkings.taxon.nameFinnish,” +
“unit.linkings.taxon.nameSwedish,” +
“unit.linkings.taxon.nameEnglish,” +
“unit.linkings.taxon.scientificName,” +
“unit.unitId,” +
“gathering.eventDate.begin,” +
“gathering.eventDate.end,” +
“gathering.team,” +
“unit.mediaCount,” +
“unit.linkings.taxon.orderId,” +
“unit.linkings.taxon.classId,” +
“unit.linkings.taxon.familyId,” +
“unit.linkings.taxon.phylumId&” +

Kentät tarvitaan jotta listassa voidaan näyttää haettujen havaintojen perustiedot ja kartalla havaintopisteet. Taksonomiatietoja tarvitsen, jotta voin näyttää havainnon kohdalla oikean ikonin. Sovelluksen koodi on muutaman vuoden vanhaa ja nykyään varmaan toteuttaisin monta asiaa toisin, jotta kenttiä ei tarvitasi noin paljon, mutta tällä hetkellä tämä oli ikävä yhtäkkinen muutos. Jos pystytte muuttamaan rajoja accessToken-kohtaisesti, niin pyytäisin, että nostatte kohdallani rajaa. Luontotilastot-sovelluksen käyttäjämäärät / käyttö on niin pientä, että se tuskin vaikuttaa ratkaisevasti suorituskykyynne.

4

Silmään pisti tuo unitId-sarakkeen käyttö aggregointisarakkeena kyselyssä. Jokainen unitId on uniikki, joten todellisuudessa tämä kysely ei edes ole aggregointi vaan listakysely.

Sovelluksen käyttöliittymästä en löydä mitään syytä käyttää noin suurta määrää aggregointisarakkeita samanaikaisesti.

5

Jos muistan oikein, niin en päätynyt listakyselyn käyttöön koska se toimi tuskastuttavan hitaasti.

6

Joo, kuten Tapani kirjoitti, listakysely on tähän asiallisempi. Millä rajauksilla se on hidas?

Kokeile myös laittaa jokin orderBy mukaan… Oletus on havaintoajan mukaan laskeva järjestys, ja se on hidastava tekijä. Jos järjestyksellä ei ole väliä, sorttaa vaikka unit.unitId mukaan

Esko / Lajitietokeskus

7

En ole kovin tyytyväinen tapaan, jossa API:in tuodaan ilman mitään ennakkovaroitusta muutoksia, jotka voivat rikkoa ja tässä tapuksessa rikkoivatkin tuotannossa olevan sovelluksen.

Mä en mun koodia rupea juuri nyt sen enempää testaamatta kommentoimaan, koska en muista tarkalleen muutaman vuoden takaista päätöstä käyttää aggregointia listakyselyn sijasta. Molempia tapoja kyllä testasin silloin.

8

Raja on nyt nostettu 10->20

Ajattelin, että tämä on enemmän sellainen safety-measure kuin konkreettinen breaking change. Kymmenen tekijää kuulosti minusta siltä, ettei se varmaankaan aiheuta konkreettista muutosta yhdessäkään sovelluksessa. Tarkoitus oli lähinnä estää esimeriksi vahingossa aggregointi kaikilla kentillä, joka pistäisi tietokannan melko juntturaan.

Ikävää, että sovelluksesi meni rikki!

On varmaan totta, että tiettyyn rajaan asti /aggregate voi olla suorituskykyisempi kuin /list ja olen tätä ehkä joskus joillekkin – ehkä myös sinulle – ehdottanut vaihtoehtona. Jos kenttiä tarvitaan esim 30, niin /list alkaa varmasti olla nopeampi.

Esko / Lajitietokeskus

9

Kiitos paljon! Näissä mobiilisovelluksissa on se hankala puoli, että mä en pysty lennosta tuomaan nopeaa korjausta, koska ne joutuu aina menemään Applen/Googlen -tarkastuksen läpi. Ja yleensä tarkastukseen pääsy myös kestää niissä sovelluksissa kauemmin missä päivityksiä tehdään harvoin / keräävät vähän latauksia.

Tuosta suorityskyvystä vielä, niin tuossa mun kyselyssä voidaan ladata max parikin tuhatta havaintoa kerralla tietyltä ajanjaksolta valitusta taksonista ja näköjään käytän myös orderBy=gathering.eventDate.begin. Jos vastauksena saatavien havaintojen määrä jää pieneksi ne tulevat kyllä ihan parin sekunnin sisällä. Hidastuminen alkaa kun havaintojen määrä kasvaa suureksi ja siinä tuo list/aggregate-valinta teki muistaakseni merkittävän eron.