hvordan vet jeg at jeg ikke er et opplyst menneske? Jo, jeg er totalt uforstående til at ikke flere er interessert i Datomic, så jeg forstår meg tydeligvis ikke på verden

👏 Jeg er veldig interessert i Datomic, og har lekt med det mange ganger, men har ennå til gode å bruke det i produksjon. Da jeg startet Vilect var jeg så nær å velge Datomic, men jeg var helt ny i Clojure også, og måtte redusere risiko. (Lære nytt programmeringsspråk og database samtidig som du starter et nytt selskap og lager et nytt produkt? YOLO!) Seks år senere har jeg en svær datamodell i Postgres. Hvordan skal man i det hele tatt begynne å tenke på en migrering fra en relasjonsdatabase til Datomic? Jeg har ikke tenkt veldig hardt på det, men det forekommer meg vanskelig. Konteksten her at jeg har en (majestetisk!) monolitt, ikke mikrotjenester.

man kunne kanskje tatt en tabell eller en chunk av domenet av gangen, eller noe sånt? Og bruke både postgres og datomic i en periode

lurer på om man klarer å uttrykke en postgres-database som en EAVT-indeks på en måte som gjør at det går noenlunde kjapt, sånn at man kan joine mellom datomic og postgres i datalog-spørringer :thinking_face:

Man mister referential integrity og transaksjoner når man skal oppdatere to databaser samtidig. Så jeg måtte valgt en del av domenet som ikke henger så tett sammen med andre deler, og heller kommunisert med resten av delene med asynkrone meldinger. Eller noe sånt.

Joins kan jo alltids gjøres på tvers av databaser i applikasjonskode, men med konsekvenser for ytelsen.

det spørsmålet blir jo fort litt annerledes i Datomic og, siden alle queries kjører i applikasjonen 🙂

@U06BEJGKD datomic er relasjonell, så den switchen er nok lettere enn du tror

Men klart, skjønner at det fremstår som en “daunting” oppgave på et stort eksisterende domene

Joa, det er relasjoner, og det er jo bare å koble id-er i applikasjonen når man leser fra de forskjellige databasene. Men at man ikke rent teknisk kan joine mellom tabeller/relasjoner på tvers av databasene vil jo gå ut over ytelsen, og øke kompleksiteten i applikasjonen. I hvert fall i migreringsperioden. Men altså, dette er rent akademisk, for jeg kommer ikke til å sette i gang med noe sånt nå. Men fantasere, det kan jeg!

man kan joine mellom datomic og hva som helst annet som er representert som EAVT - indeks-strukturen til Datomic/datalog er en protokoll man kan tilby selv. F.eks kan man joine mellom datomic og et excel-ark uten alt for mange krumspring

utfordringen blir dog å representere postgres-data på en effektiv måte, særlig om du har store datasett

kanskje en mere farbar vei er å lage en “read only replica” av (et subsett av) postgres-data som en egen datomic-database. Så kan du gjøre joins mellom din egen “ekte” datomic-database og postgres-speilingen (du kan joine mellom to ulike databaser i datomic og)

Jeg hadde nok selv bare gått for en big bang migrering. Den kan jo kjøres mange ganger i forkant for testingen sin del. Da får du også mulighet til å importere med timestamps.

Ja, jeg mente ikke at de passa bra sammen, men at det skal være greit å flytte over modellen. Men enig, her er det big bang som gjelder.

Hva med Cloud vs. On-Prem: Noen av dere som har erfaring med Cloud?

Takk! Jeg har testet Datomic litt, men aldri brukt det "skikkelig". Ønsker meg den erfaringen. Noen kjappe spørsmål: • Hvor mye koster det egentlig å bruke Datomic i prod? ◦ Hvordan skalerer Datomic-lisenskost med bruk (les/skriv/read-replikaer)? • Bruker dere alltid on-prem? ◦ hvis ja, hva bruker dere til å lagre data? Postgres?

sist jeg sjekket manglet Cloud en del essensielle ting, som excision (sletting/vasking av data mtp GDPR osv)

eneste gang jeg har brukt datomic i prod brukte vi free! Byttet nettopp til pro, kjenner ikke til detaljene siden jeg ikke er direkte involvert i prosjektet lengere

datomic har ikke write replicas forresten, man kan ha én stand by som tar over writes om den aktive dør, så man slipper å vente på en full restart

read replicas er evig, og går rett mot underliggende storage og ikke via noe spesifikke datomic-greier

Man kan bruke Datomic Starter så lenge man vil uten å betale (det gjør for eksempel http://adventur.no), men de kundene vi har vært hos har vi oppfordret til å betale for å få med support og slikt. Det koster $5000 for hvert år du vil ha med oppdateringer og support.

Det er ingen kostnader knyttet til bruk i lisensen.

Bruker bare on-prem, fordi cloud ligner mer på en tradisjonell database, hvor man må sende queries over vaieren og slikt. Mye mer smooth med ekte peers.

datomic cloud virker mest å være knyttet til de derre “serverless for Clojure”-greiene som de har laget, og ikke nødvendigvis optimalisert for stand-alone bruk og drop-in for on prem?

Noe av det feteste, og kanskje litt uventede, med Datomic on-prem er hvor stor effekt det har på koden din. Mye lettere å skrive pure kode med datomic enn med postgres.

Skal også sies at du mister retten til oppgraderinger etter ett år om du ikke betaler. Dette kan man game ved å bytte konto, men da bør man kanskje gå litt i seg selv… Jeg har hatt datomic i prod en god stund og har aldri hatt bruk for supporten til Cognitect. Jeg kan ikke engang erindre at jeg har hatt et eneste operasjonelt problem med Datomic i prod.

Det er ingen teknisk forskjell på datomic starter og datomic pro - det er bare support/oppgraderinger som skiller dem. datomic free som fantes før tror jeg ikke finnes lengre

mongo postgres

føles som mongo er et subsett av postgres, nå som postgres har JSON og greier

Veldig korrekt observert.