Performance-Frage: Sammeltabelle oder Aufteilung?

[Michi77]

Hallo zusammen!

Bin noch Anfänger auf dem Gebiet der Datenbankarchitektur, deshalb folgende Frage:

Gibt es eine generelle Aussage zu der Frage, ob es performanter ist, große Datenmengen in einer Tabelle und nach Attributen unterteilt zu speichern oder auf mehrere Tabellen aufzuteilen?

Beispiel hierzu: Wir haben im Betrieb verschiedene Arbeitsschritte, die letztlich alle "Cases" darstellen, also Aufgaben/Fälle, die jemand ausführt. Diese Cases lassen sich in verschiedene Kategorien unterteilen.

Klatscht man alles in eine Tabelle, würde die z. B. so aussehen:

05.09.2014, 16:35, Schrauben nachgezogen, Wartungsarbeiten
03.09.2014, 11:23, Lieferung abgeholt, Logistik
03.09.2014, 07:35, Schmierstoffe bestellt, Beschaffung

Wobei die letzte Spalte in dieser Tabelle die Kategorie darstellt.

Dem gegenüber hätte man natürlich die Möglichkeit, folgende Tabellen zu bilden:

cases_wartung
cases_logistik
cases_beschaffung

mit Befüllung der jeweiligen Tabellen je nach Kategorie. Wir haben nicht sehr viele Kategorien, deshalb würde dies nicht ausufern.

Folgende Punkte dürften noch eine Rolle spielen:

• Je nach Kategorie kommen Felder hinzu oder bleiben leer, weil bestimmte Case-Kategorie zusätzliche Angaben benötigen.
• Die Tabellen werden aus verschiedenen Oberflächen bedient. Das Zuleiten der Daten in die richtige Tabelle ist also kein Problem.

Fakt ist jedoch, dass die Daten aus allen Tabellen am Ende zu einer Abfrage zusammenlaufen (zwecks Abrechnung) und deshalb stelle ich mir die Frage, ob eine Aufteilung die Performanz erhöhen könnte oder ob es sinnvoller ist, eine einzige Tabelle mit möglichst wenigen Feldern und einem möglichst hohen Normalisierungsgrad (das oben waren wirklich nur nicht normalisierte Beispiele) zu schaffen.

Vielen Dank für jedes Feedback!

Michael

 

[akretschmer]

Hallo zusammen!

Bin noch Anfänger auf dem Gebiet der Datenbankarchitektur, deshalb folgende Frage:

Folgende Punkte dürften noch eine Rolle spielen:

• Je nach Kategorie kommen Felder hinzu oder bleiben leer, weil bestimmte Case-Kategorie zusätzliche Angaben benötigen.
• Die Tabellen werden aus verschiedenen Oberflächen bedient. Das Zuleiten der Daten in die richtige Tabelle ist also kein Problem.

Fakt ist jedoch, dass die Daten aus allen Tabellen am Ende zu einer Abfrage zusammenlaufen (zwecks Abrechnung) und deshalb stelle ich mir die Frage, ob eine Aufteilung die Performanz erhöhen könnte oder ob es sinnvoller ist, eine einzige Tabelle mit möglichst wenigen Feldern und einem möglichst hohen Normalisierungsgrad (das oben waren wirklich nur nicht normalisierte Beispiele) zu schaffen.

Vielen Dank für jedes Feedback!

Michael

Über was für Datenmengen reden wir? Selbst MySQL kommt mit tausenden und mehr Datensätzen zurecht.
Eine Aufteilung in einzelne Tabellen hätte einen entscheidenden Nachteil: bei einer neuen Kategorie fängst Du an, neue Tabellen aufzubauen und Deine Auswertungsabfragen daran anzupassen. Das skaliert also nicht.

Du solltest aber:

• besser normalisieren
• Datum und Zeit nicht trennen

Das Problem der unterschiedlichen Attribute bei versch. Cases könntest Du mit HSTORE lösen - wenn Du PostgreSQL hättest.

 

[ukulele]

Also hier vermischen sich erstmal zwei grundsätzliche Dinge, Normalisierung und Performance.

Eine Tabelle cases mit Spalten für Atribute die nur bei bestimmten cases existieren ist nicht gut normalisiert. Je nachdem wieviele Atribute das betrifft macht es Sinn oder keinen Sinn so zu verfahren.

Zur Performance und vor allem zur Handhabung würde ich aber klar sagen eine Tabelle für alle cases wenn bei der Auswertung auch alle Daten eine Rolle spielen.

 

[Michi77]

Es handelt sich (durch die feine Granulierung und dadurch hohen Input) momentan um einige Zehntausend Datensätze. Tendenz stark steigend.

Du solltest aber:

• besser normalisieren
• Datum und Zeit nicht trennen

Schon klar, sollte nur ein ganz banales Beispiel sein. Ich denke mal, dass bei größerer Datenmenge PostgreSQL durchaus eine Option wird. Wobei ja gerne das Beispiel bemüht wird, dass Amazon (oder wer es auch immer war) MySQL im Petabyte-Bereich laufen lässt.

Mich hatten vor allem die technischen/grundsätzlichen Aspekte interessiert wie:

• Wenn die Tabelle beim Lesen/Schreiben gesperrt wird, kann eine Verteilung auf mehrere die Trefferwahrscheinlichkeit reduzieren?
• Wenn bei Abfragen die gesamte Tabelle durchläuft, kann eine Stückelung und Verteilung Vorteile bringen?
  
• Welche Zeit "kostet" es MySQL, wenn es zwischen verschiedenen Tabellen springen muss, statt allles aus einer zu bekommen?

Sind sehr grundsätzliche Fragen und wahrscheinlich verweist Ihr mich jetzt zu Recht auf entsprechende Lehrbücher

Trotzdem wäre eine Einschätzung von Praktikern interessant.

Vielen Dank!

Michael

 

[ukulele]

• Wenn die Tabelle beim Lesen/Schreiben gesperrt wird, kann eine Verteilung auf mehrere die Trefferwahrscheinlichkeit reduzieren?
• Wenn bei Abfragen die gesamte Tabelle durchläuft, kann eine Stückelung und Verteilung Vorteile bringen?
  
• Welche Zeit "kostet" es MySQL, wenn es zwischen verschiedenen Tabellen springen muss, statt allles aus einer zu bekommen?

• Wenn die Tabelle gesperrt wird hast du ein Problem, egal wie viele andere Tabellen es gibt. Die Tabelle wird ja nicht gesperrt weil sie zu groß ist und welche Trefferwarscheinlichkeit sollte sich erhöhen wenn es andere Tabellen gibt?
• Partitionierung kann Vorteile bringen, Indexe sowieso. Sie verhindern, das jedesmal die ganze Tabelle durchlaufen wird. Ein Problem hast du eigentlich erst, wenn deine Tabelle nicht mehr auf die Festplatte eines DB-Servers passt. Aber wir reden hier ja nicht von NSA Rechenzentren.
• Auf jedenfall mehr wenn die eine Tabelle passende Indexe hat.

 

[akretschmer]

• Wenn die Tabelle gesperrt wird hast du ein Problem, egal wie viele andere Tabellen es gibt. Die Tabelle wird ja nicht gesperrt weil sie zu groß ist und welche Trefferwarscheinlichkeit sollte sich erhöhen wenn es andere Tabellen gibt?
• Partitionierung kann Vorteile bringen, Indexe sowieso. Sie verhindern, das jedesmal die ganze Tabelle durchlaufen wird. Ein Problem hast du eigentlich erst, wenn deine Tabelle nicht mehr auf die Festplatte eines DB-Servers passt. Aber wir reden hier ja nicht von NSA Rechenzentren.
• Auf jedenfall mehr wenn die eine Tabelle passende Indexe hat.

Ich möcht noch zufügen, daß Partitionierung auch einen Mehraufwand mitbringt und (zumindest in der PG-Community) sagt man, erst wenn die Kindtabellen je mind. mehr als 10 Millionen Rows haben. Vorher ist es Unfug.

Für einen Kunden, der je Tag 20-30 Millionen Datensätze hat, diese mind. 3 Jahre aufheben will und wo aber gefühlte 99% aller Zugriffe nur die letzten 2-3 Wochen betreffen macht Partitionierung per Tag wirklich Spaß: trotz mehrerer Milliarden Datensätze - da bei Suchfragen nach einem bestimmten Datensatz IMMER auch das Datum im Where ist dauern Abfragen oft unter 1 Millisekunde. Mal so als Beispiel.

 

[Michi77]

Vielen Dank für die Antworten!

Ich werde mal mit einer einzelnen Tabelle starten, diese so gut wie möglich normalisieren, indizieren und - falls das Teil zu groß wird - notfalls aufteilen.

Hat mir sehr geholfen, danke nochmal!

Viele Grüße!

Michael