Elasticsearch hunderte von Indizes ist normal?

[Falc410]

Ich habe täglich mehrere Scripte laufen die Daten in eine Elasticsearch schreiben. Allerdings würde ich gerne die Daten nach 30 - 90 Tagen wieder löschen da diese nicht mehr notwendig sind. Nun habe ich gegooglet und es wird NICHT empfohlen, das über eine Delete Query zu machen, sondern Index Lifecycle Management zu verweden (ILM).
Ich soll also für jeden Tag einen neuen Index anlegen. Über Index-Patterns kann ich trotzdem darauf zugreifen aber ich frage mich ob es kein Problem ist wenn ich auf einmal hunderte oder sogar tausende Indexe habe die dann alle noch dazu gleichzzeitig abgefragt werden.

Aktuell habe ich 4 Scripte, aber es werden noch mehr. Ich gehe mal von mindestens 10 aus bis Ende 2023. Sagen wir mal, ich möchte die Daten 90 Tage aufheben, dann wären das 900 Indexe die existieren. Bei vielen Queries muss ich alle Abfragen, mindestens die von einem Script, aber es gibt eben auch welche die mehrere Scripts benutzen, das sind dann 90 Indexe pro Script welches ich einbinden möchte.

Ich hatte gedacht, ich sollte die Anzahl der Indexe lieber gering halten (bzw. abhängig wie viele Nodes ich einsetze - ich plane mit 3 Nodes in einem Cluster).

 

[SaxnPaule]

Du musst es ja nicht auf die Spitze treiben. Lasse doch für jeden Monat einen Index anlegen.

Kannst ja mal Benches machen und 10 Mio Datensätze in einen, 10 oder 100 Indices packen.

 

[Falc410]

Ich hab zum Glück keine Vorgaben vom Datenschutz, dass die Daten genau nach X Tagen gelöscht sein müssen, also monatliche Indize würden auch gehen. In den Tutorials wurde halt pro Tag empfohlen, also Indexname-YYYY-MM-DD z.B.

Müsste mal schauen wie viel Zeit ich investieren kann um das sinnvoll zu benchen.

 

[Tornhoof]

ES ist dafür ausgelegt. Je nach wie groß die Indexe werden (pro Tag/Woche/Monat) ist natürlich eine andere Granularität besser.
Die Anzahl der Indexe hat nicht direkt was mit der Größe des Clusters zu tun. Der Overhead ist aber natürlich da. Wenn du jeden Tag nur 1MB schreibst, dann nicht täglich rotieren, wenn du 1GB schreibst dann schon (etwas überspitzt).
Die allgemeine Aussage ist, dass es einfacher ist komplette Indexe z.b. zu rotieren, als Teile eines Index.

Wenn du zb logs hast, dann wäre eine Variante du rotierst pro Woche, und schmeißt sie nach einem Monat weg oder so.

Und ja ILM ist richtig dafür. Wenn du fixe Namen hast für die Indexe (also z.b. Index "Heute") dann ist sind aliase dafür da.

 

[Skysnake]

Also ich kenne mich mit ELK nicht ganz so gut aus, aber 1000 Indizes mehr oder weniger sollten wohl eher wayne sein.

Wie so oft. Nicht spekulieren sondern Benchmarken

Ich gehe mal stark davon aus, dass das löschen so galt effizienter zumachen ist.

Über wie viele Daten reden wir denn binnen 90 Tagen?

Wir haben ne ELK Installation mit Tausenden von Quellen über viele Monate (12+). Das waren dann nen TB oder mehr an Datenbank. So lange man nicht über alles für Monate zurück geht ist das absolut kein Thema.

Das verstehen viele nicht. Die Performance der Datenbank hängt nicht davon ab wie viele Daten in der Vergangenheit da sind auf die man nicht zugreift sondern nur davon aus wie viele Daten das Querry überhaupt zugreifen muss.

 

[Falc410]

Ja ich denke monatlich oder wöchentlich rotieren passt. Ich lese mich gerade in ILM ein (bzw. bei AWS Opensearch heisst es dann ISM). Mir ist noch nicht ganz klar ob ich das rotieren und umbennen komplett mit der Policy machen kann. Das wäre natürlich super wenn ich meine Scripte nicht anpassen muss - die schreiben dann immer in den selben Index und die Policy macht nach einem Monat ein Rename z.B. - so sollte das funktionieren oder?

Die Daten die wir schreiben sind aktuell relativ gering - wir sind da noch im MByte Bereich (pro Tag), aber ich will das Zeugs eben nicht unendlich lange aufheben.

 

[Skysnake]

Blöde Frage, warum willst du es nicht aufheben?

Speicher ist heutzutage extrem günstig. Ich sehe daher kaum einen Grund Sachen zu löschen. Man stellt dann doch immer mal wieder Fest das man damit etwas anfangen kann.

 

[SaxnPaule]

Kommt immer auf die Daten an. Aufheben können und dürfen ist ein Unterschied

DSGVO sag ich nur....

 

[Skysnake]

Hat er aber schon verneint

Ich hab zum Glück keine Vorgaben vom Datenschutz, dass die Daten genau nach X Tagen gelöscht sein müssen

Ich habe bisher halt die Erfahrung gemacht, dass die Leute gar nicht verstehen wie die Performance Charakteristik von den DBs ist. Die denken immer an das Verhalten ner rationalen Datenbank und das sind die time Series DBs einfach nicht.

 

[Falc410]

Uns kostet Speicherplatz schon etwas in AWS und hinzu kommt, dass die Daten für uns einfach wirklich unnötig sind wenn diese nicht aktuell sind. Wir überlegen gerade noch was ein sinnvolles Zeitfenster ist, aber wie gesagt es wird wohl auf 4-12 Wochen hinaus laufen.

Hier geht es primär darum, dass uns die Kosten nicht explodieren oder das Cluster auf einmal out of space ist. Die Abfragen die kommen werden kann ich jetzt noch gar nicht einschätzen aber auch hier ist es natürlich von Vorteil wenn ich weniger Daten durchsuchen muss.

 

[Skysnake]

Also mit nem billigen Server für 3-5k kannst du TB an Daten speichern und bearbeiten mit ELK.

128GB Ram oder 256 und SSDs drunter und die Kiste rennt mit 16-32 Cores wie Hölle.

Je nachdem wie ihr das nutzt reicht da auch nen einfacher Desktop für.

Also über welche "Kosten" redest du da? Für mich können das eigentlich keine für ne Firma relevanten Kosten sein. Die HW sind ja wenn überhaupt die Kosten von nem MannMonat.

 

[Falc410]

Wir sind in der Cloud und davon abgesehen ist ein Server ja noch kein Cluster. Ich plane für den Start ein 3 Node Cluster, für Testing verwende ich derzeit t3.small.search Instanzen für Production später sind m6g.large.search angedacht. Das ist der Hauptkostenfaktor, neben den Daten natürlich.

Von den reinen Hardwarekosten abgesehen musst du ja auch noch den Administrationsaufwand hinzuzählen um das Teil zu betreiben. Das war eigentlich der Hauptgrund gegen Elastic selbst hosten vs. Opensearch.

 

[Skysnake]

Also aus eigener Erfahrung kann ich sagen, dass der Aufwand nach der ersten Installation ziemlich gering ist. Nimm nen Ubuntu Server oder nen RH 8 (Clon) und damit ist das Meiste schon erschlagen. Wenn man es dann noch in ne VM packt und Container style wenig bis nichts anderes dazu laufen lässt kann man das auch in bestehende VM Lösungen integrieren um HA zubekommen.

Also zumindest für mich ist das Betreiben von den Stacks quasi kostenlos machbar. Die Konfiguration ist 99% der Arbeit und die nimmt die ja niemand ab. Also die Queries schreiben und die Daten rein pushen.

Aber gut eventuell bin ich auch nicht repräsentativ. Ich empfinde Lustre, MOFED/OPA und so Sachen als intensiv.