https://news.ycombinator.com/item?id=27424605. Purely as a thought experiment, I’ve wondered where FoundationDB would fit into Crux’s world. To me, FDB seems most interesting as a replacement for RocksDB – resulting in every query running over a consistent view of the data, instead of each Crux node independently indexing transactions. I haven’t yet tried to figure out if that consistent view is a worthwhile goal, or if it could be achieved reasonably with Crux today via await-tx… FDB is fast, but surely (?) not as fast as RocksDB on a machine with lots of memory + NVMe flash…so the whole concept may be a non-starter with the current Crux architecture that assumes the data within RocksDB is accessible at very low latency… I’ll be the first to admit this is way outside of my practical experience, but I also find the topic interesting!

That said, I think Google Cloud Datastore and FoundationDB are somewhat comparable, and https://github.com/avisi-apps/crux-datastore

To confuse matters, it looks like RocksDB is being considered as a storage engine for FDB: https://github.com/apple/foundationdb/blob/e7d7b39f12afa8ea21aeb94972fc79cd7b5edbab/fdbserver/KeyValueStoreRocksDB.actor.cpp

you can try the redis index store if you want a centralized index, but I think you're better off using the http api if you want to scale up clients easier

Hey both, thanks for mentioning the HN thread, I hadn't spotted it yet! I've certainly looked a FDB in this context before and agree it's a viable match, but I've not attempted the integration myself. I did get quite excited about Redis last year though and wrote https://github.com/crux-labs/crux-redis FDB may well be fast enough to give acceptable query performance for many use-cases, and that may be worth it for the operational benefits, but it will certainly be a lot slower than Rocks for large & complex queries. For comparison, that Redis module was around 3-5x slower for WatDiv queries despite having all the data in RAM (...in a different process, with a bunch of marshalling / serialisation costs) and I imagine FDB could easily be an order of magnitude slower than that. Incidentally, Redis-on-Flash uses RocksDB behind the scenes too :)

oh, ninjaed by refset. I should add that HN is like 99% cargo culters and 1% people who know what they're talking about

I should add that implementing the KV protocol is quite a fun exercise though, and I'd be happy to help anyone get the generative testing working and run some performance benchmarks!

It’s certainly hard to beat Rocks for performance currently. If, hypothetically, your dataset grows such that it doesn’t fit on a single machine (thinking of the distributed aspect), how would Crux handle this scenario?

That's an interesting question. In my experience often you can shard data of that size, by business key or time (hot/cold)

> If, hypothetically, your dataset grows such that it doesn’t fit on a single machine (thinking of the distributed aspect), how would Crux handle this scenario? Crux doesn't currently offer any way around that issue scenario, you simply have to procure more local disk, but we're doing R&D behind the scenes right now on an alternative index strategy that will "separate storage from compute" and largely resolve this issue

\o/

Thanks @U899JBRPF! I hadn’t caught that crux-redis was a remote index-store implementation.

> but we're doing R&D behind the scenes right now Very cool!

@U899JBRPF Thought of your hack yesterday while in the city, buying swimming goggles. Some kid wandered through the sporting goods store with a "Redis Nerd" t-shirt on. (Rather unexpected, in my home province full of farmers.)