Ich vermute, dass Sie für einen solchen strukturierten Datensatz ein benutzerdefiniertes Datenformat schreiben können, das für die meisten täglichen Vorgänge schneller ist (dh kleine Datenmengen aus einer beliebigen Zeit). Der Vorteil der Umstellung auf ein Standard-DB-Tool ist wahrscheinlich in einigen Extras zu sehen, z. B. bei Ad-hoc-Abfragen, Mehrfachzugriff, Replikation, Verfügbarkeit usw. Es ist auch einfacher, Hilfe bei der Pflege eines auf Standards basierenden Datenspeichers anzustellen.
Wenn ich gebeten würde, eine Datenbank zum Speichern dieser Daten einzurichten, würde ich Folgendes tun:
Vorgeschlagenes Schema
(1) Kerndaten werden in zahlreiche (1000) einzelne Tabellen mit jeweils zwei Spalten platziert:
- Zeit: entweder ein SQL DATETIME-Datentyp oder ein numerischer Typ aus einer bestimmten Epoche (dies ist der Primärschlüssel)
- value: entsprechend Ihren Daten eingegeben. Ich würde standardmäßig Gleitkommazahlen mit einfacher Genauigkeit verwenden, jedoch ist ein Festkomma-Datentyp für Finanztransaktionen möglicherweise geeigneter. Dies ist wahrscheinlich nicht indiziert.
Diese Tabellen werden sehr groß, und Sie möchten sie möglicherweise manuell nach (z. B.) Jahren partitionieren. Sie müssen jedoch die Systemleistung überprüfen und gegebenenfalls abstimmen.
Diese Tabellen benötigen eindeutige Namen, und es gibt einige Optionen. Sie können von Menschen lesbar sein (z. B. nyse_goog_dailyhighs_2010) oder (nach meiner Präferenz) zufällig. In beiden Fällen ist ein Satz von Metadatentabellen erforderlich, und zufällige Tabellennamen verhindern, dass Entwickler etwas auf den Namen schließen, das nicht abgeleitet werden sollte.
(2) Metadaten werden in separaten Tabellen gespeichert, wie von der Anwendung gefordert :
Eine zusätzliche Tabelle oder ein Satz von Tabellen ist erforderlich, um die Metadaten zu verfolgen. Diese Tabellen enthalten Daten zu Austausch, Instrument, Wert, Häufigkeit, Datumsbereichen, Herkunft (woher stammen die Daten) sowie alles, was Sie sonst noch benötigen. Diese werden Datentabellennamen zugeordnet.
Wenn genügend Daten vorhanden sind, kann diese Suche tatsächlich einen Tabellennamen und einen Datenbanknamen enthalten, wodurch eine Art von selbstimplementiertem Daten-Sharding möglich wird (sofern dies die korrekte Verwendung des Begriffs ist). Aber ich würde das zurückhalten.
Auf der Anwendungsebene habe ich dann die Metadatentabellen abgefragt, um festzustellen, wo sich meine Daten befinden. Anschließend habe ich relativ einfache Abfragen für die Big-Data-Tabellen durchgeführt, um meine Daten abzurufen.
Vorteile:
Meine (relativ begrenzte) Erfahrung ist, dass Datenbanken im Allgemeinen eine große Anzahl kleiner Tabellen einfacher verarbeiten können als eine kleinere Anzahl großer Tabellen. Dieser Ansatz ermöglicht auch eine einfachere Wartung (z. B. Löschen alter Daten, Neuerstellen einer beschädigten Tabelle, Erstellen / Neuladen von Sicherungen, Hinzufügen einer neuen Entität). Dies entkoppelt die verschiedenen Arten von Daten vollständig, wenn Sie beispielsweise Daten mit unterschiedlichen Raten haben oder unterschiedliche Datentypen benötigen.
Dieses Skinny-Table-Konzept sollte auch einen schnellen Festplattenzugriff für die von mir vermutete häufigste Abfrage ermöglichen, einen zusammenhängenden Datenbereich von einer einzelnen Entität. Die meisten Datenanwendungen sind auf Festplatten-E / A beschränkt, daher ist dies eine Überlegung wert. Wie ein Kommentator bereits angedeutet hat, ist dies eine ideale Anwendung für eine spaltenorientierte Datenbank, aber ich habe noch kein spaltenorientiertes Produkt gefunden, auf das ich meine Karriere wetten kann. Dieses Schema kommt ziemlich nahe.
Nachteile:
Etwa die Hälfte Ihres Speicherplatzes ist für die Speicherung von Zeitstempeln vorgesehen, wenn offen gesagt 100er oder 1000er der Tabellen genau dieselben Daten in der Zeitstempelspalte enthalten. (Tatsächlich ist dies eine Voraussetzung, wenn Sie einfache Tabellenverknüpfungen durchführen möchten.)
Das Speichern von Tabellennamen und das Durchführen der dynamischen Suche erfordern viel Anwendungskomplexität und Zeichenfolgenoperationen, was mich erschreckt. Aber es scheint immer noch besser zu sein als die Alternativen (siehe unten).
Überlegungen:
Achten Sie auf die Rundung in Ihrem Zeitfeld. Sie möchten, dass Ihre Werte rund genug sind, um Verknüpfungen zu ermöglichen (falls zutreffend), aber präzise genug, um eindeutig zu sein.
Achten Sie auf Zeitzonen und Sommerzeit. Diese sind schwer zu testen. Ich würde eine UTC-Anforderung für den Datenspeicher erzwingen (was mich möglicherweise unbeliebt macht) und Konvertierungen in der Anwendung verarbeiten.
Variationen:
Einige Variationen, die ich in Betracht gezogen habe, sind:
Datenfaltung : Wenn die Zeitreihen gleichmäßig verteilt sind, verwenden Sie eine Zeitstempelspalte und (zum Beispiel) 10 Datenspalten. Der Zeitstempel bezieht sich nun auf die Zeit der ersten Datenspalte, und es wird angenommen, dass die anderen Datenspalten einen gleichen Abstand zwischen diesem Zeitstempel und dem nächsten aufweisen. Dies spart viel Speicherplatz, der zuvor zum Speichern von Zeitstempeln verwendet wurde, und ist mit erheblichen Kosten für die Abfrage und / oder die Komplexität der Anwendung verbunden. Abfragen für zusammenhängende Bereiche einzelner Entitäten erfordern jetzt weniger Festplattenzugriff.
Multi-Plexing: Wenn bekannt ist, dass mehrere Zeitreihen dieselbe Zeitreihe verwenden, verwenden Sie einen Zeitstempel und (zum Beispiel) 10 Datenspalten, wie oben beschrieben. Jetzt repräsentiert jede Spalte eine andere Zeitreihe. Dies erfordert eine Aktualisierung der Metadatentabelle, bei der es sich nicht um eine Suche nach Tabellen- und Spaltennamen handelt. Speicherplatz wird reduziert. Abfragen bleiben einfach. Unabhängig vom zusammenhängenden Bereich erfordern Einzelentitätsabfragen jetzt erheblich mehr Festplattenzugriff.
Mega-Tabelle: Bringen Sie das "Multi-Plexing" -Konzept auf die Spitze und fassen Sie alle Daten einmal pro Spalte in einer Tabelle zusammen. Dies erfordert umfangreiche Datenträgerzugriffe für zusammenhängende Bereiche und Abfragen einzelner Entitäten und ist ein Wartungs-Albtraum. Beispielsweise erfordert das Hinzufügen einer neuen Entität jetzt einen Befehl MODIFY TABLE für eine Tabelle mit vielen TB.
Weitere Informationen zu diesem Format finden Sie in den verschiedenen Antworten unter:
Zu viele Spalten in MySQL
Vollständig normalisierte Tabelle:
Anstatt viele zweispaltige Tabellen zu verwenden, können Sie auch eine dreispaltige Tabelle verwenden, deren Spalten Zeit, Daten-ID und Wert sind. Jetzt müssen Ihre Metadatentabellen nur noch nach ID-Werten anstatt nach Tabellennamen oder Spaltennamen suchen, wodurch mehr Logik in die SQL-Abfragen als in die Anwendungsebene übertragen werden kann.
Etwa 2/3 des Speichers wird jetzt mit den normalisierenden Spalten belegt, sodass dies viel Speicherplatz beansprucht.
Sie können die Primärschlüsselreihenfolge (Daten-ID, Zeitstempel) für schnelle zusammenhängende Einzelentitätsabfragen verwenden. Alternativ können Sie für schnellere Einfügungen die Primärschlüsselreihenfolge (timestamp. Dataid) verwenden.
Trotz dieser Variationen sind für meine nächste Entwicklung viele Tabellen mit jeweils zwei Spalten geplant. Das oder die Methode wird bald von jemandem gepostet, der klüger ist als ich :).