clojure-norway 2023-05-01

Tusen takk til Ardoq som sponser abonnementet for meetup gruppa vår 🙇

❤️ 7

➕ 3

Kodemaker-folk (@magnars f.eks.): de har skrive om ytelse på Datomic spørringer - at det skalerer bra. Spørsmål: Kor mange datoms (`datomic.api/db-stats`) er det då snakk om i databasen? Og kor komplekse er spørringane? Me/eg har hatt ein del utfordringar med Datomic spørringar, blant anna OOM. Datomic har ingen query planner. Det er lett å få kryssprodukt => OOM, synest eg iallefall. Eg har brukt mykje tid på å få datomic queries til å gå raskt nok. I den aktuelle databasen er det p.t. 220 millioner datoms. Usikker på kor mykje antall datoms har å seie, men det gjev ein viss peikepinn.

cjohansen06:05:39

ca 30mill i vår største database 🙃 Queries i prod-kode er ganske simple, vi bruker primært entity-api-et for å hente data. Vi gjør noen mer sammensatte queries via REPL-et for innsikt og support-arbeid.

cjohansen06:05:05

Magnar har tilgang på flere produksjonssystemer enn meg, antageligvis med mer data i.

magnars07:05:12

Har aldri opplevd OOM i et Datomic query, så det var nytt for meg. Datomic peers er jo veldig glade i minne, ettersom de får bedre ytelse av å ha flere blocks lett tilgjengelig, så jeg har alltid gitt dem røslig (tenk 4G). Kan det være der det har strandet, @UGJE0MM0W? Når det gjelder query planner, så finnes det nå noe: https://docs.datomic.com/pro/api/query-stats.html

Ivar Refsdal20:05:52

Takk for svar 🙂 Per no har containerene 8 G minne. Vil tru dei hadde 16 G når dei gjekk ned. Takk for query-stats-lenka, eg har registrert at det har kome, men ikkje fått sett på det. Poenget mitt var mest å utfordre litt dette med at spørringar i Datomic skalerer så bra. Det står også i dokumentasjonen at ein som klient/peer bør https://docs.datomic.com/pro/best-practices.html#most-selective-clauses-first. For oss kom OOM-ene i to "runder". Ein sumar nådde databasen tydelegvis ein kritiske størrelse, og byrja å OOM-e, utan at ein hadde gjort nokon endringar. Feilen i vår kode var då at den lagde eit kryssprodukt som vart for stort. Den andre OOMen var (for meg) meir kryptisk, og handla om at unpacking av vektorer i input kan resultere i queries som kan gje OOM. Eg har dokumentert denne oppførselen i https://gist.github.com/ivarref/0d3d34eeeffbc4625d6120727368e405#file-datomic-oom-clj-L75 og var i kontakt med Datomic support om det, men eg fekk ikkje noko gehør for at dette var ein bug. Gisten er ein variant av problemet me hadde i prod. Takk for tilliten og spørsmål om meetup 🙂 Eg bur i Bergen diverre. Når tida tillet det, så har eg lyst til å skriva litt om desse tinga.

👍 4

magnars09:05:14

Det slår meg at det er temmelig sjelden at jeg skriver queries. For det meste bruker jeg entity-APIet. Jeg har også gått rett i indexen til tider.

👍 2

cjohansen09:05:58

Ja, som jeg nevnte tidligere: få og enkle queries i prod-kode. Jeg bruker nok mest queries “for hånd” fra REPL-et for å stille nysgjerrigheten

👍 2

cjohansen19:05:22

Tror aldri jeg har fått OOM på et query. Litt usikker på antall datoms, men antageligvis mindre enn du har.

cjohansen19:05:42

Hvor mye minne har du på prosessene dine?

2023-05-01

Channels