¿CDP y RPC? Más bien EZ y PZ.

Así que mis compañeros del Equipo de Plataforma recientemente lanzaron y anunciaron la Plataforma de Datos Componible y Galexie. Realmente no estuve involucrado en la planificación ni en el desarrollo de este proyecto, pero las implicaciones de la flexibilidad de CDP eran tan prometedoras que tenía que probarlo. Han estado promocionándolo en la reunión de desarrolladores de Discord y en una publicación de blog reciente y sonaba un poco demasiado bueno para ser verdad.

El cínico en mí tenía que intentarlo, y aunque podría enviar mensajes directos a mis compañeros de trabajo para pedir ayuda, estaba decidido a hacerlo lo menos posible. Esta publicación es una breve incursión en mi experimentación con el uso de CDP para agregar soporte de rellenado a Stellar RPC.

Alerta de spoiler: Realmente fue así de fácil.

Si has estado jugueteando con la plataforma de contrato inteligente Stellar, probablemente también hayas intentado ejecutar Stellar RPC para que puedas ejecutar todo localmente (a menos que estés usando uno de nuestros proveedores de RPC del ecosistema!). Probablemente también te hayas encontrado con una de sus decisiones de diseño intencionales: es una puerta de enlace en vivo que no se preocupa mucho por los datos históricos. Esto es lo que lo hace tan ligero y fácil de ejecutar. Proporciona pequeñas ventanas de historia para transacciones y eventos, pero estas son "mirando hacia adelante": si configuras RPC para almacenar 24 horas de historial de libro mayor, no pasará mucho tiempo tratando de rellenar las últimas 24 horas, sino que simplemente mantendrá las siguientes 24 horas en la base de datos y luego la recortará de manera continua. El objetivo es que avances con tu proyecto lo más rápido posible en lugar de la filosofía de Horizon que está más centrada en la gestión de la historia profunda.

El advenimiento de CDP, sin embargo, me hizo preguntarme si facilitaría incorporar el relleno en RPC sin tener que lidiar con la lenta repetición y el retraso en el inicio que incurriría el mecanismo de repetición directa del núcleo cautivo.

En resumen: media hora y 80 líneas de código después (la mitad de las cuales es solo manejo de errores gracias a la pedantería de Golang), podría hacer que RPC rellenara su base de datos con un día de historia (alrededor de 28GB de datos) en unos 10 minutos.

Primero, necesitamos un almacén de datos de metadatos del libro mayor. Admito que hice un poco de trampa en esta parte ya que el equipo ya había exportado todo a nuestro cubo de GCS y no tuve que hacer ninguna exportación yo mismo. Pero una vez que CDP despegue, no me sorprendería ver a los proveedores del ecosistema permitir el acceso a sus lagos de datos a los desarrolladores de una manera similar a lo que vemos con RPC. También es importante recordar que CDP es un modelo de "exportar un rango una vez, ingerirlo en todas partes" (a diferencia de Horizon que necesita un núcleo cautivo para generar datos sobre la marcha y luego ingerirlos cada vez para cualquier rango que quieras rellenar), así que incluso si decides ejecutar galexie para construir el lago de datos tú mismo, solo tendrás que lidiar con el proceso de exportación una vez, en lugar de cada vez.

Conectar al lago es fácil:

Nota: Este paso requiere que tu máquina esté configurada con la CLI de gcloud. Una vez que te hayas autenticado y tu archivo de credenciales esté almacenado en disco (en mi máquina vive en ~/.config/gcloud), será recogido automáticamente por el código de conexión anterior.

Segundo, necesitamos usar el nuevo BufferedStorageBackend en la biblioteca de ingestión que aprovecha el lago de datos para proporcionar lectores paralelos eficientes para buscar libros mayores:[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

Nota: Hay algunas pruebas de rendimiento que el equipo hizo sobre los valores de configuración aquí que podrías encontrar útiles dependiendo de cómo exportes tus datos.

Finalmente, todo lo que tenemos que hacer es decidir sobre el rango de libros mayores que queremos buscar y rellenar. Tuve que agregar algunos cálculos aburridos al código RPC que variaban según si la base de datos estaba vacía o no que no replicaré aquí, pero puedes asumir que ahora tenemos las variables de primero/último representando el rango que queremos rellenar. En ese punto, el relleno real se vuelve trivial:

¡Y eso es todo lo que escribió! Hubo algunas otras cosas que ajustar con respecto a las migraciones de la base de datos: queremos que todas las migraciones "reocurran" en caso de un relleno ya que, por ejemplo, las transacciones aún no se habrán ingerido, pero eso es ortogonal al rápido tutorial de CDP aquí.

Primero, ejecuté el servicio RPC de la manera "normal": ponerme al día con la punta más reciente de la red e ingerir algunos libros mayores. Luego, lo detuve y le pedí que rellenara los últimos 17,280 libros mayores, que es aproximadamente un día de valor. En mi máquina (que admito es una gran advertencia), ese proceso solo tomó unos 12 minutos:

Si hubiéramos hecho esto a través del núcleo cautivo, poniéndolo al día con la red y luego realizando una repetición de este rango de libros mayores, habría tomado más de una hora, ¡si no más! Además, gran parte de ese tiempo se habría gastado solo en la fase de puesta al día, y se repetiría cada vez que quisiéramos rellenar.

Vaya, no exageraban: realmente fue así de fácil. Es poco probable que el rellenado se incorpore a RPC pronto, pero el hecho de que pude crear un prototipo en una sola tarde confirma el hecho de que CDP es tan poderoso como mi equipo afirmaba que era.

La flexibilidad de CDP significa que recopilar información sobre los datos del libro mayor es rápido y fácil: podrías rastrear pagos entre cuentas, observar la actividad de DEX, indexar eventos e interacciones de contratos, observar el archivado de estado o cualquier otra cosa que te interese. ¡El libro mayor ahora es nuestra ostra!

¿Quieres probar CDP por ti mismo? Consulta la documentación de galaxie para construir una fuente de datos y el código de muestra en esta misma publicación para usar BufferedStorageBackend para construir tu propia tubería de ingestión eficiente y componible.