-
Notifications
You must be signed in to change notification settings - Fork 721
chore: fix some documentation #1662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Xiangyu (Samuel) Hu <[email protected]> fix
| in the project root. | ||
|
|
||
| For developers, we always recommend using risedev to start the full cluster, instead of using these docker images. | ||
| For RisingWave kernel hackers, we always recommend using [risedev](../src/risedevtool/README.md) to start the full cluster, instead of using docker images. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why using such fancy word to describe "developers"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Developers include kernel devs and full stack devs. Dockers are firstly niticed and tried by the latter.
docs/state-store-overview.md
Outdated
| ### Read Path | ||
|
|
||
| To read from Hummock, we will first need a ***version*** (a consistent state of list of SSTs we can read). To avoid contacting Hummock manager in every user read, the Hummock client will cache a most recent ***version*** locally. Local version will be updated when 1) client initiates a write batch and 2) background refresher triggers. | ||
| To read from Hummock, we need a ***version*** (a consistent state of list of SSTs we can read) and and ***epoch*** to generate a consistent read snapshot. To avoid RPC with Hummock manager in every user read, the Hummock client will cache a most recent ***version*** locally. Local version will be updated when 1) client initiates a write batch and 2) background refresher triggers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and and?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
docs/state-store-overview.md
Outdated
| As mentioned in [Read Path](#read-path), reads are performed on a ***version*** based on a given ***epoch***. During the whole read process, data from the specified read epoch cannot be removed by compaction, which is guaranteed by ***pinning an snapshot***; SSTs within a ***version*** cannot be vacuumed by compaction, which is guaranteed by ***pinning a version***. | ||
|
|
||
| The SQL frontend will get the latest epoch from meta service. Then, it will embed the epoch number into SQL plans, so that all compute nodes will read from that epoch. In theory, both SQL frontend and compute nodes will ***pin the snapshot***, to handle the case that frontend goes down and the compute nodes are still reading from Hummock (#622). However, to simplify the process, currently we *only pin on the frontend side**.* | ||
| The SQL frontend will get the latest epoch from meta service. Then, it will embed the epoch number into SQL plans, so that all compute nodes will read from that epoch (***Snapshot Isolation***). In theory, both SQL frontend and compute nodes will ***pin the snapshot***, to handle the case that frontend goes down and the compute nodes are still reading from Hummock (#622). However, to simplify the process, currently we *only pin on the frontend side**.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think it's a good idea to mention Snapshot Isolation here. The consistence level we provide is somehow a little bit different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure
Codecov Report
@@ Coverage Diff @@
## main #1662 +/- ##
============================================
+ Coverage 69.79% 69.90% +0.10%
Complexity 2766 2766
============================================
Files 1050 1052 +2
Lines 92481 92473 -8
Branches 1790 1790
============================================
+ Hits 64549 64642 +93
+ Misses 27041 26940 -101
Partials 891 891
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
Signed-off-by: Xiangyu (Samuel) Hu [email protected]
Checklist
Refer to a related PR or issue link (optional)