xtdb 2022-05-26 | Slack Archive

madstap15:05:41

We are deciding how to run xt in production at work and would like some advice on the tradeoffs between running our app as an xt node or having a separate xt instance running the jar. Context: Small Data™ (<1000 entities, <1000 revisions for each entity), tx log/doc store in managed postgres. From what I understand: • App as the xt node will increase startup time and build time for the app (building indexes, more deps), decrease latency for queries (no extra network jump). • Standalone xt will increase operational complexity (extra service that we need to keep running). Are there other concerns we should consider?

➕ 1

refset21:05:28

Hey! I'd be happy to help as much as needed with your decision making 🙂 One key aspect I should mention (but probably isn't so relevant here for your Small Data™ use case) is 'ease of scaling out', which is typically a lot easier for a discrete app tier running on lightweight machines, whereas scaling out more XT nodes is inevitably more cumbersome/expensive/slow due to all the state and need for RAM.

Hukka10:05:26

Additional startup time can be eliminated by keeping the indexes. The node itself starts up very fast, it's just that building indexes can take a while. And with that amount of data, it's probably lost less than JVM start time

✔️ 1

Hukka10:05:28

My thoughts have been that keeping the indexes local to the process would help with scaling. Simpler when you don't need to figure out which layer is slower, plus no need to think about caching (since the data is local, and XTDB handles the caching from tx and doc stores)

✔️ 1

madstap13:05:46

Thanks 🙂. We have decided to use the app-as-the-xt-node approach.

😎 1

eighttrigrams21:05:21

Hey, in a REPL sessions, after doing some transactions and queries, when I call (xt/sync node) a second time, it hangs indefinitely. There are only a couple of docs in the database and i use lmbd as underlying datastore. Am I missing something?

refset22:05:00

Hey @U03GYEFN2U8 that doesn't sound right. Although you could try adding a timeout argument to the sync call to avoid the indefinite hanging. Have you got a minimal repro? Are you shutting down and restarting the database in-between at all?

refset22:05:16

Are you working with multiple threads?

eighttrigrams22:05:22

Hey @U899JBRPF. So here is my deps.edn:

{{:paths     ["src"]
 :deps      {org.clojure/tools.deps.alpha {:git/url ""
                                           :sha     "f6c080bd0049211021ea59e516d1785b08302515"}
             com.xtdb/xtdb-core           {:mvn/version "dev-SNAPSHOT"}
             com.xtdb/xtdb-lmdb {:mvn/version "1.21.0"}}
 :mvn/repos {"snapshots" {:url ""}}}

eighttrigrams22:05:02

Then I jack-in with Calva / deps.edn

eighttrigrams22:05:38

Then in the REPL :

(require '[xtdb.api :as xt]
         '[ :as io])
(def node (xt/start-node {:xtdb/index-store {:kv-store {:xtdb/module 'xtdb.lmdb/->kv-store
                                                        :db-dir      (io/file "/tmp/lmbd-i")}}
                          :xtdb/document-store {:kv-store {:xtdb/module 'xtdb.lmdb/->kv-store
                                                        :db-dir      (io/file "/tmp/lmbd-d")}}
                          }))

(xt/submit-tx node [[::xt/put {:xt/id 1
                               :pilot "Johanna"}]])

(xt/sync node)

eighttrigrams22:05:28

I execute the require and the def node parts once. Afterwards I xt/submit-tx to the node and then call xt/sync. I works. Then I submit again and call xt/sync and it hangs.

refset22:05:14

:thinking_face: that sounds weird regardless, but I do right away notice that you need to also configure the :xtdb/tx-log

eighttrigrams22:05:50

Hey, ok I'll put that in

refset22:05:58

I think technically the in-memory (default) tx-log should still work though. Thanks for sharing the repro, I'll give it a go

refset22:05:59

Ah also your versions should be consistent (ideally both "1.21.0")

eighttrigrams22:05:12

#Also sent to the channel

Yippie! 😀 Thanks so much

eighttrigrams22:05:47