Wie man Cassandra DB für Time Series, Servermetriken modelliert

Question

Mein Name ist Daniel, Ich bin ein Newcomer accountwise aber eine lange Zeit lurker. Ich beschloss, Apache Cassandra für meine nächsten "lets write schreiben Code, während die Kinder schlafen" -Projekt zu lernen.

Was ich schreibe ist eine nette kleine API, die Lesen und Schreiben gegen eine Cassandra-Datenbank tun wird. hatte ich eine Menge der db-Layout in mongodb herausgefunden, aber für mich ist es Zeit, auf und wachsen als Ingenieur zu bewegen :)

Mission: I-Metriken von den Servern in meinem Rack sammeln, wird ein Agent senden Sie eine Payload von Metriken jede Minute. Ich habe den API-Teil ziemlich viel herausgefunden, werde JWT-Tokens verwenden, die die Nutzdaten signieren. Die Art der Daten, die ich speichern werde, kann unten gesehen werden. cpuload, CPUUsage, memusage, Usage usw.

Der Teil, wo ich mit cassandra bin verwirrt ist, wie das eigentliche Modell zu schreiben, verstehe ich die storagengines Art schreibt sie alle als Zeitreihe auf der Festplatte für mich machen liest schon erstaunlich. Ich weiß, alles, was ich würde zusammen peitschen jetzt würde für mein Labor arbeiten, da es nur 30 Maschinen, ist, aber ich versuche zu verstehen, wie diese Dinge richtig gemacht werden und wie es für ein reales Leben Szenario wie Serverdichte, Datadog getan werden konnte, "Fügen Sie Ihren bevorzugten Server-Überwachungsdienst ein". :)

Aber wie haben Sie erfahrene Ingenieure, die ein solches Schema entwerfen?

Einsatzszenarien für die Datenbank:

• Schreib Nutzlasten jeder Minute durch die api. (Lässt sich vorstellen, das ist atleast 100k schreibt pro Minute aus Gründen der etwas nützliche Lern)

• Lesen Sie die Vermögenswerte im Zusammenhang mit denen Benutzer-ID

  • Pull neuesten Daten (3h)
  • Pull neuesten Daten (täglich)
  • neuesten Daten (wöchentlich)
  • Pull neuesten Daten (monatlich) ziehen
  • etc etc

• Generieren Sie monatliche PDF-Berichte, die die Betriebszeit und ähnliches anzeigen.

Sollte ich legen Sie die Zeilen die volle Nutzlast enthält, oder bin ich besser von ihnen pro Service-Basis einfügen: timeuid | CPUUsage
für den Dienst Reihe

CREATE TABLE metrics(
    id uuid PRIMARY KEY, 
    assetid int, 
    serviceType text, 
    metricValue int 
) 

Alles in einem

CREATE TABLE metrics(
    id uuid PRIMARY KEY, 
    assetid int, 
    cpuload int, 
    cpuusage int, 
    memusage int, 
    diskusage int, 
) 

In Mongo würde ich die Eimer vorallocate, und auch eine schnelle lesen avg innerhalb der Dokument. Also im Webgui konnte ich einfach die avg stats für vordefinierte Zeiträume zeigen.

Beispiele für Dummköpfe werden sehr geschätzt. Hoffe du kannst mein eher schlechtes Englisch entziffern.

Gerade gefunden diese URL in der SO Vorschläge: Cassandra data model for time series Ich denke, das ist etwas, das für mich auch gilt.

Sincerly Daniel Olsson

Answer 1

Für Ihr Datenmodell, würde ich Zeit als Clustering-Spalte hinzufügen vorschlagen:

CREATE TABLE metrics(
id uuid, 
time timeuuid, 
assetid int, 
cpuload int, 
cpuusage int, 
memusage int, 
diskusage int, 
PRIMARY KEY (id, time) WITH CLUSTERING ORDER BY (time DESC)) 

Verwenden absteigende Reihenfolge zuerst die aktuellen Messwerte zu halten. Anschließend können Sie Abfrage die LIMIT-Klausel erhalten unter Verwendung der neuesten Stunde:

SELECT * FROM metrics WHERE id = <UUID> LIMIT 60 

Oder Tag:

SELECT * FROM metrics WHERE id = <UUID> LIMIT 1440 

Je nachdem, wie lange Sie die Daten zu halten, sollten Sie eine Spalte hinzufügen für Jahr, Monat oder Tage an die Tabelle, um die Partitionsgröße zu begrenzen. Zum Beispiel, wenn Sie Daten zu halten für 3 Monate wünschen, ein Monat Spalte können Sie Ihre Schlüssel von id und Monat zu partitionieren hinzugefügt werden:

CREATE TABLE metrics(
id uuid, 
time timeuuid, 
month text, 
assetid int, 
cpuload int, 
cpuusage int, 
memusage int, 
diskusage int, 
PRIMARY KEY ((id, month), time) WITH CLUSTERING ORDER BY (time DESC)) 

Wenn Sie Daten für mehrere Jahre halten, verwenden Jahr + Monat oder ein Datumswert

In Bezug auf Ihre letzte Frage, über separate Tabellen oder eine einzelne Tabelle. Cassandra unterstützt spärliche Spalten, sodass Sie mehrere Einfügungen in einer gemeinsamen Tabelle für jede Metrik vornehmen können, ohne Daten zu aktualisieren. Es ist jedoch immer schneller, nur einmal pro Zeile zu schreiben.

Sie benötigen möglicherweise separate Tabellen, wenn Sie nach anderen Metriken durch einen alternativen Schlüssel suchen müssen. Suchen Sie beispielsweise nach der Festplattenbelegung nach ID und Festplattennamen. Sie benötigen eine separate Tabelle oder eine materialisierte Ansicht, um dieses Abfragemuster zu unterstützen.

Schließlich definiert Ihr Schema eine assetid, aber das ist nicht in Ihrem Primärschlüssel definiert, so dass Sie mit Ihrem aktuellen Schema nicht mit Assetid abfragen können.