En el contexto de los datos de archivo de Solana, la indexación es el proceso de estructurar y organizar los datos históricos de transacciones en una base de datos para recuperarlos de forma rápida y eficiente. La mayoría de las empresas que crean productos en Solana mantienen índices relacionados con su negocio (p. ej., transferencias de stablecoins). La carga histórica es el proceso de recuperar datos históricos de transacciones desde cualquier momento a partir del bloque génesis de Solana para crear un índice. En la mayoría de los casos, los desarrolladores pueden usar un método RPC como getTransactionsForAddress para aplicar filtros temporales, establecer el orden (es decir, cronológico o más recientes primero) y paginar lotes de transacciones. Para cargas históricas grandes, las empresas pueden comunicarse con nuestro equipo para solicitar cargas históricas gestionadas.

El autoservicio te permite cargar o indexar datos históricos de Solana con métodos RPC existentes, como nuestro getTransactionsForAddress mejorado, y almacenarlos en el destino que prefieras. La carga histórica gestionada es una oferta beta en la que nos encargamos del proceso anterior por ti. Al principio, limitaremos el acceso al servicio de carga histórica gestionada a un número reducido de clientes. Así podremos comprender mejor sus dificultades y el destino que prefieren para los datos históricos antes de ofrecerlo como una opción de autoservicio.

El método recomendado para indexar datos de Solana consiste en usar el método RPC getTransactionsForAddress para obtener todos los datos de archivo de Solana, almacenarlos en la base de datos que prefieras, como PostgreSQL o una base de datos columnar como ClickHouse, y luego usar una solución de streaming de datos de Solana como LaserStream o Enhanced WebSockets para mantener tu índice actualizado en tiempo real.

El método RPC getTransactionsForAddress (gTFA) es un método RPC de Solana para consultar datos de archivo exclusivo de Helius que combina getSignaturesForAddress y getTransaction en una sola llamada. Los desarrolladores pueden usar nuevas y potentes funciones, como búsqueda inversa, filtrado por tiempo, estado y slot, y paginación, para devolver lotes de hasta 100 transacciones completas o 1000 firmas.

El nuevo filtro tokenAccounts de getTransactionForAddress devuelve todas las transacciones de una dirección de Solana —incluidas todas las transacciones que involucran las cuentas de tokens asociadas (ATA) de la dirección— con una sola llamada. Antes, los desarrolladores debían consultar getTokenAccountsByOwner y luego getSignaturesForAddress para cada cuenta de tokens. Esto era lento y costoso, y a menudo requería cientos de llamadas RPC adicionales.

Sí. Para obtener una vista completa, usa la Parsed Events API para paginar el historial de una dirección. Las instrucciones compatibles se decodifican en argumentos y cuentas con nombre para más de 3600 programas de Solana, junto con detalles de transferencias de tokens y resúmenes en lenguaje sencillo cuando son compatibles. Los datos sin procesar de las instrucciones se conservan cuando no es posible decodificarlos. Usa getTransactionsForAddress cuando necesites las cargas de transacciones sin procesar. También puedes usar getTransfersByAddress para devolver registros concisos y analizados de transferencias de SOL y tokens de una dirección.

Para obtener todo el historial de una billetera de Solana, incluidas todas sus cuentas de tokens asociadas (ATA), usa el método RPC getTransactionsForAddress y configura el filtro tokenAccounts como all. Esto requiere que las transacciones devueltas hagan referencia a la dirección de la billetera o a una cuenta de tokens propiedad de la billetera. Para obtener más información, consulta nuestra guía sobre cómo obtener el historial de tokens de Solana con una sola llamada.

Creamos desde cero un sistema de archivo de Solana completamente nuevo para sustituir la base de datos predeterminada Google BigTable, que la mayoría de los demás proveedores de RPC usan para servir datos históricos. Nuestro índice almacena una entrada por cada par único de (transacción, cuenta). Hasta la fecha, nuestro índice contiene más de 2,3 billones de filas, que almacenan las más de 450 mil millones de transacciones de Solana al momento de escribir este texto. A pesar de su tamaño, el tiempo de consulta P50 es de aproximadamente 8 ms bajo carga de producción. También creamos otros índices para permitir consultas por slot, tiempo, estado y más. Todos estos índices se ejecutan en hosts bare metal diseñados específicamente, con petabytes de NVMe de última generación, y se replican en varias regiones para brindar a los desarrolladores acceso confiable, escalable y de baja latencia a los datos históricos.

Los métodos RPC estándar como getBlock son lentos y no son adecuados para conjuntos de datos pequeños y específicos. Repetir métodos como getSignaturesForAddress y getTransaction requiere muchas solicitudes RPC innecesarias, tiempos de espera exponenciales y lógica de reintentos. Hasta ahora, estos métodos RPC estándar también consultaban Google BigTable, el almacén de datos de archivo predeterminado que usa la mayoría de los proveedores de RPC. Creamos nuestro propio índice desde cero para optimizar cómo se almacenan, consultan y sirven los datos históricos. Cuando los desarrolladores consultan el método getTransactionsForAddress (gTFA), combinan los métodos estándar getSignaturesForAddress y getTransaction en una sola consulta con opciones adicionales de ordenamiento, filtrado y paginación. Como creamos índices personalizados, getTransactionsForAddress brinda a los desarrolladores mayor control sobre sus consultas, simplifica los flujos de trabajo y devuelve los datos más rápido.

Para comenzar, explora estos recursos:

• Descripción general de la documentación de datos históricos
• Guía de getTransactionsForAddress
• Guía de getTransfersByAddress
• Referencia de la API getTransactionsForAddress
• Cómo indexar datos de Solana