HISTORIAL DE CUOTAS
Guarda tú mismo el historial de cuotas de Pinnacle.
La API de cuotas de Pinnacle sirve los precios actuales y dice claramente que no tiene archivo histórico. El historial de una línea, un precio de cierre, la forma de un mercado a lo largo de una semana: todo eso solo existe si lo registraste mientras sondeabas. Esta página da un diseño de tablas, una regla de deduplicación y la aritmética de retención para un almacén que se mantiene pequeño.
Qué registrar
Con dos tablas basta. Una guarda los eventos, escritos una vez y actualizados cuando cambia la hora de inicio o el estado: event_id, sport_id, league, home, away y starts. La otra guarda los cambios de precio, una fila cada vez que el precio de una selección difiere de la última fila que tienes de ella: qué evento, qué periodo, qué mercado, qué lado, el precio y cuándo lo observaste.
CREATE TABLE price_changes (
event_id bigint NOT NULL,
period smallint NOT NULL,
market text NOT NULL, -- money_line, spread, total
side text NOT NULL, -- home, draw, away, over, under
points numeric(6,2), -- spread or total line, else NULL
price numeric(8,3), -- NULL when the market closed
observed_at timestamptz NOT NULL,
cursor_last bigint NOT NULL, -- the response's last value
PRIMARY KEY (event_id, period, market, side, points, observed_at)
);Guarda el precio como cuota decimal exactamente como se sirve, y conserva el nulo cuando un mercado está suspendido o cerrado. Una fila nula es información: registra cuándo desapareció el mercado, que es lo que necesita una consulta de precio de cierre.
Escribe solo lo que cambió
El cursor since ya limita un sondeo a los eventos que cambiaron, pero dentro de un evento con cambios la mayoría de las selecciones suelen estar igual que antes. Compara cada selección con la última fila que tienes e inserta solo cuando haya diferencia. Un pequeño mapa en memoria con el último precio por selección hace que la comparación sea gratis; reconstrúyelo desde la tabla al arrancar. Sin esta regla, un tablero de fútbol en vivo escribe todas las selecciones en cada sondeo, y la tabla crece con la tasa de sondeo y no con el movimiento real del mercado.
Capturar el cierre
El precio de cierre es el último precio observado antes de la hora de inicio del evento, y solo existe en tu almacén si el poller estaba funcionando en ese momento. Sondea los tableros prepartido hasta el mismo inicio, ya que el cursor mantiene el coste bajo, y deja que un trabajo que corre unos minutos después de cada inicio marque la última fila prepartido de cada selección como el cierre. Por qué el cierre merece su propia columna se explica en la guía de valor de la línea de cierre en pnclDATA: es la referencia contra la que la mayoría de los apostadores miden sus precios.
Aritmética de retención
El crecimiento del almacén depende del movimiento, no del sondeo, una vez que la deduplicación está en marcha. Las cifras de abajo ilustran la aritmética, no miden el feed; sustitúyelas por tus propios recuentos tras una semana de registro.
| Supuesto | Valor | Resultado |
|---|---|---|
| Cambios de precio escritos por día, cinco deportes, en vivo y prepartido | 200,000 | Filas por día |
| Bytes por fila con índice | 120 | 24 MB al día |
| Filas en bruto conservadas | 90 días | Unos 2,2 GB |
| Último precio por hora por selección más allá de 90 días | 1 fila por hora | Bastante menos de una décima parte del tamaño en bruto |
Particiona la tabla de cambios por mes y elimina particiones en lugar de borrar filas. Conserva las filas de eventos mientras existan los cambios que las referencian.
Los huecos siguen siendo huecos
Nada en la API reproduce el pasado. Un poller que estuvo caído una hora tiene una hora sin filas, y el siguiente sondeo devuelve el estado actual, no el camino que llevó hasta él. Registra las interrupciones en una tabla aparte para que una consulta sobre el historial distinga un mercado tranquilo de uno ausente, y trata el día en que empezaste a registrar como el primer día que cubre tu historial. Qué comprobar antes de fiarte del archivo de otro con estos precios está en la guía de datos históricos de cuotas en pnclAPI.
Preguntas antes de la primera fila
¿El endpoint de caídas puede rellenar el historial hacia atrás?
Solo unos minutos. El endpoint REST de caídas devuelve movimientos recientes dentro de una ventana acotada, lo que ayuda tras una interrupción corta y no más allá.
¿Debería guardar la respuesta completa como JSON?
Conserva una copia comprimida de las respuestas en bruto durante unos días si quieres volver a derivar filas tras un bug del parser, pero consulta la tabla normalizada. El JSON en bruto crece con la tasa de sondeo; la tabla de cambios crece con el mercado.
¿La clave gratuita permite esto?
Para un tablero sondeado cada 15 minutos, sí, y el historial será tosco. Un historial de línea útil necesita los planes REST de pago, cuya tasa por segundo es la cifra desde la que dimensionar.
La ausencia de archivo y el comportamiento del cursor siguen la documentación publicada por el proveedor, revisada el 26 de septiembre de 2026. Publicado el .