Document the clustering #302
Conversation
Signed-off-by: Gao Hongtao <hanahmily@gmail.com>
Codecov Report
@@ Coverage Diff @@
## main #302 +/- ##
==========================================
- Coverage 39.96% 39.94% -0.02%
==========================================
Files 100 100
Lines 10868 10868
==========================================
- Hits 4343 4341 -2
- Misses 6107 6109 +2
Partials 418 418 see 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| ----------------- ----------------- ----------------- | ||
| | Data Node 1 | | Data Node 2 | | Data Node 3 | | ||
| | (Shard 1) | | (Shard 2) | | (Shard 3) | | ||
| ----------------- ----------------- ----------------- |
There was a problem hiding this comment.
Instead, it delegates the task of replication to these underlying storage systems.
I think diagram is not complete, should we add more detail diagram about how to delegates the task of replication to these underlying storage systems?
There was a problem hiding this comment.
Make sense. You could push a "suggestion" to update the text diagram.
There was a problem hiding this comment.
Sorry. The data node doesn't necessarily have to be built on "shared" storage. It just requires a robust one in case of a potential single point of failure. Therioally, the whole architecture is shared-nothing instead of shared storage.
|
The design is good enough for now. I recommend to add principles/philosophy for why the arch looks like this. Such as
These are fundamentals of why we did these choices, which are more important. We could have countless optimizations with time and experiences, but these are rarely to be changed as they only close to our use cases, which is skywalking itself. |
Signed-off-by: Gao Hongtao <hanahmily@gmail.com>
done |
|
LGTM |
|
|
||
| ### 6.1 Query Routing | ||
|
|
||
| Query Nodes differ from Liaison Nodes in that they do not store shard mapping information from Meta Nodes. Instead, they access all Data Nodes to retrieve the necessary data for queries. As the query load is lower, it is practical for query nodes to access all data nodes for this purpose. It may increase network traffic, but simplifies scaling out of the cluster. |
There was a problem hiding this comment.
It may be necessary to explain the impact of the datanodes scale on the long tail of the query
There was a problem hiding this comment.
It could. Side effects of this solution is there for sure. No matter we wrote or not.
There was a problem hiding this comment.
This pattern is good at batching and aggregation. Some scenarios can leverage it:
- Ad-hoc "TopN" is a classic aggregation operation. OAP's service and instance TopN metric query will benefit from this pattern.
- "MultiGet" is a batching operation on several entities, which is natural to retrieve data from all data nodes.
- A Skywalking UI's classic Dashboard will fetch several metrics belonging to an entity. The OAP generates several query operations to fetch data from DB. If it can combine them to issue a batch operation, BanyanDB will perform better than the one with several separate queries.
The scenarios serve as examples to illustrate the potential of "stateless query". As core contributors, we must possess a thorough understanding of this concept.
tldr
Meta nodes hold active nodes and shard mapping info.
Liaison nodes shard data based on real-time shard mapping.
Query nodes retrieve data from all active nodes without shard mapping info.
Update the
CHANGESlog.