Fork me on GitHub
#xtdb
<
2019-07-17
>
hoppy01:07:14

I realize I'm just battering you with questions, so sorry about that. But here's another. Aside from the jdbc database being located on (percieved) more reliable/shareable hardware, is there any percieved advantage to using that over rocksDB for the tx-log? Are you trying to leverage commodity services/replication/availability, or is there something else going on?

hoppy01:07:05

In a single-server situation, I'm not seeing any downside to rocks/rocks for tx/doc. am I missing something in my analysis?

hoppy01:07:05

I get the central shared tx-log multiple indexing client thing, but if that isn't in play...

hoppy01:07:15

The metrics on this is that we trust the one (aggressively backed up) machine to be an acceptable single point of failure in my application. I have no problem leaning on RocksDB for this job, although I'd almost prefer having a single DB for both in this case - having a chance to use RocksDB machinery to keep the backup lively and not worry about consistency problems.

hoppy01:07:28

Probably not the use case you had in mind, but compelling in my case.

refset08:07:22

@hoppy no need to apologise 🙂 crux-jdbc is really only interesting as a crux-kafka alternative. Your preference for RocksDB is very sensible. That said, I am just about to test crux-jdbc with sqlite 😉

refset15:07:05

@mitchelkuijpers just announced https://github.com/avisi-apps/crux-xodus (MIT License) via the juxt-oss Zulip. This means we now have a pure Java backend (for both KV and TxLog) as an alternative to RocksDB and LMDB - great work! 💪

parrot 20
8
mitchelkuijpers15:07:46

Will look into releasing it to Clojars tommorow probably

mitchelkuijpers16:07:20

You can now find the JAR on Clojars: https://clojars.org/avisi-apps/crux-xodus And I will be updating the README with some instrutions.