¡Prueba Nuestro Nuevo Conjunto de Datos Analíticos!

Los datos que estamos exponiendo resumen el estado del libro mayor de Stellar, así como la historia completa de transacciones en la red. Horizon típicamente almacena esta información en una base de datos Postgres. ¡Hemos puesto este conjunto de datos en Google BigQuery, lo que ha hecho que las consultas a gran escala sean de 10 a 100 veces más rápidas! Ten en cuenta que cada tabla se actualiza diariamente, alrededor de las 7 AM PST, a través de un pipeline de datos interno.

• cuentas: Contiene el estado actual de todas las cuentasestado (bueno, a partir de las 7 AM del Pacífico ;)).
• cuentas_historia: Mapea cada ID de cuenta a una dirección Stellar. Más útil con operaciones, que se refiere a cuentas usando estos ID.
• activos_historia: Mapea cada ID de activo a un activo Stellar. Más útil con operaciones, que también se refiere a activos usando estos ID.
• libros_mayores_historia: Contiene todoslos libros mayores.
• operaciones_historia: Contiene todaslas operaciones.
• transacciones_historia: Contiene todaslas transacciones.
• ofertas: Contiene todaslas ofertas.
• líneas_de_confianza: Contiene todas las actualeslíneas de confianza.
• operaciones_historia_enriquecidas: la tabla de operaciones de historia, pero potenciada. Incluye el estado de cada operación; unida con su transacción; y unida nuevamente con su libro mayor (que contiene el tiempo de cierre). ¡Súper útil para cualquier pregunta a nivel de operación!
  

Nota: mientras SDF aloja el conjunto de datos y paga los costos de alojamiento, no cubriremos consultas de usuarios externos. Afortunadamente, las consultas individuales son bastante baratas, típicamente, ¡solo unos pocos centavos! Además, Google ofrece una cantidad generosa de créditos de prueba para nuevos usuarios de Google Cloud. Aquí estáninstrucciones para configurar una prueba gratuita. Después de eso, asegúrate de configurar unproyecto, o no podrás consultar ningún dato.

Basta de hablar. Aquí están losdatos.‍

¡Por supuesto! Más que feliz de complacer. ¡Aquí hay tres! :)‍

Esta consulta es un calentamiento: ¿qué cuentas tienen más XLM? ¡Intenta ejecutarla tú mismo para encontrar la respuesta!

SELECT
 account_id,
 balance
FROM `crypto-stellar.crypto_stellar.accounts`
ORDER BY balance DESC;

Esta es más compleja: ¿cuánto se pagó en un activo específico — por día — en el intercambio descentralizado de Stellar (DEX)? En este ejemplo, estamos usando NGNT de Cowrie. ¡Ve si puedes modificarla tú mismo y probar con un activo diferente!

SELECT
 DATE(closed_at) AS close_date,
 SUM(amount) AS daily_amount,
FROM `crypto-stellar.crypto_stellar.enriched_history_operations` eho
WHERE
 type = 1 AND -- Type: Payment
 (asset_code = "NGNT" AND asset_issuer = "GAWODAROMJ33V5YDFY3NPYTHVYQG7MJXVJ2ND3AOGIHYRWINES6ACCPD") AND -- Asset code and issuer are NGNT and Cowrie
 eho.from != eho.to AND -- Different sender and recipient to exclude arbitrage ops.
 (successful = true OR successful IS NULL) -- Only include successful operations.
GROUP BY close_date
ORDER BY close_date DESC;

‍

Finalmente, aquí hay un cálculo serio: ¿cuántas operaciones hubo de un par de trading específico — por día — en el DEX? Para este ejemplo, estamos usando XLM/AnchorUSD, en ambas direcciones. Como antes, ¡prueba con tu propio par!

-- Make a table of ID to "base_asset" (concatenation of type, code, issuer).
WITH base_assets AS (
 SELECT
 id,
 CONCAT(asset_code, '-', asset_issuer) AS base_asset
 FROM `crypto-stellar.crypto_stellar.history_assets`
),

-- Make a table of ID to "counter_asset" (concatenation of type, code, issuer).
-- We have multiple tables, as it seems you cannot rename a column in a left join.
counter_assets AS (
 SELECT
 id,
 base_asset AS counter_asset
 FROM base_assets
)
-- Select the number of different base accounts, counter accounts, and trades.
-- Group by date, base asset, and counter_asset.
-- We use AnchorUSD as an example.
SELECT
 DATE(ledger_closed_at) AS close_date,
 COUNT(DISTINCT(history_operation_id)) AS num_trades,
FROM `crypto-stellar.crypto_stellar.history_trades`
LEFT JOIN base_assets ON base_assets.id = base_asset_id
LEFT JOIN counter_assets ON counter_assets.id = counter_asset_id
WHERE 
(base_asset="USD-GDUKMGUGDZQK6YHYA5Z6AY2G4XDSZPSZ3SW5UN3ARVMO6QSRDWP5YLEX" AND counter_asset="-") OR
 (base_asset="-" AND counter_asset="USD-GDUKMGUGDZQK6YHYA5Z6AY2G4XDSZPSZ3SW5UN3ARVMO6QSRDWP5YLEX")
GROUP BY close_date, base_asset, counter_asset
ORDER BY close_date DESC, num_trades DESC

‍

Desde su diseño e inicio, el protocolo Stellar ha utilizado sistemas de gestión de bases de datos estándar de la industria comoPostgreSQL. Esta elección de diseño hace que la configuración y el mantenimiento de un nodo Stellar Core y el servidor API de Horizon sean relativamente simples. Postgres es probado y comprobado, de código abierto, y increíblemente fiable y estable, por lo que es genial para almacenar libros mayores, transacciones y otros datos y metadatos de la red Stellar.

Desafortunadamente, aunque es excelente para almacenamiento, Postgres y sistemas similares no son tan buenos ejecutando consultas a gran escala. La mayoría de los sistemas de bases de datos se dividen en una de dos categorías: procesamiento de transacciones en línea (OLTP) y procesamiento analítico en línea (OLAP), y Postgres es un ejemplo del primero. Los OLTP procesan eficientemente un gran número de transacciones en línea cortas y almacenan sus resultados de manera fiable, incluso en entornos de múltiple acceso. Pero debido a que estos sistemas están optimizados para manejar estas transacciones más pequeñas rápidamente, no manejan consultas complejas tan bien. ¡No es su culpa, simplemente no es para lo que están diseñados! Es como un velocista tratando de levantar pesas.

Ahí es donde entran los OLAP. Se actualizan más lentamente y generalmente son más caros de consultar. Pero también están optimizados para manejar eficientemente consultas masivas con muchas uniones. Una herramienta popular en este sentido es Google BigQuery. Decidimos usarlo para nuestro propio almacenamiento de datos por algunas razones clave. Usamos GSuite en SDF, por lo que se integra bien con nuestras herramientas organizacionales. También ofrece una fácil integración con otras ofertas de Google Cloud, como Cloud Storage, Functions y Drive, lo que hace que construir un pipeline de análisis de extremo a extremo sea mucho más fácil. Finalmente, tiene una documentación ampliamente accesible, lo que simplificó el desarrollo del pipeline y la incorporación de otros usuarios.

Esperamos que esto haya sido útil. No dudes en contactarme en Twitter con cualquier pregunta: @debnilsur. ¡Feliz consulta!