Fork me on GitHub

If I recall correctly every node has to be able to hold the entire kv-store contents, are there any plans for future sharding? (I imagine it's quite tricky given the query results "laziness"/snapshoting needs)


hi @mpenet there are sharding discussions in the works, particularly for the underlying kv-store holding documents.


oh, on github or internal for now?


I am starting to actually use crux on a personal project, really having fun so far

🙂 8

Sharding discussions have been internal for the most part because we aren't ready to commit to anything and don't want to get anyone too excited. The short answer is that have mapped out the spectrum of what could be done to shard with the current design, but we are also looking at alternative approaches like segment based indexes, k2-Trees and natively distributed KV stores such as:


have you considered something similar to Datomic, where the indexing happens in the Transactor and indexes are written to shared storage that can be (lazily) accessed by nodes/peers?


Hi, yep we have definitely pondered how to gain the benefits of the Datomic transactor/indexing approach, you can read more about the trade-offs here: -- the current Crux architecture, where every node validates transactions and performs indexing, was the easiest thing to build initially but we have much grander ambitions for the future

♥️ 4

It would be great to talk more about your use-cases and what kinds of sharding constraints you would be able to tolerate. Certainly if you have a project in mind we are very open to collaboration and joined-up planning!


I am just toying with that project at the moment. The sharding issue is just something I was wondering about, so far it seems like a weakness crux has for scaling horizontally with very large datasets, but I guess it's not a big concern for now (alpha stage)


Ah okay, good to know. We haven't tested at vast scale yet, but Rocks is definitely good for a few TBs