datahike

https://datahike.io/, Join the conversation at https://discord.com/invite/kEBzMvb, history for this channel is available at https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/datahike
whilo 2020-11-18T05:06:16.087200Z

Thanks @mpenet. I left this in there originally, because I wanted to give credit to David Greenberg. If you think this is confusing, which I agree it can be, then we should update the pointer.

2020-11-18T12:44:37.088400Z

You could update the link while still having credit for the original work to DG.

mpenet 2020-11-18T12:47:21.089Z

yup, it's a bit confusing for people interested in using hh-tree separately I think. They always hit the (very outdated) original repo

2020-11-18T13:06:44.089400Z

@whilo Just a couple of additional thoughts: 1. Using a separate tx log offers you the theoretical option of switching away from hitchhiker-trees. (I know, I know it’s called dataHIKE :)). 2. With distributed transactor, I presume the implication is that more than one machine could theoretically write txs to storage? Presumably you’re doing conditional writes. This could create serious bottlenecks as different machines race to write. So is the plan to forward txs to a single machine? And perhaps use consistent hashing to assign all txs for K database to V machine? I think this would work well if all transactor machines are “near” each other in a cluster in the cloud, and might still work well enough if they’re “far apart,” say in different clouds.