2016-06-06 15 views
0

so ein schnelles Update auf, warum ich diese Frage erstellt habe.DocumentDB - Telemetrie Daten speichern

Derzeit speichern wir unsere Telemetriedaten unserer Geräte im Feld innerhalb von Azure SQL Server. Das funktioniert gut (habe eine Menge Erfahrung mit EF, LINQ und Beziehungs-DBs). ABER ich bin mir bewusst, dass dies wahrscheinlich nicht die beste Lösung ist, um "große" Daten zu speichern (die Daten sind noch klein, werden aber innerhalb eines Jahres wachsen)).

Ich habe DocumentDB als unsere mögliche Lösung ausgewählt, um nur unsere Ereignishistorie zu speichern. Der Rest wird in SQL bleiben - Benutzer, Profile, Geräteinfo, Sim, Vehicle usw., da ich die Entwicklung nicht komplett anhalten will, da wir 100% auf docdb umstellen und einfach nur das beste kurzfristige - Kosten + Leistung machen.

dieses Video Wenn man durch kam ich endlich mit einer möglichen Lösung auf, wie Telemetriedaten zu speichern - https://www.youtube.com/watch?v=-o_VGpJP-Q0 Sie empfahlen Einen Eintrag pro Zeitperiode (zB 1 pro Stunde verwendet wird). Ist das der empfohlene Ansatz noch?

enter image description here

[Index] 
    public DateTime TimestampUtc { get; set; } 
    public DateTime ReceivedTimestampUtc { get; set; } 
    [Index] 
    public EventType EventType { get; set; } 
    public Guid ConnectionId { get; set; } 
    public string RawEventMessage { get; set; } 
    [Index] 
    public Sender Sender { get; set; } 
    [Index] 
    public Channel Channel { get; set; } 
    public DbGeography Location { get; set; } 
    public double? Speed { get; set; } 
    public double? Altitude { get; set; } 
    public Int16? Heading { get; set; } 
    public Byte? HDOP { get; set; } 
    public Byte? GPSFixStatus { get; set; } 
    public Byte? GPSFixType { get; set; } 
    public string Serial { get; set; } 
    public string HardwareVersion { get; set; } 
    public string FirmwareVersion { get; set; } 
    public string Relay1 { get; set; } 
    public string Relay2 { get; set; } 
    public string Relay3 { get; set; } 
    public string Ign { get; set; } 
    public string Doors { get; set; } 
    public string Input1 { get; set; } 
    public string Input2 { get; set; } 
    public string Out1 { get; set; } 
    public string Out2 { get; set; } 
    public int V12 { get; set; } 
    public int VBat { get; set; } 
+0

* Haftungsausschluss - Ich bin einer der Mitautoren des // Build-Videos, auf das Sie verwiesen haben * - Es gibt wirklich keinen "empfohlenen" Ansatz zum Speichern von Telemetriedaten. Was wir zur Speicherung von Telemetriedaten gezeigt haben, war ein spezifischer Modellierungsfall, basierend auf einigen realen Lösungen, die wir behandelt haben, spezifisch für eine Dokumentendatenbank wie DocumentDB (die für Ihren speziellen Fall funktioniert oder nicht). Es gibt andere Möglichkeiten zum Modellieren und sogar verschiedene Datenbank-Engine-Typen. –

+1

Hey Dave, danke für die Antwort :) Yeah war heute brainstorming und stieß auf dieses gute Video und es gab mir eine andere Möglichkeit. Alles funktioniert gut in SQL nur für langfristige – David

+0

Freut mich, es hat Ihnen gefallen - danke. :) Und wenn es dir ein paar neue Dinge zum Nachdenken gab, dann halte ich es für einen Erfolg. –

Antwort

2

Das ist einer von mehreren möglichen Alternativen ist. Was am besten ist, hängt davon ab, wie Ihre Daten aussehen. Zum Beispiel, wenn Sie Ereignisse haben, die sich in ihrem Anfangsdatum/-zeit und -dauer (oder Enddatum/-zeit) unterscheiden oder wenn Sie alle Statusänderungen von Entitäten verfolgen, dann ist etwas wie Richard Snodgrass 'temporales Datenmodell ideal. Interessanterweise hat Microsoft SQL Server 2016 vor kurzem direkte Unterstützung für temporal tables hinzugefügt, aber sie sind seit einiger Zeit in der SQL-Spezifikation als TSQL2. Beachten Sie, dass die TSQL2-Spezifikation sowohl valid-time als auch transaction-time unterstützt, aber ich glaube, dass die jüngste MS SQL 2016-Ergänzung nur gültige Zeit unterstützt ... aber das ist in Ordnung, da dies das wertvollste ist. Ich weise nur darauf hin, dass es schwierig ist, sich über die Funktionsweise einer Tabelle mit gültigen Zeitangaben zu informieren, ohne dass zusätzliche Transaktionszeit hinzukommt.

Das Schöne an diesem Ansatz ist, dass Sie sich bei der Erfassung der Daten nicht erst für die benötigte Zeitgranularität entscheiden müssen, sondern nur dann, wenn Sie sie aggregieren.

Wie Sie jedoch schon gesagt haben, ist SQL für solche großen Datensätze nicht ideal. Also, ich habe gültige Zeit-Modell von Richard Snodgrass Stil auf DocumentDB in meiner Lumenize Bibliothek insbesondere die TimeSeriesCalculator und seine andere Zeitreihen-Funktionalität implementiert. Lesen Sie die Seiten 10-19 here für einen Hintergrund für das Datenmodell und allgemeine Operationen in der Lumenize-Zeitreihenanalyse. Dieses Deck ist für eine Implementierung gedacht, die ich während der Rallye gemacht habe, die Lookback API, die auf MongoDB basiert, aber die Konzepte sind die gleichen und ich bin jetzt zu DocumentDB gewechselt (aber Rally hat nicht).

Ein weiterer Kommentar zu Ihrem vorgeschlagenen Modell, möglicherweise möchten Sie für jede Lesung ein separates Dokument in Betracht ziehen. Es ist ein wenig verwirrend aus dem Beispiel, wenn es ein Dokument pro Minute oder eins pro Gerät gibt. Wenn es eins pro Gerät pro Stunde ist, dann können Sie sicher sein, dass Sie nie über 60 Minuten gehen werden, was in Ordnung wäre, aber in fast jeder anderen Art, die ich mir vorstellen kann, sieht es so aus, als hätten Sie das Risiko eines einzigen Das Dokument wächst unbegrenzt, was in DocumentDB (und allen NoSQL-Datenmodellierungen) ein großes No-No ist. Auch wenn es nicht unbegrenzt ist, würde es viele In-Place-Updates beinhalten. Da Ihr System wahrscheinlich schwer schreiben wird, würde ich vorschlagen, dass Sie mit einem einzigen Dokument pro Lesung besser dran sind. Wenn Sie später denormalisierte Aggregationen für Geschwindigkeit speichern müssen, haben Sie immer noch die Möglichkeit, dies zu tun. Du brauchst es vielleicht nicht einmal. Lassen Sie die Leistung des Produktionssystems diese Entscheidung mitteilen.

Ich schlage vor, dass Sie Zeit-Dimensionen für Stern-Schemas nachlesen.Es sieht sehr ähnlich aus, was Sie planen, aber es ist auch ideal für den denormalisierten Aggregationsspeicher, den ich beschreibe. Ich habe keine Aufstellungen von Star-Schema-Konzepten für NoSQL gesehen, aber here ist eine aus der traditionellen SQL-Welt, die Ihnen mit den Konzepten helfen wird.

Wie gesagt, es gibt viele Alternativen und ohne mehr über Ihre Situation zu wissen, kann ich nicht wissen, welches das Beste ist.

+0

Danke für die tolle Antwort! Ich werde es so schnell wie möglich durchgehen, in der Zwischenzeit werde ich die Datenrate erklären, wie die Daten aussehen und wie sie verwendet werden. Für jetzt sagen wir sicher 1 Paket alle 5-10 Minuten so sehr wenig ... für jetzt! Sicher zu sagen, ich sollte für 1 jede Sekunde entwerfen, aber die Daten von den Geräten in 30-60 Sekunden Blöcke bekommen (irgendwie irrelevant). Ich habe einige meiner ersten Datenmodell Code zu meinem ursprünglichen Beitrag hinzugefügt. – David

+0

Der größte Teil des Inhalts wird Null sein, da nur bestimmte Nachrichten bestimmte Felder ausfüllen. Ich weiß nicht, ob dies auch Auswirkungen hat ... – David

+0

Es ist möglich, 'null' anzugeben, indem das Feld weggelassen wird. Sie müssen bei Ihren Abfragen ein wenig vorsichtig sein, da ein tatsächlicher Nullwert und ein fehlender Wert unterschiedlich reagieren. Verwenden Sie 'IS_DEFINED (...)' statt 'IS_NULL (...)'. Dieser Ansatz hat Vorteile für die Speicherung, macht aber auch Ihre Indizes kleiner und schneller. –

0

Ok, ich denke, ich gehe für das 1 Dokument pro Ereignis (für jetzt 1 alle 5 Minuten, könnte aber zu 1 pro Sekunde pro Gerät ändern). Der Grund dafür ist an ein Dokument anhängen sollte sicherlich teuer sein, da Sie eine "ersetzen" auf diesem Dokument tun müssen? (Unterstützt Docdb jetzt Append/Teilaktualisierungen?) Sicherlich beinhaltet das ein Lesen und dann ein zunehmendes Ersetzen, was teurer und zeitgerechter wäre, als nur ein neues Dokument pro Ereignis hinzuzufügen. Die einzige Sorge ist, wenn wir Millionen/Milliarden von Dokumenten haben ... ist das in Ordnung?