Cambios en la Base de Datos Próximos en el Protocolo 21
Autor
Garand Tyson
Fecha de publicación
En el Protocolo 21, Soroban recibe su primera gran actualización con la implementación de cinco nuevos CAPs que introducen algunas características emocionantes, como el soporte de firma con llave de paso, una mejora en el archivo de estado y mejoras en el costo para las transacciones de contratos inteligentes. Además de estas nuevas características, los validadores de Stellar también están obteniendo una de las optimizaciones de rendimiento más grandes hasta la fecha: una nueva base de datos llamada BucketListDB.
Para aquellos que no lo saben, BucketListDB es una base de datos construida desde cero para la blockchain de Stellar. BucketListDB ofrece lecturas y escrituras mucho más rápidas que los actuales backends de base de datos SQL de Stellar, mientras que también requiere menos memoria y espacio en disco. Lo más emocionante es que BucketListDB también soporta IO paralelo sin conflictos, lo cual será clave para futuras actualizaciones del Protocolo que introduzcan la ejecución paralela de Soroban y la red Overlay multihilo. Si tienes curiosidad por saber cómo funciona todo bajo el capó, revisa esta charla técnica.
BucketListDB ha sido una característica experimental en stellar-core y después de un año de pruebas rigurosas, es hora de activarla por defecto. Esto significa que, a partir de la versión 21.0 de stellar-core, el modo SQL y en memoria están oficialmente siendo descontinuados. Durante este período de transición, el modo SQL y en memoria todavía serán compatibles, pero pueden experimentar una degradación significativa del rendimiento en comparación con BucketListDB y quedarse atrás del resto de la red.
Nota que SQL no desaparecerá por completo. SQL continuará siendo utilizado para almacenar pequeñas cantidades de metainformación no relacionada con el libro mayor y para algunas consultas de DEX. Sin embargo, la mayoría de las consultas y la mayor parte del estado del libro mayor solo serán atendidas por BucketListDB.
Lo que los Operadores de Validadores Deben Hacer
La versión 21.0 de stellar-core introducirá una nueva bandera de configuración llamada DEPRECATED_SQL_LEDGER_STATE. Si esta bandera no está establecida, stellar-core no podrá iniciar. Esta bandera debe ser establecida cuando un nodo se actualice al paquete stellar-core 21.0. Esta bandera debe ser establecida cuando el paquete se despliegue, no cuando la red se actualice realmente al Protocolo 21.
La configuración predeterminada de esta bandera, y la configuración que la mayoría de los operadores de validadores deberían usar, es DEPRECATED_SQL_LEDGER_STATE=false. Si DEPRECATED_SQL_LEDGER_STATE=true, el nodo puede experimentar degradación del rendimiento y quedarse atrás del resto de la red.DEPRECATED_SQL_LEDGER_STATE=true solo debe ser establecido a verdadero si tú:
- Debes ejecutar stellar-core con la bandera de modo “en memoria”.
- Consultas directamente datos desde el backend SQL de stellar-core, y los datos consultados no son compatibles con BucketListDB (ver “Características Obsoletas” abajo).
Solo los operadores que ejecuten un nodo validador o de observación independiente necesitarán establecer esta bandera. Si captive-core está ejecutándose como parte de Horizon o RPC, la bandera se establecerá automáticamente y no se requerirá ninguna acción.
Guía de Migración
Cuando DEPRECATED_SQL_LEDGER_STATE=false se establece por primera vez, se realiza una migración única de SQL a BucketListDB. Esta migración ocurre automáticamente la primera vez que se ejecuta `stellar-core run` o `stellar-core upgrade-db` y requiere permiso para realizar cambios en el esquema de la DB. Esta migración implica eliminar tablas SQL y configurar índices requeridos para BucketListDB y está limitada por el disco. En unidades SSD NVME, esta migración toma alrededor de 3 minutos. En unidades respaldadas por EBS más lentas, la migración puede tardar hasta 45 minutos. Se recomienda que los operadores actualicen y migren cada nodo individualmente. Después de la migración única, el tiempo de inicio del validador y el tiempo de recuperación se reducen significativamente en comparación con SQL.
Después de la migración, se espera que el uso de disco de stellar-core disminuya aproximadamente un 65%. Aunque se espera que el uso de memoria del proceso de stellar-core aumente alrededor de 1 GB, hay una reducción significativa en el uso de memoria por el backend SQL (nota que el uso específico de memoria del backend SQL depende mucho de la configuración del operador). Se espera que BucketListDB sea estrictamente más eficiente que los backends SQL preexistentes, por lo que los requisitos de los validadores y la utilización de recursos en general no deberían aumentar.
Características Obsoletas
Cuando DEPRECATED_SQL_LEDGER_STATE=false las siguientes tablas en la base de datos SQL de stellar-core son eliminadas:
- CUENTA
- LÍNEA DE CONFIANZA
- DATOS
- SALDO RECLAMABLE
- FONDO DE LIQUIDEZ
- DATOS DEL CONTRATO
- CÓDIGO DEL CONTRATO
- CONFIGURACIÓN
- TTL
Esto incluye todas las tablas de estado del libro mayor (con la excepción de OFERTAS). Además, la columna TXMETA en la tabla TXHISTORY será eliminada.
Nota que cuando DEPRECATED_SQL_LEDGER_STATE=false, estos datos se eliminan en la primera ejecución de `stellar-core run` o `stellar-core upgrade-db`. Para recuperar esta información, será necesario establecer DEPRECATED_SQL_LEDGER_STATE=true, ejecutar `stellar-core new-db`, luego reproducir los datos de transacción.En general, aconsejamos contra el uso de stellar-core para proporcionar esta información porque consultar bases de datos centrales directamente puede causar que el nodo pierda sincronización con la red, y la mejor práctica es ejecutar una instancia de Horizon o RPC. Sin embargo, si tu aplicación requiere consultar esta información, se recomienda establecer DEPRECATED_SQL_LEDGER_STATE=true a corto plazo. Esta bandera será eliminada en futuras versiones y estas tablas ya no serán compatibles. Como solución a largo plazo, considera ejecutar una instancia de Horizon o RPC.
Además, el modo en memoria está siendo obsoleto y será eliminado en una futura actualización. BucketListDB ofrece un tiempo de inicio significativamente más rápido y puede alcanzar a la red mucho más rápido que SQL, eliminando la necesidad del modo en memoria.
¿Preguntas? ¿Comentarios? Por favor, plantealos en el Stellar Dev Discord canal #validators.