sqldb+graph/db: add node related tables and implement some node CRUD #9824

ellemouton · 2025-05-19T10:28:15Z

Builds on top of #9853

In this PR, the following schemas are defined for storing graph nodes:

(NOTE: the block_height column is only shown as an example to show how v2 data might fit into this schema. It is not included in the initial schema definition).

nodes: stores the main info about the node from a node_announcement. Note that we might sometimes insert a "shell node" for when we get a channel announcement that points to a node that we dont yet have a record for. In this case, we will only have the public key of the node along with the gossip version it was advertised on. So the version:pub_key pair is always unique.
node_addresses: normalised node addresses.
node_extra_types: stores the normalised TLV records of a node_announcement for any fields that we dont explicitly store in the nodes table.
node_features: stores the normalised features advertised in a node announcement.
source_nodes: we store a pointer to an entry in the nodes table to indicate which node belongs to this node. NOTE: there will be an entry here per gossip protocol that we are aware of.

The following methods are implemented on the SQLStore:

AddLightningNode
FetchLightningNode
HasLightningNode
AddrsForNode
DeleteLightningNode
FetchNodeFeatures
LookupAlias
NodeUpdatesInHorizon
SourceNode
SetSourceNode

This then lets us run a number of existing unit tests against the new SQLStore backend. Namely:

TestNodeInsertionAndDeletion
TestLightningNodePersistence
TestAliasLookup
TestNodeUpdatesInHorizon
TestSourceNode

Part of #9795

coderabbitai · 2025-05-19T10:28:22Z

Important

Review skipped

Auto reviews are limited to specific labels.

🏷️ Labels to auto review (1)

llm-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Explain this complex logic.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai explain this code block.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and explain its main purpose.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

ellemouton · 2025-05-20T13:13:52Z

graph/db/sql_store.go

+// information.
+//
+// NOTE: part of the V1Store interface.
+func (s *SQLStore) AddLightningNode(node *models.LightningNode,


currently working on a benchmark to compare this to the performance of the kvdb version which uses the batch schedular. We may end up needing something similar here to batch these txs

so this method will be updated to make use of the timed scheduler once this PR is merged: #9845

order of operations: either:

merge 9845, then update this PR

merge this, then 9845, then new PR to update this to use that.

All depends on what gets merged first

guggero

Very nice!
Did a first pass, will probably need a second one since it's quite a chunk of code. But looks great so far.

guggero · 2025-05-20T17:23:04Z

sqldb/sqlc/migrations/000007_graph.up.sql

+    node_id BIGINT NOT NULL REFERENCES nodes(id) ON DELETE CASCADE,
+
+    -- The id of the feature that this node has.
+    feature_id BIGINT NOT NULL REFERENCES features(id)


Hmm, similar to today's offline discussion: What's the advantage of having the feature bits defined in a separate table? Since we don't store more information with each bit that would be de-duplicated. IMO this can just be the bit itself.
I know @Roasbeef had different opinions on such enums (or generally numbers that correspond to Golang constants). So I think we should settle this discussion once and then do the same everywhere.

IMO this can just be the bit itself.

unlike the discussion offline today though, this is an array of feature bits. So i think the idea was if you normalise this out, then you can do "Which nodes advertise feature x" which is hard to do if you keep it in the array form

I'm not talking about removing the node_features table, but just the features. The "array" is the node_features, which is good. But the features table just maps a database ID to a numeric feature number. So we can just inline the feature number here, in the node_features table (and save quite a bit of space while doing that as well).

gotcha 👍

cool - will update as suggested

guggero · 2025-05-20T17:23:55Z

sqldb/sqlc/migrations/000007_graph.up.sql

+    feature_id BIGINT NOT NULL REFERENCES features(id)
+);
+CREATE INDEX IF NOT EXISTS node_feature_node_id_idx ON node_features(node_id);
+CREATE UNIQUE INDEX IF NOT EXISTS node_features_unique ON node_features (


A unique index will create a normal index. So we don't need the first one, as the second one also includes that same field (node_id).

guggero · 2025-05-20T17:26:22Z

sqldb/sqlc/migrations/000007_graph.up.sql

+CREATE UNIQUE INDEX IF NOT EXISTS node_addresses_unique ON node_addresses (
+    node_id, type, position
+);
+CREATE INDEX IF NOT EXISTS node_addresses_node_id_idx ON node_addresses(node_id);


Same here re duplicate index for node_id field.

guggero · 2025-05-20T17:27:19Z

sqldb/sqlc/migrations/000007_graph.up.sql

+
+-- The gossip protocols are distinct. So often we will only want to
+-- query for nodes that are gossiped on a specific protocol version.
+CREATE INDEX IF NOT EXISTS nodes_version_idx ON nodes(version);


Index not needed since we have the unique one (see other comments).

guggero · 2025-05-20T17:31:10Z

sqldb/sqlc/migrations/000007_graph.up.sql

+    -- announcement for a channel that is connected to a node that we
+    -- have not yet received a node announcement for.
+    signature BLOB
+);


Do we want to add some checks to this table for extra validation?
For example (CHECK ((version = 0 OR VERSION =1) AND length(pub_key) == 33)?
I think the downside is that we can't have named checks. So if we ever wanted to add checks or change them, we'd need to drop the table and re-create it, which is a bit tedious (especially with multiple foreign keys).

So I'm leaning toward no, but let's discuss.

i think for version at least we should not be strict since we expect future versions and so would need to change the checks.

Even for pubkey - im hesitant to add the length check just given that there might be a version in which we start advertising schnorr (x-only) pub keys which are 32 bytes

guggero · 2025-05-20T17:41:09Z

sqldb/sqlc/queries/graph.sql

+)
+ON CONFLICT (pub_key, version)
+DO UPDATE SET
+    alias = EXCLUDED.alias,


Since these ON CONFLICT ... DO UPDATE statements are a bit hard to read sometimes, I made it a habit of adding a comment above what the expectation is. For example, the above on the feature bit is a no-OP because the bit field is part of the unique index.
But here we update the fields that aren't covered by the unique index.

ok yeah - good idea - will add!

guggero · 2025-05-20T17:42:02Z

sqldb/sqlc/queries/graph.sql

+-- name: GetNodeFeaturesByPubKey :many
+SELECT f.bit
+FROM nodes n
+         JOIN node_features nf ON nf.node_id = n.id


nit: indentation of JOIN doesn't match above statement.

guggero · 2025-05-20T17:46:06Z

graph/db/sql_store.go

+	}
+
+	if node.HaveNodeAnnouncement {
+		params.LastUpdate = sql.NullInt64{


nit: use sqldb.SQLInt64(), SQLStr() and SQLTime().

oh cool! TIL - thanks.

just a quick check: i've opted to have LastUpdate as an int64 in the DB since it is the unix timestamp advertised in the node announcement so we want to be sure it is not changed somehow by timezone etc.

just want to check if reviewers are ok with that part?

Sounds good to me. I assume precision down to one second is enough here? Otherwise we'd need to use UnixNano() in which case we should make it very clear in the documentation that it's nanoseconds and not seconds.

yeah it is advertised in seconds in the announcement 👍

graph/db/sql_store.go

guggero · 2025-05-20T17:52:42Z

sqldb/sqlc/queries/graph.sql

+-- name: GetNodesByLastUpdateRange :many
+SELECT *
+FROM nodes
+WHERE last_update >= sqlc.arg(start_time)


nit: just use @start_time and @end_time.

ellemouton

updated, thanks @guggero!

as noted offline, i'll continue to iterate on the node_addrs schema to see if we can improve update efficiency there. I'll work on this in parallel with the upcoming PRs - the migrations are not available in prod build so should not be an issue.

depending on what gets approved first, i'll also update the AddLightningNode here to use the batcher: #9845

ellemouton · 2025-05-22T08:54:50Z

sqldb/sqlc/migrations/000007_graph.up.sql

+    -- announcement for a channel that is connected to a node that we
+    -- have not yet received a node announcement for.
+    signature BLOB
+);


i think for version at least we should not be strict since we expect future versions and so would need to change the checks.

Even for pubkey - im hesitant to add the length check just given that there might be a version in which we start advertising schnorr (x-only) pub keys which are 32 bytes

ellemouton · 2025-05-22T08:57:00Z

sqldb/sqlc/migrations/000007_graph.up.sql

+    node_id BIGINT NOT NULL REFERENCES nodes(id) ON DELETE CASCADE,
+
+    -- The id of the feature that this node has.
+    feature_id BIGINT NOT NULL REFERENCES features(id)


gotcha 👍

cool - will update as suggested

ellemouton · 2025-05-22T09:01:43Z

graph/db/sql_store.go

+// information.
+//
+// NOTE: part of the V1Store interface.
+func (s *SQLStore) AddLightningNode(node *models.LightningNode,


so this method will be updated to make use of the timed scheduler once this PR is merged: #9845

order of operations: either:

merge 9845, then update this PR

merge this, then 9845, then new PR to update this to use that.

All depends on what gets merged first

ellemouton · 2025-05-22T09:11:49Z

graph/db/sql_store.go

+	}
+
+	if node.HaveNodeAnnouncement {
+		params.LastUpdate = sql.NullInt64{


oh cool! TIL - thanks.

just a quick check: i've opted to have LastUpdate as an int64 in the DB since it is the unix timestamp advertised in the node announcement so we want to be sure it is not changed somehow by timezone etc.

just want to check if reviewers are ok with that part?

graph/db/sql_store.go

ellemouton · 2025-05-22T09:15:13Z

sqldb/sqlc/queries/graph.sql

+)
+ON CONFLICT (pub_key, version)
+DO UPDATE SET
+    alias = EXCLUDED.alias,


ok yeah - good idea - will add!

ellemouton · 2025-05-22T09:22:52Z

sqldb/sqlc/migrations/000007_graph.up.sql

+
+CREATE TABLE IF NOT EXISTS source_nodes (
+    node_id BIGINT PRIMARY KEY REFERENCES nodes (id) ON DELETE CASCADE


isnt that only the case if we want this to be auto incrementing? we defs dont want this to auto increment.

ellemouton · 2025-05-22T09:23:43Z

sqldb/sqlc/migrations/000007_graph.up.sql

+
+CREATE TABLE IF NOT EXISTS source_nodes (
+    node_id BIGINT PRIMARY KEY REFERENCES nodes (id) ON DELETE CASCADE


the reason i added PRIMARY KEY is just to make sure this is unique - but I guess could also remove that and just use UNIQUE to avoid confusion?

ellemouton · 2025-05-22T14:41:29Z

ok i'll update this now to use the generic batch scheduler now that that is merged. Will do that before re-requesting

In this commit, the various SQL schemas required to store graph node related data is defined. Specifically, the following tables are defined: - nodes - node_extra_types - node_features - node_addresses

In this commit, we add the various sqlc queries that we need in order to implement the following V1Store methods: - AddLightningNode - FetchLightningNode - HasLightningNode - AddrsForNode - DeleteLightningNode - FetchNodeFeatures These are implemented by SQLStore which then lets us use the SQLStore backend for the following unit tests: - TestNodeInsertionAndDeletion - TestLightningNodePersistence

In this commit, we let the SQLStore implement LookupAlias. This then lets us run the TestAliasLookup unit test against the SQL backends.

In this commit we add the necessary SQL queries and then implement the SQLStore's NodeUpdatesInHorizon method. This lets us run the TestNodeUpdatesInHorizon unit tests against SQL backends.

In this commit, we add the `source_nodes` table. It points to entries in the `nodes` table. This table will store one entry per protocol version that we are announcing a node_announcement on. With this commit, we can run the TestSourceNode unit test against our SQL backends.

ellemouton added this to the v0.20.0 milestone May 19, 2025

ellemouton self-assigned this May 19, 2025

ellemouton added the no-changelog label May 19, 2025

ellemouton mentioned this pull request May 19, 2025

[epic]: graph db: SQL implementation & migration #9795

Open

60 tasks

ellemouton added graph database Related to the database/storage of LND labels May 19, 2025

ellemouton force-pushed the graphSQL7-nodes-tables branch from eac15ac to eae4d81 Compare May 19, 2025 12:21

saubyk added this to lnd v0.20 May 19, 2025

saubyk moved this to In progress in lnd v0.20 May 19, 2025

ellemouton force-pushed the graphSQL7-nodes-tables branch from eae4d81 to 2802707 Compare May 19, 2025 18:49

ellemouton added the sql label May 19, 2025

ellemouton requested review from bhandras and guggero May 20, 2025 03:57

ellemouton commented May 20, 2025

View reviewed changes

guggero reviewed May 20, 2025

View reviewed changes

ellemouton force-pushed the graphSQL7-nodes-tables branch from 2802707 to 0e86ef1 Compare May 22, 2025 09:25

ellemouton commented May 22, 2025

View reviewed changes

ellemouton force-pushed the graphSQL7-nodes-tables branch from 0e86ef1 to f89c2f2 Compare May 22, 2025 09:30

ellemouton force-pushed the elle-graph branch from 7a18b60 to 7cef62f Compare May 22, 2025 12:18

ellemouton force-pushed the graphSQL7-nodes-tables branch from f89c2f2 to 32d4287 Compare May 22, 2025 14:40

ellemouton removed the request for review from bhandras May 22, 2025 14:41

ellemouton changed the base branch from elle-graph to master May 23, 2025 08:38

ellemouton added 5 commits May 23, 2025 11:07

sqldb: define schemas for all graph node tables

f7f5dc3

In this commit, the various SQL schemas required to store graph node related data is defined. Specifically, the following tables are defined: - nodes - node_extra_types - node_features - node_addresses

graph/db: implement SQLStore.LookupAlias

63aaff4

In this commit, we let the SQLStore implement LookupAlias. This then lets us run the TestAliasLookup unit test against the SQL backends.

sqldb+graph/db: implement SQLStore.NodeUpdatesInHorizon

d79cd2a

In this commit we add the necessary SQL queries and then implement the SQLStore's NodeUpdatesInHorizon method. This lets us run the TestNodeUpdatesInHorizon unit tests against SQL backends.

ellemouton force-pushed the graphSQL7-nodes-tables branch from 32d4287 to ef435a7 Compare May 23, 2025 09:13

ellemouton changed the base branch from master to elle-graphSQL8-prep May 23, 2025 09:13


		CREATE TABLE IF NOT EXISTS source_nodes (
		node_id BIGINT PRIMARY KEY REFERENCES nodes (id) ON DELETE CASCADE

sqldb+graph/db: add node related tables and implement some node CRUD #9824

Are you sure you want to change the base?

sqldb+graph/db: add node related tables and implement some node CRUD #9824

Uh oh!

Conversation

ellemouton commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai bot commented May 19, 2025

Review skipped

Chat

Support

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

guggero left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ellemouton May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ellemouton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ellemouton commented May 22, 2025

ellemouton commented May 19, 2025 •

edited

Loading

CodeRabbit Configuration File (`.coderabbit.yaml`)

ellemouton May 20, 2025 •

edited

Loading