Ich stehe gerade vor einer kniffligen Entscheidung bei unserem neuen Projekt. Wir müssen eine Menge unstrukturierter Logdaten aus verschiedenen Quellen zusammenführen und analysieren. Mein erster Impuls war, alles in eine traditionelle relationale Datenbank zu zwingen, aber das fühlt sich immer mehr nach dem falschen Werkzeug an. Ich frage mich, ob wir nicht besser eine andere Art von System brauchen, eines, das besser mit dieser Art von flexiblen, verschachtelten Daten umgehen kann. Ich habe das Gefühl, ich kämpfe gegen das Schema an, anstatt dass es mir hilft. Hat jemand ähnliche Erfahrungen gemacht, als die Daten einfach nicht in die starren Tabellen passen wollten?
Es klingt nach einer echten Diskussion um Schema mit der Praxis der Daten. Unstrukturiertes Logmaterial aus vielen Quellen braucht kein starres relationales Modell. Stattdessen könnt ihr über Data Lake oder Suchplattformen nachdenken die verschachtelte Felder gut handhaben. Man könnte Parquet oder ORC in einem Lakehouse verwenden oder JSON Dokumente in einer passenden Datenbank speichern oder Logs direkt in eine Suchmaschine indexieren. Das Schema on read bedeutet dass ihr das Abfrage Schema erst beim Zugriff anlegt und nicht vorher. Das verschafft Flexibilität aber die Abfragen werden komplexer und Kosten können steigen. Bevor ihr euch entscheidet klärt welche Abfragen welche Dashboards welche Compliance Anforderungen bestehen. Dann könnt ihr grob skizzieren welche Teile rohen Log Daten bleiben und welche als strukturierte Metriken extrahiert werden.
Ich bleibe skeptisch ob der Schritt in NoSQL oder Lake Ansätze automatisch besser ist. Relationale Systeme können JSON oder verschachtelte Felder speichern etwa in Postgres JSONB oder ähnliche Funktionen. Man wirft ihnen dann jedoch neue Herausforderungen zu. Oft hilft eine hybride Architektur Kernmetadaten in der relationalen Welt und der Rest in einem flexibleren Speicher. Wichtig ist dass ihr klare Kriterien für Abfragen und Latenz definiert statt dem Trend zu folgen. Wenn ihr zu früh alles in Tabellen presst verliert ihr die Leistungsfähigkeit der Logs.
Ja hatte ich auch. Man sammelt Felder aus Logsystemen und Messages aus verschiedenen Ecken und fühlt sich als müsste man fortwährend neue Tabellen bauen. Ein erster Schritt ist ein gemeinsames Event Format definieren und rohe Logs speichern statt zu stark zu transformieren und erst später schauen was wirklich abgefragt wird.
Vielleicht hilft eine Idee namens Schema on read als Leitidee um die Daten verschachtelt zu halten und dennoch zu analysieren. Es ist kein Freifahrtsschein aber es reduziert die Friktion beim Intake. Man nutzt einen Data Lake oder eine Such Engine, baut Indizes auf Felder und skaliert Zeitscheiben. Die Kunst ist dann sinnvolle Abfragen zu definieren bevor man tiefer in die Verschachtelungen geht.
Aus Lesersicht wirkt es oft verführerisch einfach alles in einem neuen System abzulegen doch die Erwartungen der Stakeholder müssen erfüllt werden. Dashboards brauchen konsistente Metriken und Logs brauchen Kontext. Vielleicht ist der Fokus auf Verschachtelungen eine Ablenkung von sinnvollen Kennzahlen.
Was wäre wenn die eigentliche Frage nicht lautet welches System sondern welches minimale Format ihr konsistent erfasst damit ihr überhaupt darauf Antworten bauen könnt?
