Tabellen für viele kleine Datensätze optimieren

[Namenloser]

Zitat:

Zitat von Dejan Vu (Beitrag 1265105)

Kommt eine Spalte hinzu, muss ich das Programm ändern, an vielen Stellen, Ändere ich die Aggregierung, auch. Ich muss also laufend an der Software rumfummeln.

Dann ist dein Code nicht vernünftig gekapselt. Mir fallen eigentlich nur zwei Stellen ein, die man ändern muss: Speichern eines Datensatzes und Laden eines Datensatzes. Das ist bei der RDBMS-Variante nicht anders.

Aber ich will das jetzt nicht weiter diskutieren, wird langsam Off Topic.

[DSP]

Zitat:

Zitat von Dejan Vu (Beitrag 1265101)

[Das nennt sich Tracing und ist im ISO-Prozess zwingend.

Sorry, merkst du nicht, wie du dich her disqualifizierst? Ich sagte nicht, dass man die Daten löschen soll, sondern archivieren. Und für manche gibts da auch längere aufbewarungsfristen, zehn Jahre sind da eher die untere Grenze. Dann sag mir mal, wie willst du das mit eine wirtschaftlich vertretbaren aufwand realisieren? Dein aktueller Ansatz ist wirtschaftlich komplett inakzeptabel .. Daneben sollte die Zuverlässigkeit des System über die nächsten zehn Jahre gewährleistet sein mit geringen Wartungsaufwand und Folgekosten. Das sehe ich bei deinen Ansatz nicht. Eher die Tendenz, die Softwarequalität immer miserabler zu gestalten ...

[DSP]

Zitat:

Zitat von Dejan Vu (Beitrag 1265101)

ich will aus EXCEL heraus die 3 Stunden vom Januar 1980 in meiner Auswertung darstellen, wegen der Anomalie.

exakt, das ist Blödsinn, welcher troll will schon 50 Terra vorhalten um dann festzustellen, dass in Excel, in der neusten Version, nur zwei Gig passen?

Sorry, das kannst komplett vergessen.

[Medium]

Wow! Piano die Herren. Die Anforderungen sind recht klar, und ich bin mit dem aktuellen Stand bisher nicht unzufrieden. Um ein paar Punkte zu klären, die hier auftauchten:

Ein eigenes Dateiformat kommt nicht in die Tüte. Der Kunde wünscht explizit die Verwendung eines verbreiteten RDBMS, so dass im schlimmsten aller Fälle (für mich) auch ein anderes Softwarehaus leichtes Spiel mit der Weiterentwicklung und Wartung hat. Irgend welche obskure und ggf. proprietäre Dateiformate haben da einfach nichts verloren. Langzeitarchive, die weitere Schritte benötigen um sie auswerten zu können sind auch passé. Der Kunde will 2016 in seinem Viewer sagen können: Zeige mir die Ströme der Betriebsbereiche 1, 3 und 7 von 2014-2016, GO! Und dann will der innerhalb von einstelligen Sekunden seine Kurven sehen. Das entwickel ich NICHT selbst, das macht bitte sehr ein etabliertes DBMS. (Also zumindest das Anliefern der zum Zeichnen nötigen Daten.)
Und falls doch dann mal erweiterte Auswertungen gewünscht werden, werde ich endlos glücklich sein ein Backend zu haben, dass mir die Arbeit daran auf das Schreiben eines vergleichsweise kleinen Scriptes vereinfacht. Dass nachfolgende Wünsche dann ggf. nicht mehr in Millisekunden Ausführungszeit geschehen ist im Zweifel darstellbar, und stellt dann auch vermutlich nicht täglich genutzte Funktionalität dar.

Betrachtungen der Art "immer Donnerstags zwischen 7:00 und 12:00" wird es, laut nun mehrmonatig erstelltem Anforderungsprofil des Kunden (durch uns begleitet), nicht geben.

Ja, es ist ein großer industrieller Produktionsbetrieb. Festplattenkapazität ist nicht relevant. Der Kunde ging von sich aus schon von reichlich dimensionierten Backplanes mit zig HDDs aus, was IMHO sogar etwas hoch gegriffen ist. Ich erzeuge hochgerechnet jetzt etwa 15 MB Daten pro Tag, also pessimistisch gerechnet rund 6GB pro Jahr. Da reicht mir eine 1TB Platte für mindestens 15 Jahre, also nehme ich ein Mirror-Stripe (RAID 10) mit 4x 2TB SAS Platten und habe 30 Jahre lang Ruhe. Vorausgesetzt die technischen Standards entwickeln sich nicht zwischenzeitlich weiter, was sicherlich Umrüst-Begehrlichkeiten wecken müsste.

Abfragen werden immer die zuvor gezeigte Struktur haben: Gib Daten aus Zeitraum a bis b, der Messstellen 2, 6, 7 und 12. Der kombinierte Index aus "valueID, vdate" hat sich in meinen heutigen Tests als immense Verschnellerung erwiesen! Zusammen mit den kummulierten Tabellen, die das Zeichnen bei gröberem Zoom verschnellern sollen, dürfte ich auf akzeptable Reaktionszeiten kommen. Auch über ein handlesübliches Gigabit-Netzwerk.

Excel spielt keine Rolle. Ich schreibe ein vollumfängliches Auswertungsprogramm mit Graph und Reports, und das könnte von mir aus eine Exportfunktion bekommen. Gefordert ist dies bisher nicht, aber problemlos denkbar. Die Daten sind dann ja bereits gefiltert und aufbereitet.

"Materialized Views" erscheinen mir als ungeeignet. Beziehungsweise mache ich ja mit meinen Aggregat-Tabellen etwas sehr ähnliches, und das "Gewürgel" dies auf die verlinkte Art in reinem SQL auf MySQL abzubilden... da gefällt mir meines besser. Zumal es ziemlich einfach auch für Pflegeläufe nutzbar ist, sollte es dort wirklich mal Probleme geben.

Partitioning ist eventuell interessant. Da sich das aber durchaus auch nachträglich umsetzen lässt, würde ich gerne erstmal ohne testen. Wenn der Kunde dann doch irgendwann nicht mehr akzeptable Auswertezeiten berichtet, oder sich das noch besser in meinen noch kommenden "großen" Tests abzeichnet, wäre dies ein möglicher Ansatzpunkt.

Der wesentliche Grund für die Erstellung des gesamten Systems ist das Identifizieren der Ursachen für teilweise auftretende Verbrauchsspitzen. Verträge mit Energielieferanten definieren in diesen Größenordnungen Tarife nach aktuellem Verbrauch, heisst dass die ersten paar hundert kW normal berechnet werden, ab dann aber ein immens hoher "Straftarif" einsetzt. Die Quellen dafür sollen gefunden und bestenfalls eliminiert werden.
Der zweite Grund (nicht minder wichtig) ist die genauere Anrechenbarkeit von Energiekosten auf ein spezifisches Produkt. So, dass nachher gesagt werden kann: Für Produkt X entfallen Y kWh auf eine Produktionseinheit, verrechnet mit Tarif T sind also P% des Preises reine Energiekosten. Zusammen mit den Messungen für teils einzelne Motoren zeigen sich hier dann ggf. gute Einsparpotenziale.
Um gewissen Rankings zu entsprechen, und vereinbarte Einsparungen durch staatliche Stellen vorgegeben nachweisen zu können, sind Langzeitbetrachtungen notwendig. Auch rückwirkend über mehrere Jahre. (Manche Baugenehmigung kommt mit derartigen Anforderungen daher.)


Abschließende Bewertungen mit definitiven Werten müssen noch folgen. Hierfür muss ich zunächst ein zumindest rudimentäres Auswertetool bauen, und einen Generator für Echtwelt-ähnliche Daten, der mir flott Daten von ein paar Jahren simulieren kann. Die bisherigen Ideen und Infos bzgl. Indizes und Aggregat-Tabellen haben mich immerhin schon ein mal so weit gebracht, dass ich mir gut vorstellen kann den gewünschten Funktionsumfang mit erschwinglicher Hardware und akzeptablen Laufzeiten anbieten zu können. Sehr geil!

[hstreicher]

mal ne blöde Frage, wieso muessen die Daten denn in festen Zeitabständen gespeichert werden?

man könnte doch auch einfach einen Datensatz speichern wenn der Messwert einen gegeben Wert vom letzten gespeicherten Wert abweicht,
dann kann man einerseits die Daten im Sekundentakt reinholen , ohne die DB mit Abermillionen von gleichen Werten sich widerholenden aufzublasen
man haette dann die granularitaet Abnormalitaeten sekundengenau zu untersuchen

Nachteil: würde aber die Auswertungen etwas Komplizierter machen


mfg Hannes

[mkinzler]

Und auh das eigentliche Logprogramm. So wird einfach zeitgesteuert Werte protokolliert, bei Deinem Vorschlag müsste immer zuerst mit dem letzten Wert verglichen werden)

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1265105)

Zitat:

Zitat von jobo (Beitrag 1265102)

Ich würde es mit getrennten Indizes machen. Das ist flexibler.

Erklär mal bitte. Ist der kombinierte Index über den Zeitraum und Messstationen nicht besser, als nur über den Zeitraum? Den Index über die ValueID wird man imho nie benutzen, oder irre ich mich?

Ein kombinierter Index ist naheliegend, lässt sich durch das RDBMS bzw. den Optimizer aber oftmals nicht so vielseitig nutzen.
Das Thema ist sehr DB spezifisch, vermutlich sogar (Optimizer)Version-spezifisch.

Einzeln aufgebaute Indizes werden durch die Optimizer idR besser nach Bedarf zusammengesetzt bzw. abgegriffen, also wirklich verwendet, als Kombi-Indizes. Deren Aufbau und Nutzen ist halt viel spezifischer.
Die Verwendung / Filterung nach Meßstation halte ich für sehr naheliegend. Auch wenn der Kunde was anderes behauptet.

Letztlich ist das Indexthema aber sekundär, weil man es unabhängig von der Logik mit ein paar Handgriffen variieren und testen kann, notfalls sogar auf einem Produktivsystem.

Zitat:

Zitat von hstreicher (Beitrag 1265127)

mal ne blöde Frage, wieso muessen die Daten denn in festen Zeitabständen gespeichert werden?

man könnte doch auch einfach einen Datensatz speichern wenn der Messwert einen gegeben Wert vom letzten gespeicherten Wert abweicht,
dann kann man einerseits die Daten im Sekundentakt reinholen , ohne die DB mit Abermillionen von gleichen Werten sich widerholenden aufzublasen
man haette dann die granularitaet Abnormalitaeten sekundengenau zu untersuchen

Nachteil: würde aber die Auswertungen etwas Komplizierter machen


mfg Hannes

Das ist eine prima Sache.
Wenn Anzahl der Messwerte und Toleranz gespeichert werden, kann man die Daten wenn es sein muss (>Auswertung/Export/Archiv) auch rekonstruieren (mit Toleranzverlust natürlich). Vermutlich sogar transparent on the fly per View bspw.

[DSP]

Dann solltest du mal gut testen, ein Stresstest welcher mal 5 oder 7 Jahre simmuliert, sehe ich hier als absolute Notwendigkeit und dies nicht nur bei den Auswertungen sondern auch beim Insert. Wenn du hier, die Berechnung des max-/durschnittswertes innerhalb des kleinsten Intervalls in der DB realsieren möchtest, sehe ich hier schon mal ein Problem. Da würd ich zumindest die ersten 10 Sekunden im Speicher halten, berechnen und dann einen Insert auslösen ohne da noch verschiedene Ergebnistabellen generieren zu müssen. Nichts desto troz, würde ich eine Archivierungsfunktion vorsehen und eine temporäre Einlesefunktion für die archivierten Daten.

Anmerkung, du darfst auch nicht nur die Daten rechnen, sondern musst bei der Grössenberechnung auch den Index mit einbeziehen. Auch taugt meist ein Index der aus einen Double besteht nichts. Wünsche schon mal viel Glück.

Noch ein Hinweis, die Orginaldaten sollten natürlich auch gespeichert werden, damit man im Notfall das ganze rekonstruieren und belegen kann. Ein sequenzielles File, ist auch schnell und einfach zu lesen und zu schreiben.

Grüsse
DSP

[Dejan Vu]

Bezüglich der benötigten HD würde ich den Nettoverbrauch, also die reinen Nutzdaten mit dem Faktor 3-4 multiplizieren, da Du hochredundante Indexe(60-80% der Daten sind dort nochmals vorhanden) und Aggregationstabellen verwendest etc.

Zitat:

Zitat von Medium (Beitrag 1265120)

Betrachtungen der Art "immer Donnerstags zwischen 7:00 und 12:00" wird es, laut nun mehrmonatig erstelltem Anforderungsprofil des Kunden (durch uns begleitet), nicht geben.

Das war nur ein Beispiel, um die Flexibilität eines RDBMS ggü. einem handgebissenen Dateiformates zu belegen. Ich denke, das wird kommen, denn beim Datamining und dem Suchen nach Ursachen spielen auch Tageszeiten, Wochentage eine Rolle (können! könnten!). Aber da die Spec das nicht vorsieht, ist es ok. Ich würde es in der Hinterhand halten und eventuell den Timestamp doppelt abbilden: vDateTime, vDate, vTime. Das nachzurüsten geht natürlich auch, würde aber ein einmalig stundenlanges rumrödeln bedeuten. Aber gut: Das würde bezahlt werden.

Zitat:

Excel spielt keine Rolle.

Wichtig ist: Da du hier mit einem Standard-RDBMS arbeitest, sorge nur für einen Ole-DB provider (ODBC mit ADO geht auch).

Zitat:

"Materialized Views" erscheinen mir als ungeeignet. Beziehungsweise mache ich ja mit meinen Aggregat-Tabellen etwas sehr ähnliches, und das "Gewürgel" dies auf die verlinkte Art in reinem SQL auf MySQL abzubilden... da gefällt mir meines besser. Zumal es ziemlich einfach auch für Pflegeläufe nutzbar ist, sollte es dort wirklich mal Probleme geben.

Ich kenne die Tools für mySQL nicht, aber ich finde einen zeitgesteuerten SQL-Job wesentlich besser, weil das alles in einer Umgebung läuft, die alles schon eingebaut hat: Wiederholung bei Fail, E-Mail-Benachichtigung im Fehlerfall etc. Logging ist auch vorbildlich: Wozu also das Rad neu erfinden... Schau mal, ob Du dich mit professionellen ETL/cron-Tools für mySQL anfreunden kannst.

Bezüglich deiner Auswertetools, die Du alle selbst schreiben willst, würde ich auch mal prüfen, ob es etwas derartiges nicht gibt. Natürlich macht Programmieren Spaß, aber wenn es etwas Fertiges gibt... Wieso nicht? Oder zumindest Denkansätze besorgen.

Zum Abschluss noch meine persönliche Meinung:
Ich würde mir noch überlegen, ob ein SQL-Server nicht eher in Frage kommt, zumal Du dort alles hast, was Du brauchst: SSIS um die Jobs zu definieren, SSAS, um OLAP-Cubes zu entwerfen und zeitgesteuert zu füllen (Eine noch bessere Alternative als die handgebissenen Aggregattabellen), SSRS um Reports zu generieren etc.

Je weniger ich selbst programmieren muss, desto besser: Denn ich werde mir die gleichen blutigen Nase an genau der gleichen fiesen Ecke holen, wie tausende Programmierer vor mir: Nur warum soll ich mir das antun?

Zitat:

Zitat von jobo (Beitrag 1265130)

Einzeln aufgebaute Indizes werden durch die Optimizer idR besser nach Bedarf zusammengesetzt

Du kannst Indexe doch nicht zusammensetzen? Ein Index auf 'B' bringt dir doch gar nichts, wenn Du nach 'A' und 'B' suchst, und schon einen Index 'A' verwendest. Wie soll das denn gehen? Was richtig ist: Mit einzelnen Indexen kannst Du unterschiedlichen Queries idR besser begegnen, aber wenn es hier eh nur ein Query-Pattern gibt, nimmt man besser auch nur einen Index.

Zitat:

Letztlich ist das Indexthema aber sekundär, weil man es unabhängig von der Logik mit ein paar Handgriffen variieren und testen kann, notfalls sogar auf einem Produktivsystem.

Da wird der Kunde aber ziemlich kotzen, wenn Du in seinem Produktivsystem mit Indexen experimentierst: Schließlich ist das System doch ziemlich ausgelastet (und die Tabelle gelockt), wenn Du mal den Kombi-Index über die TB an Daten neu erstellen willst. Da würden dann alle Messstationen meckern, weil der Server nicht erreichbar ist => keine gute Idee.

Lieber vorher Testdaten erzeugen (10 Jahre: 150.000 x 365 x 10= 547.500.000), damit rumspielen und ein Gefühl für die Queries bekommen.

Aber sekundär ist das Thema wirklich.

Zitat:

Zitat von DSP (Beitrag 1265132)

..Wenn du hier, die Berechnung des max-/durschnittswertes innerhalb des kleinsten Intervalls in der DB realsieren möchtest, sehe ich hier schon mal ein Problem

Welches?

Zitat:

Auch taugt meist ein Index der aus einen Double besteht nichts.

Natürlich taugt der was: Beim Aggregieren nimmt das RDBMS nämlich diesen Wert und muss den Datensatz nicht laden. *Suchen* nach Messwerten wird man nie

Zitat:

Wünsche schon mal viel Glück.

Glück wird hier nicht benötigt. Das ist eine Standardanforderung an eine Messdatenerfassung. Das ist, wie man so schön sagt: 'No big deal'.

[mkinzler]

Die Auswertung muss ja nicht zwangsläufig auf dem System erfolgen, welche die Logdaten erzeugt. GGf kann man ja die Datenbank auf eine anderes System kopieren und dort dann wen nötig auch nachträglich Indizes erzeugen.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1265134)

Zitat:

Zitat von jobo (Beitrag 1265130)

Einzeln aufgebaute Indizes werden durch die Optimizer idR besser nach Bedarf zusammengesetzt

Du kannst Indexe doch nicht zusammensetzen? Ein Index auf 'B' bringt dir doch gar nichts, wenn Du nach 'A' und 'B' suchst, und schon einen Index 'A' verwendest. Wie soll das denn gehen? Was richtig ist: Mit einzelnen Indexen kannst Du unterschiedlichen Queries idR besser begegnen, aber wenn es hier eh nur ein Query-Pattern gibt, nimmt man besser auch nur einen Index.

Zitat:

Letztlich ist das Indexthema aber sekundär, weil man es unabhängig von der Logik mit ein paar Handgriffen variieren und testen kann, notfalls sogar auf einem Produktivsystem.

Da wird der Kunde aber ziemlich kotzen
-....
Aber sekundär ist das Thema wirklich.

Ich setze keine Indizes zusammen, ich überlasse es dem Optimizer, die beste Kombination zu verwenden. Der ist sehr wohl in der Lage, mit dem was er vorfindet, sinnvolle Rangescans usw. durchzuführen.
Und meinetwegen, wenn es wirklich nur ein "Querypattern" gibt- was laut Plan so sein mag, in der Praxis aber vlt ganz anders aussieht- kann es auch ein Kombiindex sein.
Da es ursprünglich auch um Platzbedarf ging, war es eine Möglichkeit zu sparen. Man kann es bequem und schnell ausprobieren.

Natürlich wird der Kunde kotzen, wenn man das im laufenden Betrieb macht, ich schrieb aber notfalls, und darüber hinaus traue ich es dem TE zu solcherlei Überlegungen und weit mehr alleine anzustellen ohne diese Annahme auch noch explizit hinzuschreiben.


Und ja, es ist sekundär.

[DSP]

Noch ein Hinweis, das System sollte redundant ausgelegt sein, dass bei einen Hardware defekt die Daten nicht verloren sind. Also eine Duplikateprüfung mit integrieren, damit man da auch mal Wartungsarbeiten vornehmen kann. Auch sollte ein DB unabhängiges Log geschrieben werden, mit dem man auch mal die Datenbank Nachfahren kann, sollte sie au h mL gewartet werden ;)

Grüsse
DSP

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1265143)

..es dem Optimizer, die beste Kombination zu verwenden. Der ist sehr wohl in der Lage, mit dem was er vorfindet, sinnvolle Rangescans usw. durchzuführen.

Erklär mir mal bitte, wie das gehen soll.
Ein Index sortiert nach Vorname, der andere nach dem Nachnamen. Wie soll man die Indexe kombinieren, wenn nach 'Max' und 'Müller' gesucht wird? Der Optimizer wird den Index mit dem niedrigeren distinct/total count nehmen, denn dort ist die Wahrscheinlichkeit eines eindeutigen Treffers am höchsten (oder einen Clustered Index, oder den, mit der besseren Strategie). Und dann scannt er alle Treffer durch, lädt den jeweiligen Datensatz und prüft, ob der Nachname = 'Müller' ist. Kann er den zweiten Index da denn verwenden?. Nee, oder? Genau hier fehlt mir ein Beispiel, das das belegt. Zu sagen 'Der macht das schon irgendwie' reicht mir nicht. ;-)

Und weil das imho so ist, verfällt man ja so leicht in das Anti-Pattern "Index-Shotgun", also eine Tabelle mit Indexen zu überladen, um bloß alle Queries optimal durchführen zu können.

Ich wiederhole nochmal (da sind wir einig): Ein Index auf einer einzelnen Spalte ist im täglichen Betrieb einem kombinierten Index in jedem Fall vorzuziehen (wegen der vielfältigen Einsatzmöglichkeiten, 'Flexibilität'). Nur in Ausnahmefällen sollte ein kombinierte Index zusätzlich verwendet werden, eventuell als Ersatz für einen einfachen. In der Regel (also eigentlich fast immer) sind die Abfragen schnell genug, weil die meisten Daten eh im Cache sind.

Hier ist es wirklich so, das es nur ein Pattern gibt:
Suche für bestimmte Stationen Daten innerhalb eines bestimmten Zeitraumes.
Suche alle Messwerte im Zeitraum ist sinnlos.
Suche alle Messwerte einer Station ebenso.

Ergo bleibt hier nur der Index ValueID+vDate.

Zitat:

...in der Praxis aber vlt ganz anders aussieht-

Absolut, da kommt noch was, sehe ich auch so.

Zitat:

Zitat von DSP (Beitrag 1265145)

Noch ein Hinweis...

RAID + Cluster, dann wirds aber langsam teuer. Wartungsarbeiten per Agent/SSIS. Ich glaub, SSIS macht das, der Agent sowieso. DB-Unabhängige Logs? Nö. Brauchts nicht, das macht das RDBMS alles von ganz alleine. Deshalb heißt es Daten*bank* (nicht zum draufsetzen, sondern weil es sicher ist).

[Medium]

Es wird wie gesagt ein RAID 10 zum Einsatz kommen, und sehr wahrscheinlich sogar zwei Mal, sprich zwei identische PCs. Ob dort die Redundanz von MySQL eingesetzt wird oder ein nächtlicher DB-Abgleich ist noch nicht entschieden. Ein Log wird es geben, aber nur ein Fehler-Log. Würde ich normale Aktionen alle loggen, kann ich gleich das Datacenter auf dem Gelände nebenan in Auftrag geben :D

Dass mein neuerdings kombinierter Index für meine Fälle scheinbar sehr gut geeignet ist, sehe ich allein schon wenn ich Abfragen auf eine Hand voll Daten mache. Die sind von ~1sek auf bis weit unter 200ms Antwortzeit runter. Groß-Test wie gesagt in Mache. Stellt sich dabei raus, dass es noch immer zu langsam ist, wird da was anderes probiert. Und nur dann!

Die eigentlichen Rohdaten werden zwar sekündlich gelesen (bzw. alle 200ms bis 10s je nach Messstelle), ich bilde aber bereits "im Speicher" daraus die minütlichen Maxima und Durchschnitte. Eine Speicherung nach Hysterese wäre prinzipiell denkbar und wurde überlegt, zugunsten der Lesbarkeit von Ausdrucken in Listen-Form aber verworfen. Ganze Minuten lesen sich einfach "sauberer" und übersichtlicher, und "lügen" durch Runden der Schönheit wegen ist auch nicht im Sinne des ganzen gewesen :)

Bei meinen geschätzten 15MB/Tag waren die Indizes und Aggregattabellen inkl. derer Indizes enthalten.

Wo habe ich einen Index vom Typ Double? :gruebel:

Das RDBMS wird vom Kunden gestellt. Unsere Alternative wäre Oracle, und die IT Abteilung hat nicht ganz undeutlich signalisiert, dass sie keinen wirklich hätten, der diese administrieren wöllte. Ich auch nicht. Ein DB Wechsel ist ja aber auch kein Hexenwerk, sollte sich später herausstellen, dass es überhaupt nicht geht mit MySQL.

[Dejan Vu]

Zitat:

Zitat von Medium (Beitrag 1265151)

Wo habe ich einen Index vom Typ Double? :gruebel:

Den hatte ich ins Spiel gebracht, wenn man die Aggregierung einzelner Messwerte optimieren will;

Code:

select sum (value) from Messwerte where vDate Between :From And :To and ValueID in (1,3,6)

geht bei vielen RDMBS noch schneller, wenn der Index über vDate+ValueID+value geht. Denn dann muss ja 'value' nicht mehr aus dem Datensatz gezogen werden.

Bezüglich 'geht nicht mit mySQL' kann ich dich beruhigen: Das geht schon. Die Nachteile und Lizenzmodelle sind bekannt und wenn es die zusätzlichen Tools gibt (Agenten, ETL etc.) Super. Wenn nicht, haste doch noch was zu Programmieren.

Das ist wirklich ein sehr interessantes Projekt, wo man sich schöne Lorbeeren verdienen kann, speziell in den Auswertungen, wenn die in Quasi Echtzeit erstellt werden ("Wie schaffen Sie das bloß, aus den Millionen Daten die Monatsmittelwerte zu berechnen, auf Knopfdruck?" :shock:)

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1265146)

Zitat:

Zitat von jobo (Beitrag 1265143)

..es dem Optimizer, die beste Kombination zu verwenden. Der ist sehr wohl in der Lage, mit dem was er vorfindet, sinnvolle Rangescans usw. durchzuführen.

Erklär mir mal bitte, wie das gehen soll.

Ich kann Dir das ehrlich gesagt nicht erklären und ich hab da auch keine Ambitionen, mich in die Optimierungsalgorithmen beliebiger Optimizer reinzudenken. In der Realität gibt es mit verschiedenen RDBMS und deren Versionen eine beträchtliche Anzahl von Varianten / Verfahren, wie ein Optimizer sich verhält. (Genaugenommen auch nochmals abhängig von Datenlage aka Statistiken, die wiederum falsch oder schlecht sein können)
Es ist eine allgemeine Aussage meinerseits (Anbieter-unspezifisch). Fakt ist, es kostet den TE 3 Minuten, beide Varianten am echten System auszuprobieren. Ich selbst habe nicht das Problem, sondern nur eine Anmerkung dazu gemacht, Du musst also ohne eine Erklärung leben, kannst mir aber gerne beweisen, dass es falsch ist.
negativer Erfahrungswert mit kombinierten Indizes:
Schon bei vertauschter Reihenfolge der Felder in der Where Bedingung gegenüber der Indexdefinition wird der Index gar nicht genutzt oder nur teilweise bis zum vertauschten Feld.
positiver Erfahrungswert bei nicht kombinierten Indizes:
Es wird ein "Range Index Scan" durchgeführt, das Ergebnis liegt geschwindigkeitsmäßig zwischen "Nur ein Index" und "Kombi Index"

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1265306)

Ich kann Dir das ehrlich gesagt nicht erklären und ich hab da auch keine Ambitionen, mich in die Optimierungsalgorithmen beliebiger Optimizer reinzudenken.

Hmmm. Ich dachte, Du wüsstest das.

Zitat:

Schon bei vertauschter Reihenfolge der Felder in der Where Bedingung gegenüber der Indexdefinition wird der Index gar nicht genutzt oder nur teilweise bis zum vertauschten Feld.

Dann ist das kein Optimizer am Werk, denn der würde das ja optimieren, aber das ist mir bei einigen RDBMS auch schon aufgefallen. (Für Oracle gab es / gibt es wohl entsprechende Query-Optimizer, die diese Reihenfolge dann optimieren). Na ja 'Optimizer' sind das schon, aber eigentlich sind es Strategieauswähler, weil bei jedem Schritt der Query (eigentlich nur ein Baum aus Filtern, und Enumeratoren) die vermeindlich kostengünstigste Variante aus eine Pool an Möglichkeiten (Index-Seek, Index-Scan, Table-Scan, Sort, Bucket, Hash etc.) herausgepickt wird.

Übrigens wird ein Index-Scan benutzt, wenn einzelne Felder benötigt werden, die in Index-Informationen enthalten sind und wenn dafür dann kein Datensatz gelesen werden muss. Oder der Scan über den Index, um etwas zu finden, ist schneller als ein Table-Scan. Insofern sind einzelne Index eventuell geeignet, Scan-Vorgange zu beschleunigen, aber 'eigentlich'(*) auch nur dann, wenn sie kombiniert sind, oder weitere Felder huckepack mit ablegen ('INCLUDE' Klausel bei T-SQL in Verbindung mit 'CREATE INDEX')
(*)'Eigentlich'=Ich weiss es nicht genau.

Aber was war das alles doch gleich? Ach ja, sekundär und wie Du schon sagtest per Experiment in ein paar Minuten belegt/widerlegt/erkannt.

Vom Diskussionsstoff her jedoch ein schönes Thema für einen anderen Thread.

[BUG]

Die Annahme, dass die Optimierer nach festen Regeln optimieren, ist meines Wissens falsch. Vielmehr ist es tatsächlich eine Minimierung des geschätzten Aufwandes über die Ausführungspläne der Anfrage.

Dabei hängt schon das Schätzen des Aufwandes von den Daten ab (Menge, Histogrammen, usw.).
Außerdem ist die Menge der Pläne auch zu groß, um komplett durchsucht zu werden. Natürlich können Heuristiken verwendet werden, um Pläne zu verbessern. Es ist aber auch nicht unwahrscheinlich, das bei der Auswahl des betrachteten Suchraums eine (pseudo-)zufällige Komponente mit reinspielt.

Insofern halte ich es für sinnlos, sich als Anwender zu genau mit dem Optimierer zu beschäftigen. Was aber nicht heißen soll, das man ihn nicht mithilfe von Erfahrung einen Tritt in die richtige Richtung geben kann.

[jobo]

Zitat:

Zitat von BUG (Beitrag 1265312)

Die Annahme, dass die Optimierer nach festen Regeln optimieren, ist meines Wissens falsch.

Nein, es gibt auch Optimierer, die nach festen Regeln arbeiten.
Aber was Du schlussfolgerst, läuft auf das hinaus, was ich auch rüberbringen wollte. Es macht wenig Sinn, einen nicht regelbasierten Optimizer "verstehen" zu wollen. Unabhängig von der Qualität der Statistiken, die von manchen Systemen herangezogen werden, sagt man gewissen Systemen nach, dass bspw. sogar physikalische Gegebenheiten berücksichtigt werden. (Welches Device hält welche Datenmenge, ..)
Wie auch immer, im Zweifel kann ich ihn mit Hints lenken. Im Beispiel hier bei den Indizes halt ausprobieren.

Letztlich ist es dennoch so, dass ich im Produktivbetrieb mit schleichenden Änderungen oder plötzlich kippendem Laufzeitverhalten rechnen sollte. Da muss also entweder ein kompetenter DBA ran und nachjustieren oder eben ein Supportvertrag her.

[BUG]

Zitat:

Zitat von jobo (Beitrag 1265315)

Nein, es gibt auch Optimierer, die nach festen Regeln arbeiten.

Okay, vielleicht habe ich an der Stelle etwas übertrieben :wink:

Zitat:

Zitat von jobo (Beitrag 1265315)

Da muss also entweder ein kompetenter DBA ran ...

Wobei es insgesamt keine schlechte Idee wäre, sich im Vorfeld mit einem Spezialisten für das entsprechende Datenbank-System abzusprechen, der das dann auch betreut. Die sind ja nicht ohne Grund so gut bezahlt.

[jobo]

Natürlich ist das keine schlechte Idee! Ich muss meine Aussage "Optimizer kann man eh nicht nachvollziehen" etwas gerade rücken.
Im Zuge von Hibernate, JPA und Persistenzframeworks ist es trendy, die DB als Blackbox zu betrachten. Das Verständnis der Abläufe innerhalb der Blackbox ist damit per Definition ausgeblendet. Sehr bequem, Schuld ist im Zweifel der DB Admin.
Das mag in vielen Fällen (z.B. kleine Projekte, wenig User / Daten) gut gehen, kann aber auch voll in die Hose gehen.

Daher sollte man sich schon um ein gewisses Verständnis von (grundlegenden) DB Verfahren bemühen.
Ein Tuning der DB funktioniert im Produktivbetrieb übrigens am besten bei der Verwendung von Views, hier kann man nachträglich Verbesserungen anbringen bzw. sogar testen, ohne der Anwendung ein Haar zu krümmen, z.B. über Optimizer Hints..

[Dejan Vu]

Zitat:

Zitat von BUG (Beitrag 1265312)

Die Annahme, dass die Optimierer nach festen Regeln optimieren, ist meines Wissens falsch.

Da jedes Programm nach 'festen Regeln' (nämlich dem Code) arbeitet, ist das 100% korrekt (die festen Regeln). Nur frage ich mich, wer das behauptet. Ich habe nur grob skizziert, wie ein Optimierer bzw. der Strategieauswähler arbeitet. Da muss ich auch nicht lange überlegen, in welcher Reihenfolge ich die Dinge abarbeiten und großartige Kombinationen, die alle durchzutesten sind, sehe ich auch nicht. Deshalb liegen die ja auch manchmal daneben, eben weil sie ziemlich starr sind. Es ist wirklich kein Hexenwerk, was da abgeht: Das Statement (meistens ja ein SELECT) wird in einen Baum überführt (das macht der Parser), dann wird 'gekürzt', d.h. gleiche Fragmente zusammengefasst und dann rechnet man für die einzelnen Knoten die beste Strategie nach Brute Force aus. Hierbei wird eine Performancefunktion angewandt, die mit den Statistiken gefüttert wird. Da mittlerweile der I/O-Durchsatz eine entscheidende Rolle spielen kann (SSD, HD, RAM) wird sich das, wenn man die Statistiken erweitert, auch entsprechend auswirken. Wichtig ist: Man muss diese Statistiken pflegen, also im Rahmen eines Wartungsplans immer mal wieder neu erstellen lassen.

Aber da ich nicht alle Optimierer kenne, sondern eigentlich nur 2 (SQL-Server und einen für ein RDBMS selbst entwickelten) kenne ich die Magie hinter anderen Optimizern natürlich nicht. Nur eines kann ich mir nicht vorstellen: Das man irgendwelche Kombinationen durchprobiert, denn da gibt es eigentlich keine. Aber wenn ihr mit 'nicht regelbasiert' Fuzzy-Logik meint, dann ist das natürlich korrekt, denn es ist eine analoge Funktion, die 'ausrechnet', wie teuer ein bestimmtes Verfahren ist und anhand dessen wird bestimmt, was jetzt das beste ist. Also nicht: 'Index-Seek < Index-Scan < Table-Scan'.

Zitat:

Zitat von jobo (Beitrag 1265330)

Daher sollte man sich schon um ein gewisses Verständnis von (grundlegenden) DB Verfahren bemühen.

Genau. Und wie Du schon sagtest: Probieren, Probieren, Probieren. Denn nur aus der Stoppuhr (bzw. die IO-Statistik) spricht die Wahrheit. Amen.

[DSP]

@to: Mal ne dumme Frage, wie ist denn jetzt das Tabellendesign und der Stresstest ausgegangen?