Rajoitteet

Seuraavat rajat kannattaa pitää aina näkyvissä:

• kaikki kyselyt eivät hyödy samalla tavalla range-readeista
• kirjoituspolku ja immutable artefakti -malli tuovat omat kompromissinsa
• suorituskyky riippuu paljon datan organisoinnista
• latenssi voi kasvaa, jos tarvittavia range-lukuja on liikaa

Esimerkkirajoite benchmarkeista

Yksi keskeinen havainto oli, että indexed_top voi olla tavumäärältään tehokas mutta silti latenssiriskinen, jos se vaatii liikaa erillisiä range-read-pyyntöjä.

Alkuperainen remote tulos:

indexed_top
  rangeReads: 46
  bytesRead: 5603
  Worker p50: 571 ms

Klusteroidun indexed-layoutin ja string-index page cachen jälkeen:

indexed_top
  rangeReads: 8
  bytesRead: 2563
  duration: 365 ms

Johtopäätös

Objektin koko ei ole enää ensisijainen ongelma. Seuraava optimointiongelma on R2:n range-read-latenssi.

Mitä ei pidä yleistää

• ettei kaikki kyselyt automaattisesti toimi muutamalla luvulla
• ettei pieni bytesRead yksin takaa hyvää käyttökokemusta
• ettei vain lukuun perustuva arkkitehtuuri ratkaise kirjoitus- tai ad hoc -kyselyongelmia