graphprotocol / graphprotocol/graph-node

Speed up reverts

Abierto
#1,705 1 comentario 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

area/indexing ops performance
Lenguaje dominante
Rust
Estrellas
3.2k
Forks
1.1k
Merge medio
4 d 1 h
PR fusionados (30 d)
1

Descripción

For some subgraphs, reverting blocks is still slow. The best way to speed this up might be to restrict the queries we run to revert the block by the vid of the entity versions that are actually affected by the revert. To facilitate that, graph-node should keep a list of the vid's of entities by block in memory as it moves forward and processes blocks. That list can then be used to speed up reverts.

Even if we only keep this data for a small number of blocks (say 5), it should help in speeding up reverts already. It's ok if we do not have that data for a revert (e.g., after a cold start), we can just fall back to the current behavior. The amount of data to keep should be relatively small, as mappings typically only alter a small number of entities for each block, but we might want to limit this by only keeping the data if there are fewer than N vid's to keep for a block.

Before implementing this, we should analyze the performance of the current queries and compare it to the performance of queries including the vid of the entities affected by the rollback. That should also inform the shape of the data we keep in memory, but will likely look like this for the different operations in a specific block:

  • create: remember the vid of the new entity
  • update: remember the vid of the old and the new version of the entity
  • delete: remember the vid of the deleted entity version

During a revert, we'd then use this information to narrow down which rows in a table to change, for example the query to delete entity versions that are now in the future would become

delete from things where vid in ($vids)

where vids contains what we recorded as new versions for a create or update

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza perfilando las consultas actuales de reversión de bloques de graph-node y comparándolas con consultas acotadas a los IDs de versión de las entidades afectadas (vid). Usa esas mediciones para determinar la estructura de datos en memoria por bloque y el límite de retención; se considera terminado cuando se haya medido una mejora en la velocidad de reversión y el comportamiento existente siga estando disponible cuando no haya datos.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
rust, sql
Área
backend, database, performance
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
30/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.