Ich glaube, dass buchstäblich alle großen NoSQL-Datenbanken diese Anforderung unterstützen werden, insbesondere wenn Sie nicht wirklich über ein großes Datenvolumen verfügen (was die Frage aufwirft, warum NoSQL?).
Allerdings musste ich kürzlich eine NoSQL-Datenbank für Zeitreihendaten entwerfen und damit arbeiten, damit ich etwas zu diesem Design beitragen kann, das dann für alle anderen extrapoliert werden kann.
Unsere gewählte Datenbank war Cassandra , und unser Design war wie folgt:
- Ein einziger Schlüsselraum für alle 'Symbole'
- Jedes Symbol war eine neue Zeile
- Jeder Zeiteintrag war eine neue Spalte für diese relevante Zeile
- Jeder Wert (kann mehr als ein einzelner Wert sein) war der Wertteil des Zeiteintrags
Auf diese Weise können Sie alles erreichen, was Sie wollten, insbesondere die Daten für ein einzelnes Symbol lesen und gegebenenfalls einen Bereich verwenden (Spaltenbereichsaufrufe). Obwohl Sie sagten, die Leistung sei nicht kritisch, war sie es für uns, und dies war auch ziemlich leistungsfähig - alle Daten für ein einzelnes Symbol werden per Definition sortiert (Spaltennamensortierung) und immer auf demselben Knoten gespeichert (keine knotenübergreifende Kommunikation für einfache Abfragen ). Schließlich lässt sich dieses Design gut auf andere NoSQL-Datenbanken übertragen, die über dynamische Spalten verfügen.
Darüber hinaus finden Sie hier einige Informationen zur Verwendung von MongoDB (und ggf. begrenzten Sammlungen) für einen Zeitreihenspeicher:MongoDB als Zeitreihendatenbank
Abschließend finden Sie hier eine Diskussion über SQL vs. NoSQL für Zeitreihen:https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Ich kann dieser Diskussion Folgendes hinzufügen:
- Die Lernkurve für NoSQL wird höher sein, Sie erhalten die zusätzliche Flexibilität und Funktionalität nicht umsonst in Bezug auf „weiche Kosten“. Wer wird diese Datenbank operativ unterstützen?
- Wenn Sie davon ausgehen, dass diese Funktionalität in Zukunft wachsen wird (entweder mehr Felder, die zu jedem Zeiteintrag hinzugefügt werden müssen, oder viel größere Kapazität in Bezug auf die Anzahl der Symbole oder die Größe der Zeitreihen der Symbole), dann entscheiden Sie sich definitiv für NoSQL. Der Flexibilitätsvorteil ist enorm, und die Skalierbarkeit, die Sie (mit dem obigen Design) sowohl auf der Basis "pro Symbol" als auch auf der Basis der "Anzahl der Symbole" erhalten, ist nahezu unbegrenzt (ich sage fast unbegrenzt - die maximale Anzahl von Spalten pro Zeile liegt in den Milliarden, maximal). Zeilen pro Schlüsselraum ist unbegrenzt, glaube ich).
