# Ideen für Datenhaltung



## aemik (29. Aug 2011)

Hallo,

habe folgendes Problem und wollte Fragen wie ihr es lösen würdet bzw. was ihr für Ideen und Erfahrung ihr schon damit schon gesammelt habt.

In einer relationalen Datenbank haben wir eine Tabelle die aktuell an die 5 Millarden Datensätze hält. Weil nach 1,7 Millarden Schluss ist, wird eine View über mehrere dieser Tabellen gelegt. 
Eine Suche über diese Tabelle dauert ewig und ist ein echtes Performanceproblem. Alle Tuningmaßnahmen (Index, Partitionierung, Archivierung, usw.) sind gescheitert.

Die Daten werden nur in diese Tabelle geschrieben und später gelesen. Sie werden nicht gelöscht bzw. geändert.


Was wäre eure Idee für eine passende Datenhaltung bzw. Datenzugriffsschicht?
Ein realtionales Verhältnis zu den Daten ist zu vernachlässigen.

Noch Fragen? Irgendwelche Ideen?


----------



## homer65 (29. Aug 2011)

Schwer zu sagen. Das dürfte wohl den Rahmen einer Forumsdiskussion sprengen. 
Grundsätzlich läßt sich nur sagen, das, wenn ein Großteil der Datensätze verarbeitet werden muß, eine deutliche Performancesteigerung mit Parallelverarbeitung erreicht werden kann.
Aber wie schon erwähnt wird die Diskussion wohl den Rahmen hier sprengen.


----------



## nillehammer (29. Aug 2011)

Ich würd mir auch die Queries anschauen, die Ihr zum Zugriff auf die Daten benutzt. Full-Table Scans vermeiden und alle Clauses, die die Ergebnismenge wirksam einschränken, möglichst nach vorne. Es gibt für die Analyse von Queries in jedem DMBS einen SQL-Befehl, um sich anzeigen zu lassen, wie das DBMS die Queries abarbeiten wird (such mal nach EXPLAIN).

Wenn ihr tatsächlich über die gesamte Datenmenge iterieren müsst und die Ergebnismenge nicht einschränken könnt, dann siehe homer65's Post.


----------



## JohannisderKaeufer (29. Aug 2011)

Wie ist das Verhältnis zwischen lesenden und schreibenden Zugriffen?

Wie sehen typische Abfragen aus?


Wenn "Ein realtionales Verhältnis zu den Daten ist zu vernachlässigen." gilt, muß es dann bei einem *Relationalen* DBMS bleiben?

Wie sieht es mit dem ACID-Paradigma aus?


Ich könnte mir gut vorstellen, daß ein Cluster aus Dokumentenorientierten Datenbanken, mit Map/Reduce mehr rausholen kann, wenn relationen keine zu große Rolle spielen.


----------



## aemik (30. Aug 2011)

Schonmal Danke für die Antworten...

- lesende Zugriffe haben klare Priorität in Bezug auf Performance
- schreibende Zugriffe gibt es verhältnismäßig viele, haben aber keine Prio

Die Datenstruktur sieht grob folgendermaßen aus (in xml-darstellung):

<produkt>
 <id>123</id>
 <vorgang>
  <id>345</id>
  <datum>1.1.09</datum>
  <merkmal>
   <id>
   <wert>test</wert>
  <merkmal>
 </vorgang>
</produkt>

Abfragen gehen meist über das Datum eines Vorgangs.

- für den Teil mit der extrem großen Datenmenge muss es kein relationales dbms bleiben.
- ACID kann vernachlässigt werden.


Es handelt sich quasi um einen riesigen Datenspeicher in den ständig Daten reingepumpt werden und gelegentlich Abfragen erfolgen.
Ich sehe immer eine Parallelität zu Twitter. Wie handelt man dort die unmengen von Daten?


----------



## fastjack (30. Aug 2011)

Welches DB-System nutzt Du denn?

Abfragen über das Datum sind schon mal ein Problem, wenn es in dieser Form ist (TT.MM.YYYY). Wenn Du Dein Datum als BigInt, Numeric, Decimal usw. speicherst, in der Form YYYYMMDD hast Du schonmal ein großen Performancegewinn.

Ich habe sehr gute Erfahrungen mit MySQL/PostgresQL riesigen Datenmengen gemacht (zentralisierte Umlaufdaten aus verschiedenen Krankenhausketten).


----------



## aemik (2. Sep 2011)

Eine IBM DB2 Version 9.5

Datumsfelder sind vom Typ "Timestamp" und im Format "TT.MM.YYYY HH:MM:SS" abgelegt.
Über diese Felder wird oft gesucht, aber es liegt auch ein Index darauf.

Wieviel Performacegewinn würde eine Umstellung auf einen numerischen Wert bringen? Trotz Index...
Das klingt auf jeden Fall sehr plausibel und wäre, wenn die Performance spürbar besser wird, eine Möglichkeit.

Danke schonmal!


----------



## Gelöschtes Mitglied 5909 (2. Sep 2011)

MongoDB


----------



## homer65 (4. Sep 2011)

Wie sieht den eine typische Abfrage genau aus?
Kannst du die DDL der Tabelle und der Indizes posten?


----------



## nocturne (10. Sep 2011)

wenn tunen nix bringt ist es kein hardwareproblem, ich würde vorschlagen die where-klausel zu ändern, am besten man untersucht die rechenlast der queries.


----------

