Fork me on GitHub
#xtdb
<
2021-09-07
>
teodorlu07:09:20

Hello! I'm trying to understand how Crux scales horizontally for reads. Please bear with my lack of ops/db experience. I've been reading https://opencrux.com/articles/what-is-crux.html, but I have some follow-up questions. Let's assume I have multiple Crux nodes backed by a single Postgres instance, and that write volume is low. Will adding more Crux nodes give me a linear increase in read throughput? Will this put more pressure on the backing PostgreSQL instance? When I want to upgrade Crux, will I have to upgrade all Crux nodes at the same time?

refset09:09:29

Hey! > Let's assume I have multiple Crux nodes backed by a single Postgres instance, and that write volume is low. > Will adding more Crux nodes give me a linear increase in read throughput? Yes, definitely 🙂 > Will this put more pressure on the backing PostgreSQL instance? There are some read pressure implications here, but in practice the write workload limit for Postgres is a much more significant pinch point than the read workload. After the initial reads during "ingestion" (transaction processing), Crux nodes don't generally read from Postgres very often outside of polling for new transactions, unless you use pull or entity heavily and have an undersized document cache configured (but even then I think Postgres is unlikely to be the bottleneck vs. network speed) > When I want to upgrade Crux, will I have to upgrade all Crux nodes at the same time? It's generally a good idea to upgrade all nodes at roughly the same time, but there is no requirement to do so - the only exceptions to this would be if we change an external API or some ingestion semantic that may affect the notion of consistency across multiple versions (particularly when load-balancing), but we try to identify and highlight all such changes in the release notes

💯 2
teodorlu11:09:16

That answers all my questions. Thank you!

🙏 2
refset11:09:19

Excellent, I'm pleased to hear it ☺️

🙌 2