Ich habe heute die Ticker-Feed-Struktur von GRVT durchgesehen, hauptsächlich weil ich verstehen wollte, was genau ein einzelnes Ticker-Update tatsächlich enthält, um das Markt-Datenbild, das ich über diesen Sprint hinweg aufgebaut habe, sauber abzuschließen.
Ein Ticker spiegelt vermutlich den zuletzt gehandelten Preis, das 24-Stunden-Hoch und -Tief, das 24-Stunden-Volumen und sehr wahrscheinlich auch die prozentuale Veränderung in demselben Zeitfenster wider. Das Ganze wird als kompakter Snapshot aktualisiert, statt dass ein Client diese Statistiken selbst aus der Roh-Trade-Historie ableiten muss.
Was ich bemerkenswert finde, ist, dass das im Grunde eine Komfortschicht ist, die auf Daten aufbaut, die technisch gesehen ohnehin aus dem Trades-Feed ableitbar sind, den ich zuvor untersucht habe. Ein Client könnte theoretisch das 24-Stunden-Hoch, -Tief und das Volumen berechnen, indem er die komplette Trade-Historie selbst verarbeitet. Aber wenn GRVT diese Zusammenfassung berechnet und direkt streamt, nimmt das die tatsächliche Rechenlast von jedem einzelnen Client weg, der andernfalls dieselbe gleitende Berechnung unabhängig pflegen müsste.
Das hängt mit einem Muster zusammen, das ich diese Woche auch in der breiteren Feed-Planung von GRVT bemerkt habe: Rohes, granulareres Datenmaterial existiert – etwa Orderbook-Tiefe und einzelne Trades –, aber zusätzlich gibt es zusammengefasste, vorab berechnete Ansichten für Fälle, in denen die volle Detailtiefe nicht wirklich nötig ist.
Ich schließe diesen Sprint mit der Erkenntnis ab, dass die API-Oberfläche von GRVT offenbar durchgängig um genau diesen Tradeoff herum gestaltet ist: Granulare Daten für diejenigen, die Präzision brauchen, und zusammengefasste Daten für diejenigen, die einfach schnell ein korrektes Bild benötigen.
@grvt_io #grvt
Ein Ticker spiegelt vermutlich den zuletzt gehandelten Preis, das 24-Stunden-Hoch und -Tief, das 24-Stunden-Volumen und sehr wahrscheinlich auch die prozentuale Veränderung in demselben Zeitfenster wider. Das Ganze wird als kompakter Snapshot aktualisiert, statt dass ein Client diese Statistiken selbst aus der Roh-Trade-Historie ableiten muss.
Was ich bemerkenswert finde, ist, dass das im Grunde eine Komfortschicht ist, die auf Daten aufbaut, die technisch gesehen ohnehin aus dem Trades-Feed ableitbar sind, den ich zuvor untersucht habe. Ein Client könnte theoretisch das 24-Stunden-Hoch, -Tief und das Volumen berechnen, indem er die komplette Trade-Historie selbst verarbeitet. Aber wenn GRVT diese Zusammenfassung berechnet und direkt streamt, nimmt das die tatsächliche Rechenlast von jedem einzelnen Client weg, der andernfalls dieselbe gleitende Berechnung unabhängig pflegen müsste.
Das hängt mit einem Muster zusammen, das ich diese Woche auch in der breiteren Feed-Planung von GRVT bemerkt habe: Rohes, granulareres Datenmaterial existiert – etwa Orderbook-Tiefe und einzelne Trades –, aber zusätzlich gibt es zusammengefasste, vorab berechnete Ansichten für Fälle, in denen die volle Detailtiefe nicht wirklich nötig ist.
Ich schließe diesen Sprint mit der Erkenntnis ab, dass die API-Oberfläche von GRVT offenbar durchgängig um genau diesen Tradeoff herum gestaltet ist: Granulare Daten für diejenigen, die Präzision brauchen, und zusammengefasste Daten für diejenigen, die einfach schnell ein korrektes Bild benötigen.
@grvt_io #grvt