Eignen sich Dokumentendatenbanken für die Speicherung großer Mengen von Stock Tick-Daten?

Question

Ich dachte an die Verwendung einer Datenbank wie mongodb oder ravendb, um eine Menge von Aktien-Tick-Daten zu speichern und wollte wissen, ob dies lebensfähig im Vergleich zu einem Standard-relationalen wie Sql Server wäre.

Die Daten wären nicht wirklich relational und würden aus einer Reihe großer Tabellen bestehen. Ich dachte auch, dass ich Summe/Min/Max Zeilen von Daten durch Minute/Stunde/Tag/Woche/Monat usw. für noch schnellere Berechnungen könnte.

Beispielhafte Daten: 500 Symbole * 60 Minuten * 60 Sekunden * 300 Tage... (pro Datensatz werden gespeichert: Datum, Eröffnung, Höchst-, Tiefst-, Schlusskurs, Volumen, Eröffnungswert - alles dezimal/fließend)

Was haltet ihr also davon?

Answer 1

Seitdem diese Frage im Jahr 2010 gestellt wurde, wurden mehrere Datenbank-Engines veröffentlicht oder haben Funktionen entwickelt, die speziell für Zeitreihen wie z. B. Aktien-Tickdaten geeignet sind:

• InfluxDB - siehe meine andere Antwort
• Cassandra

Wenn Sie mit MongoDB oder anderen dokumentenorientierten Datenbanken Leistung anstreben, empfiehlt es sich, Folgendes zu tun Ihr Schema verdrehen um Ticks in einem Objekt zu organisieren, das nach Sekunden geordnet ist (oder ein Objekt mit Minuten, wobei jede Minute ein weiteres Objekt mit 60 Sekunden ist). Bei einer spezialisierten Zeitreihendatenbank können Sie die Daten einfach abfragen mit

SELECT open, close FROM market_data
WHERE symbol = 'AAPL' AND time > '2016-09-14' AND time < '2016-09-21'

Ich dachte auch, dass ich die Datenzeilen nach Minute/Stunde/Tag/Woche/Monat usw. für noch schnellere Berechnungen summieren könnte.

Mit InfluxDB ist dies sehr einfach. Hier erfahren Sie, wie Sie die täglichen Mindest- und Höchstwerte erhalten:

SELECT MIN("close"), MAX("close") FROM "market_data" WHERE WHERE symbol = 'AAPL'
GROUP BY time(1d)

Sie können nach Zeitintervallen gruppieren, die in Mikrosekunden angegeben werden können ( u ), Sekunden ( s ), Minuten ( m ), Stunden ( h ), Tage ( d ) oder Wochen ( w ).

TL;DR

Zeitreihendatenbanken eignen sich besser als dokumentenorientierte Datenbanken für die Speicherung und Abfrage großer Mengen von Börsentickerdaten.

Answer 2

Die Antwort auf diese Frage hängt vom Umfang ab.

MongoDB ist eine großartige Möglichkeit, die Daten "rein" zu bekommen, und es ist sehr schnell bei der Abfrage von einzelnen Teilen. Es ist auch gut, da es horizontal skalierbar ist.

Sie müssen jedoch bedenken, dass alle Ihre wichtigen "Abfragen" in Wirklichkeit aus der "Batch-Job-Ausgabe" resultieren.

Gilt Groupe hat zum Beispiel ein System namens Kolibri die sie für Echtzeit-Analysen auf ihrer Website verwenden. Präsentation aquí . Im Grunde werden die Seiten auf der Grundlage der gesammelten Leistungsdaten in kurzen Abständen (15 Minuten) dynamisch gerendert.

In ihrem Fall haben sie einen einfachen Zyklus: Daten in Mongo posten -> Map-Reduce ausführen -> Daten zur Echtzeit-Optimierung in Webs pushen -> Spülen/Wiederholen.

Das kommt dem, was Sie wahrscheinlich tun wollen, ziemlich nahe. Allerdings gibt es hier einige Einschränkungen:

1. Map-reduce ist für viele Menschen neu. Wenn Sie mit SQL vertraut sind, müssen Sie die Lernkurve von Map-reduce akzeptieren.
2. Wenn Sie viele Daten einspeisen, werden Ihre Kartenreduzierungen auf diesen Boxen langsamer sein. Wenn die Antwortzeiten eine große Rolle spielen, sollten Sie wahrscheinlich Slave-/Replika-Paare in Betracht ziehen.

Auf der anderen Seite werden Sie bei SQL auf verschiedene Varianten dieser Probleme stoßen.

Natürlich gibt es hier einige Vorteile:

1. Horizontale Skalierbarkeit. Wenn Sie viele Boxen haben, können Sie diese aufteilen und eine einigermaßen lineare Leistungssteigerung bei Map/Reduce-Aufträgen erzielen (so funktionieren sie). Der Aufbau eines solchen "Clusters" mit SQL-Datenbanken ist viel aufwendiger und teurer.
2. Die Geschwindigkeit ist wirklich hoch, und wie bei Punkt 1 können Sie den Arbeitsspeicher horizontal erweitern, um die Geschwindigkeit aufrechtzuerhalten.

Wie bereits von anderen erwähnt, verlieren Sie jedoch den Zugang zu ETL und anderen gängigen Analysetools. Sie werden auf jeden Fall eine Menge eigener Analysetools schreiben müssen.

Answer 3

Hier ist mein Vorbehalt gegenüber dieser Idee - und ich gebe offen zu, dass meine Kenntnisse im Bereich der Dokumentendatenbanken gering sind. Ich gehe davon aus, dass Sie all diese Daten speichern wollen, um sie zu aggregieren oder trendbasierte Analysen durchzuführen.

Wenn Sie eine dokumentenbasierte Datenbank als Quelle verwenden, ist das Laden und Bearbeiten der einzelnen Datenzeilen (CRUD-Operationen) sehr einfach. Sehr effizient, sehr geradlinig, im Grunde wunderbar.

Das Schlimme daran ist, dass es nur sehr wenige oder gar keine Möglichkeiten gibt, diese Daten zu extrahieren und in eine Struktur zu packen, die für statistische Analysen besser geeignet ist, z. B. eine spaltenförmige Datenbank oder einen Würfel. Wenn Sie die Daten in eine einfache relationale Datenbank laden, gibt es eine Vielzahl von kommerziellen und Open-Source-Tools wie pentaho die die ETL und die Analyse sehr gut unterstützen wird.

Letztendlich sollten Sie jedoch bedenken, dass jedes Finanzunternehmen der Welt eine Aktienanalyse-/Autohandelsanwendung hat; sie haben gerade einen großen Einbruch des US-Aktienmarktes verursacht und sind kein Spielzeug :)

Answer 4

Ein einfacher Datenspeicher wie eine Key-Value- oder Dokumentendatenbank ist auch dann von Vorteil, wenn die Durchführung von Analysen die Kapazität eines einzelnen Systems sinnvollerweise übersteigt. (Oder es wird ein außergewöhnlich großer Rechner benötigt, um die Last zu bewältigen.) In diesen Fällen ist es sinnvoll, einen einfachen Speicher zu verwenden, da die Analysen ohnehin eine Stapelverarbeitung erfordern. Ich persönlich würde nach einer horizontal skalierenden Verarbeitungsmethode suchen, um die erforderlichen Analysen pro Einheit und Zeit zu bewältigen.

Ich würde den Einsatz von Hadoop für die Parallelverarbeitung in Erwägung ziehen. Entweder verwenden Sie das Framework nativ in Java/C++ oder eine höhere Abstraktionsebene: Pig, Wukong, binäre ausführbare Dateien über die Streaming-Schnittstelle usw. Amazon bietet relativ günstige Verarbeitungszeit und Speicherplatz, falls dieser Weg von Interesse ist. (Ich habe keine persönlichen Erfahrungen, aber viele haben welche und sind für ihre Geschäfte darauf angewiesen).