From b2fbc0581ba9746cef7e9cf239a5e719b8c9d4e2 Mon Sep 17 00:00:00 2001 From: Lee Danilek Date: Wed, 6 Nov 2024 12:44:31 -0500 Subject: [PATCH] Update README.md --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 9c554e6..52ddce8 100644 --- a/README.md +++ b/README.md @@ -599,7 +599,7 @@ In order to calculate in `O(log(n))` time, the aggregate component stores denormalized counts in an internal data structure. Data points with nearby keys may have their counts accumulated in one place. -Imagine the leaderboard aggregate defined with key=`[username, score]`. Users +Imagine the leaderboard aggregate defined with `Key: [username, score]`. Users "Laura" and "Lauren" have adjacent keys, so there is a node internal to the Aggregate component that includes the counts of Laura and Lauren combined. If Laura is looking at her own high score, this involves reading from the @@ -613,6 +613,12 @@ each new data point will be added to the same part of the data structure (the end), because `_creationTime` keeps increasing. Therefore all inserts will wait for each other and no mutations can run in parallel. +On the other hand, each namespace has its own data structure and there's no +overlap in internal nodes between namespaces. So if you use +`Namespace: username` and `Key: score`, which has similar capabilities +to an aggregate with `Key: [username, score]`, then you never have a problem +with "Laura" and "Lauren" having contention. + ### Put bounds on aggregated data To reduce the read dependency footprint of your query, you can partition your