Skip to content
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

Optimize balance-related queries with a cache #2383

Merged
merged 123 commits into from
Nov 29, 2024
Merged

Conversation

rafal-ch
Copy link
Contributor

@rafal-ch rafal-ch commented Oct 22, 2024

Linked Issues/PRs

Closes #1965

Description

  1. The client uses the off-chain database metadata to tell if it can use the optimized queries or fall-back to the legacy ones.
  2. When client starts the metadata is either:
    1. Kept intact in-case genesis exists (meaning - no optimized queries are available)
      • this stems from the fact that the pre-existing DB contains some coins already and we'll not be re-indexing them in order to create the lookup indexes
      • in this mode of operation the "old" way of getting balances is used as confirmed in logs:
        • worker_service: 607: Balances cache available: false
        • query::balance: 100: Querying balances without balances cache owner=53a9c6a...
    2. Initialized with V2 if genesis is missing
      • this means that while re-syncing the DB the balance indexes are going to be created and could be used to satisfy the requests
        • worker_service: 607: Balances cache available: true
        • query::balance: 151: Querying balances using balances cache owner=53a9c6a...

Technical considerations:

  • Metadata is extended with V2 which now contains indexation_availability. This is a set that holds the available indexations (currently only Balances)
  • New databases are added: CoinBalances and MessageBalances that keep the coin and message balances respectively
    • CoinBalances stores the balances per owner and asset_id
    • MessageBalances stores balances per owner, separately for retryable and non-retryable messages
  • In case balances indexation is available (see "Description" above):
    • these databases are updated in the GrapQL API worker service when processing one of these events: MessageImported, MessageConsumed, CoinCreated, CoinConsumed
    • balance() and balances() queries use these databases to satisfy the query

Checklist

  • New behavior is reflected in tests

Before requesting review

  • I have reviewed the code myself

@rafal-ch rafal-ch removed the no changelog Skip the CI check of the changelog modification label Nov 22, 2024
acerone85
acerone85 previously approved these changes Nov 26, 2024
Copy link
Contributor

@acerone85 acerone85 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM.

A side question, right now indexation is enabled by default on nodes that did not process genesis. Do we want to also make this configurable? E.g. do some nodes like the block producer not want to perform any indexation on balances, regardless of whether they start at genesis or not?

crates/fuel-core/src/database/metadata.rs Outdated Show resolved Hide resolved
crates/fuel-core/src/database/metadata.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@xgreenx xgreenx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR looks good=) I think some parts can be simplified and we can connect all places related to the same code together via same functions.

Created a PR with suggestions=) #2465

@rafal-ch
Copy link
Contributor Author

I think some parts can be simplified and we can connect all places related to the same code together via same functions.

Nice one, thanks. In particular I like how you got rid of the AssetBalanceWithRetrievalErrors, as it was not something I was especially proud of 👍

@rafal-ch rafal-ch enabled auto-merge (squash) November 29, 2024 15:42
@rafal-ch rafal-ch merged commit ffb7644 into master Nov 29, 2024
30 checks passed
@rafal-ch rafal-ch deleted the 1965_balances_cache branch November 29, 2024 16:26
@rafal-ch
Copy link
Contributor Author

rafal-ch commented Dec 5, 2024

Overall LGTM.

A side question, right now indexation is enabled by default on nodes that did not process genesis. Do we want to also make this configurable? E.g. do some nodes like the block producer not want to perform any indexation on balances, regardless of whether they start at genesis or not?

@xgreenx
Actually, @acerone85 has a point here. Opting out from the balances cache might be potentially useful in case the index somehow becomes corrupted. But otoh, in such case also other parts of the DB could be corrupted and it'll be probably better to sync from scratch and rebuild the index.

xgreenx pushed a commit that referenced this pull request Dec 5, 2024
…#2472)

## Description
This PR partially reverts the changes introduced in the [balances
indexation PR](#2383).

In particular:
* reverts the type of `amount` in the `Balance` GraphQL type back to
`U64`
* introduces a new field `amountU128` in the `Balance` GraphQL type
* reverts the `FuelClient::balance()` function to return `u64`. There is
no `balance_u128()` function added to the `FuelClient` for now.


![image](https://github.com/user-attachments/assets/621db3b9-54f8-46c9-8bdd-c29f65b01c7c)

This is done to maintain the full backward compatibility on the GraphQL
level, internally the total balance is still processed using `u128`.

### Before requesting review
- [X] I have reviewed the code myself
@xgreenx
Copy link
Collaborator

xgreenx commented Dec 12, 2024

We have an issue with adding a flag that allows you to not support off-chain database. We could consider to allows customization on what stuff we want from the off-chain database. But I think we don't need to worry about it, until someone will ask for this kind of feature=)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Optimize GraphQL "balances" query
5 participants