Jeg har testet litt, ikke funnet noe jeg ikke liker! Men jeg har ikke kjørt XTDB i prod. Hva er du ute etter? De som lager det henger på #xtdb og er lette å snakke med :)

lurer på hvor man møter veggen i forhold til datomic 🙂

har et vagt minne av å ha kikket på det, og det var et eller annet kritisk som går an i datomic og ikke i XTDB :thinking_face: Håper jeg ikke bare sprer FUD nå

Da bør noen andre som kan mer ops enn meg mene noe!

> A XTDB ClusterNode system provides sequential consistency by default due to the use of a single unpartitioned Kafka topic for the transaction log

noice

> There is no support for […] accessing the log and history directly hmm

ah, der var den store forskjellen - XTDB er documents, ikke facts. Du gjør en PUT på hele dokumentet, altså må alle facts for hele dokumentet alltid være med. Du har ikke facts med cardinality som i Datomic

(xt/db) sier: > Returns a DB snapshot at the given time. The snapshot is not thread-safe. :thinking_face:

Hmm, jeg trodde det var noe som het tx-log, men nå finner jeg ikke det i dokumentasjonen.

definitivt fordeler og ulemper med facts. Har til gode å se en hyggelig måte å jobbe med f.eks manuell sortering av items i datomic, blir en del krøll å vedlikeholde det via facts, mot for et dokument hvor du bare kan sende inn et array

Fant noe: https://docs.xtdb.com/clients/1.21.0/http/#tx-log

Det finns tre stora skillnader. Facts vs documents, unitemporal vs bitemporal och schema vs schema-less

Utöver det en del andra skillnader som också är stora, men påverkar inte i lilla stor grad

lurer på om det som manglet når jeg så på det var joins og relationships og sånt, men det ser ut til å være på plass nå

Exempelvis så indexerar xt allt som är på den första nivån i ett dokument

Du kan även använda xt som en enkel version av en grafdatabas

Datomic er også graf-database. Kan gjøre rekursive spørringer om du trenger.

@U0MKRS1FX hvis du syns at "dokument" gir god nok granularitet så kan du jo også i datomic lagre en liste som edn hvis du ikke ønsker å manuelt vedlikeholde rekkefølgen.

Jeg syns facts og skjemamodellen til datomic er helt fantastisk, den gjør det så lett å jobbe med data, bygge ut skjemaet over tid, og la systemet vokse. At man spesifiserer enkeltattributter men aldri sier noe om entiteten som helhet er "peak clojure" og gir masse fleksibilitet.

Nå har jeg ikke testa xt, så det er sikkert mye fint der. Men entusiasmen min døde ved "skjemaløs dokumentdb"

poeng :thinking_face: Vet ikke om det er noen størrelsesbegrensning på xtdb-docs, men du får vel plass til en ganske stor liste i en Datomic-fact

rakk aldri å skjønne om det er hard eller soft limits på størrelsen til en fact i Datomic :thinking_face:

Om jag kommer ihåg rätt så har du en hard limit på 64kb

@U9MKYDN4Q Datomic som grafdb: Hur mycket påverkas performance i datomic i grafqueries vid joins som inte är indexerade?

Jeg har ikke veldig mye erfaring med å bruke datomic som graf-database. Men performance blir vel som vanlig i datalog: så lenge du har de mest diskriminerende reglene først får du best ytelse. Men du må jo ikke bruke queries heller, kan også navigere data via entities

jeg skal snakke om Datomic på javazone i år, så jeg skal grave litt i xtdb. Da blir det enten et segment med “endelig finnes det et verdig open source alternativ” eller “dette er grunnen til at granularitet på facts er essensielt”

Cloud: > Strings are limited to 4096 characters. https://docs.datomic.com/cloud/schema/schema-reference.html