Ingesta
La API Horizon proporciona la mayor parte de su utilidad a través de datos ingeridos, y tu servidor Horizon puede configurarse para escuchar y consumir los resultados de las transacciones de la red Stellar. La ingesta permite el acceso a la API tanto al estado actual (por ejemplo, el saldo de alguien) como al estado histórico (por ejemplo, el historial de transacciones de alguien).
Tipos de Ingesta
Hay dos casos de uso principales de la ingesta para las operaciones de Horizon:
- Ingestar datos en vivo para mantenerse al día con los últimos ledgers de la red, acumulando una ventana deslizante de ledgers antiguos;
- Ingestar datos históricos para añadir retroactivamente datos de la red de un intervalo de tiempo en el pasado a la base de datos.
Determinar Espacio de Almacenamiento
Debes pensar detenidamente sobre el marco temporal histórico de los datos ingeridos que te gustaría retener en la base de datos de Horizon. Los requisitos de almacenamiento para transacciones en la red Stellar son sustanciales y están creciendo sin límites con el tiempo. Esto es algo que puede que necesites monitorear y reevaluar continuamente a medida que la red continúa creciendo. Hemos encontrado que la mayoría de las organizaciones solo necesitan una pequeña fracción de datos históricos recientes para satisfacer sus casos de uso. A través del análisis de patrones de tráfico en la instancia Horizon de SDF, vemos que la mayoría de las solicitudes son para datos muy recientes.
Para mantener tu huella de almacenamiento pequeña, recomendamos lo siguiente:
- Usar ingesta en vivo, usar ingesta histórica solo en casos excepcionales limitados.
- Si tu aplicación requiere acceso a todos los datos de la red, no se puede realizar filtrado, recomendamos limitar la retención histórica de los datos ingeridos a una ventana deslizante de 1 mes (HISTORY_RETENTION_COUNT=518400) que es el valor predeterminado establecido por Horizon.
- Si tu aplicación puede trabajar con un conjunto de datos de red filtrado basado en cuentas y activos específicos, entonces recomendamos aplicar reglas de filtrado de ingesta. Al utilizar reglas de filtrado, proporciona la ventaja de elegir un marco de tiempo de retención histórica más largo, ya que el filtrado reduce el tamaño general de la base de datos a tal grado que la retención histórica(
HISTORY_RETENTION_COUNT
) se puede establecer en términos de años en lugar de meses o incluso deshabilitar(HISTORY_RETENTION_COUNT=0
). - Si no puedes limitar tu ventana de retención histórica a 30 días y no puedes usar reglas de filtrado, recomendamos considerar el Stellar Hubble Data Warehouse para cualquier dato histórico.
Ingestar Datos En Vivo
Esta opción está habilitada por defecto y es el modo de ingesta recomendado para ejecutar. Se controla con la bandera de configuración del entorno INGEST
. Consulta Configuración sobre cómo una instancia de Horizon desempeña el rol de ingesta.
Para requisitos de alta disponibilidad, recomendamos desplegar más de una instancia de ingesta en vivo, ya que esto facilita evitar el tiempo de inactividad durante las actualizaciones y añade resistencia, asegurando que siempre tengas los últimos datos de la red (consulta Rol de Ingesta de Instancia).
Ingestar Datos Históricos
Importar datos de la red de un rango de fechas pasado a la base de datos:
- Ejemplo
stellar-horizon db reingest range <start> <end>
Ejecutar cualquier rango de ingesta histórica requiere coordinación con la configuración de retención de datos elegida. Al establecer un límite temporal en la historia con HISTORY_RETENTION_COUNT=<LEDGER_COUNT>
, el límite temporal tiene prioridad, y cualquier dato ingerido más allá de ese límite será automáticamente purgado.
Típicamente, la única vez que necesitas ejecutar ingesta histórica es una vez al iniciar un sistema después del primer despliegue, a partir de ese momento la ingesta en vivo mantendrá la base de datos poblada con la ventana deslizante esperada de datos históricos posteriores. Quizás una excepción sea si crees que tienes un vacío en la base de datos causado por la ingesta en vivo que está caída, en cuyo caso puedes ejecutar un rango de ingesta histórica para llenar esencialmente el vacío.
Puedes ejecutar ingesta histórica en paralelo en segundo plano mientras tu servidor principal de Horizon realiza la ingesta en vivo por separado. Si el rango especificado se superpone con datos ya en la base de datos, está bien y será simplemente sobrescrito, siendo efectivamente idempotente.
Trabajadores de Ingesta en Paralelo
Puedes paralelizar la ingesta del rango de ledger histórico objetivo dividiéndolo en segmentos secuenciales de rangos más pequeños y ejecutar el comando de reingestión de db para cada subrango en paralelo como un proceso separado en la misma máquina o en una diferente. La regla abreviada para el mejor rendimiento es identificar el número de núcleos de CPU disponibles por máquina objetivo, si tiene múltiples núcleos, luego añade --parallel-workers <num de núcleos>
al comando, esto permitirá que el comando paralelice aún más internamente dentro de un solo proceso usando múltiples hilos y rangos más pequeños subdivididos.
- Ejemplo
# target range 1 30000, on single machine with 1 CPU core
horizon1> stellar-horizon db reingest range 1 30000
# target range 1 30000, on single machine with 4 CPU cores
horizon1> stellar-horizon db reingest range 1 30000 --parallel-workers 4
# target range 1 30000, on two machines, each has 2 CPU cores
horizon1> stellar-horizon db reingest range 1 15000 --parallel-workers 2
horizon2> stellar-horizon db reingest range 15001 30000 --parallel-workers 2
Notas
Algunos endpoints pueden reportar no disponibles durante la ingesta en vivo
- Los endpoints que muestran información del estado actual desde la ingesta en vivo pueden devolver el error
503 Servicio No Disponible
/Aún Ingesteando
. Un ejemplo es el endpoint/paths
(construido utilizando ofertas). Tales endpoints estarán disponibles después de que la ingesta en vivo haya terminado la sincronización de la red y se ponga al día (generalmente dentro de un par de minutos).
Si han pasado más de cinco minutos sin nuevos datos ingeridos:
-
Verifica que la máquina host cumpla con los Requisitos previos recomendados.
-
Revisa la salida de registro de Horizon.
- Si hay muchos mensajes
nivel=error
, puede indicar un problema ambiental, incapacidad para acceder a la base de datos. - La ingesta en vivo emitirá dos líneas de registro clave aproximadamente cada 5 segundos basado en el último ledger emitido desde la red. Observa la salida de registro de Horizon y filtra la presencia de estas líneas con un filtro:
Si no ves salida de este canal cada pocos segundos para un nuevo ledger, entonces la ingesta no está avanzando, revisa los registros completos y verifica si hay mensajes alternativos que impresionan razones en contrario. Puede que veas líneas mencionando 'poniéndose al día' al conectar a pubnet, ya que puede tardar hasta 5 minutos para que el proceso de núcleo cautivo iniciado por Horizon se ponga al día con la red pubnet.
tail -f horizon.log | | grep -E 'Processed ledger|Closed ledger'
- Verifica el uso de RAM en la máquina, es posible que el sistema haya agotado la RAM y esté usando memoria de intercambio, lo que dará como resultado un rendimiento lento. Verifica que la máquina host cumpla con los requisitos mínimos de RAM.
- Verifica las velocidades de lectura/escritura en el volumen que el directorio de trabajo actual para el proceso de horizon está utilizando. Basado en requisitos previos, el volumen debería tener al menos 10mb/s, una forma de verificar esto aproximadamente en la máquina host (linux/mac) línea de comando:
sudo dd if=/dev/zero of=/tmp/test_speed.img bs=1G count=1
- Si hay muchos mensajes
Monitorear el Proceso de Ingesta
Para despliegues de alta disponibilidad, se recomienda implementar el monitoreo del proceso de ingesta para visibilidad sobre el rendimiento/salud. Consulta Monitoreo para acceder a registros y métricas de Horizon. Stellar publica el ejemplo Horizon Grafana Dashboard, que demuestra consultas contra métricas clave de ingesta de Horizon, específicamente observa el Retraso Local de Ingesta [Ledgers]
y Edad del último ledger
en el panel de Resumen de Salud
.