MySQL Ablage von vielen Datensätzen

[Hobbes]

Hallo zusammen,

ich bin gerade dabei, ein Datenbankdesign für eine sehr dynamische und stetig wachsende Datenmenge zu erstellen. Es geht konkret um die Ablage von jährlich (im Extremfall) 1.800.000 neuen gleichartigen Datensätzen. Als Datenbank wird MySQL (InnoDB) genutzt.

Am liebsten würde ich alle diese Daten in einer Tabelle speichern. Die Definition geeigneter Indizes ist dabei ohne Probleme möglich. Für mich stellt sich aber die Frage, ob der Zugriff auf Dauer performant möglich ist? Oder sollte man die Datensätze lieber gleichmäßig (aber systematisch) auf 10 oder 100 kleinere Tabellen verteilen?

Gibt es in dieser Größenordnung Erfahrungswerte?

Gruß
Hobbes

 

[homer65]

Ja, wir haben Erfahrungen mit derart großen Datenmengen.
Allerdings nehmen wir dafür kein MySQL Datenbanksystem.
Und ich frage mich, ob das dafür geeignet ist.
Wir benutzen DB2 z/OS. Dort gibt es die Möglichkeit große Tabellen in einen Tablespace mit mehreren Partitionen zu legen.
Die einzelnen Partitionen können dann parallel bearbeitet werden.

 

[Hobbes]

Danke für die Antwort. Ein Wechsel des Datenbanksystems kommt erst mal nicht in Frage. Die Entscheidung für MySQL steht.

Auch gibt es in der Anwendung bereits eine gekappselte Logik, die die Daten in einer vorher festgelegten Anzahl Tabellen verwalten könnte. Trotzdem würde ich es nach Möglichkeit gerne in einer Tabelle ablegen.

 

[Gast2]

Partitionieren: MySQL :: MySQL 5.1 Reference Manual :: 18.1 Overview of Partitioning in MySQL

 

[fastjack]

MySQL kannst Du dafür locker nehmen. Ich habe Tabellen mit mehreren Hundertmillionen Datensätzen auf MySQL gehabt (Infosystem mit Daten mehrerer medizinischer Einrichtungen europaweit). Die Hardware dazu ist das A&O. Mit entsprechenden Optimierungen kannst Du auf solche Tabellen auch noch Berichte fahren. Bei MySQL ist allerdings ein gewisses Feintuning angesagt (Indizieren, Caches einstellen etc). Du kannst solche Datenmengen übrigens auch locker mit PostgreSQL verwalten, locker deshalb, weil es Dir einiges an Feintuning abnimt und eine der wenigen Datenbanken ist, die konstante Queryzeiten zu einer Abfrage liefert (probiere das mal mit MSSQL )
Bei DB2 kenne ich mich nicht so gut aus, allerdings kostet es auch einiges soweit ich weis. Was ganz wegfällt in größeren Dimensionen, auch bei entsprechender Hardware, ist MSSQL, die Jungs haben es einfach net druff Oder besser Gott sei Dank!

 

[Gast2]

Was ganz wegfällt in größeren Dimensionen, auch bei entsprechender Hardware, ist MSSQL

Woher nimmst du diese Weisheit? Ich kenne einige MSSQL Systeme die mit riesigen Datenmengen genauso performat hantieren wie eine vergleichbare Oracle oder DB2. Es kommt immer drauf an ob der DBA und die Datenbank Designer wissen was sie tun.

Das einzige Problem bei MSSQL ist das durch die Klicki-bunit Server Management GUI es viel zu leicht ist ein System zu administrieren und so viele MSSQL Server von unqualifizierten DBAs (wenn man sie überhaupt als solches bezeichnen kann) verwaltet werden.

Ein ähnliches Problem hat meiner Erfahrung nach aus MySQL. Es ist viel zu leicht ein funktionierendes System aufzubauen, es gibt eine riesen Anzahl an HowTos und Tutorials mit zweifelhafter Qualität - bei MySQL sind es vorallem dieser PHP+MySQL-wir-bauen-uns-eine-tolle-Webanwedung HowTos.

 

[homer65]

Die Hardware dazu ist das A&O.

Ja, die Hardware ist wichtig. Aber genauso wichtig ist ein fähiger Administrator. Ohne den geht es auch nicht.

 

[fastjack]

@fassy diese Systeme kenne ich leider nicht. Die Weisheit nehme ich daher, daß ich bis jetzt immer in Firmen gearbeitet hatte, die von MSSQL weg umstellten, wegen erheblicher Performance-Problemen. Daran war auch nicht das Design Schuld sondern einfach mal das MSSQL. In zwei Firmen wurden spezielle MSSQL-Berater eingekauft, einer kam direkt von Microsoft und erzählte uns dann, das mit diesen Datenmengen der MSSQL-Server eh nicht klarkommt.

 

[Gast2]

In zwei Firmen wurden spezielle MSSQL-Berater eingekauft, einer kam direkt von Microsoft und erzählte uns dann, das mit diesen Datenmengen der MSSQL-Server eh nicht klarkommt.

Dann gehört der entlassen! Ich bin kein MSSQL Fan - eigentlich schlägt mein Herz für Oracle - aber die Aussage ist einfach Blödsinn. Ich hab einige große Projekte im Moment die mit Terabyte großen MSSQL Instanzen arbeiten die hervorragende Performance liefern. Bei gängigen Benchmarks wie den von TPC schlägt sich der MSSQL auch immer sehr gut.

Aber egal - für diese Frage ist ja eh MySQL relevant, da müsen wir uns nicht über die Vor- oder Nachteile von anderen RDBMS streiten.

 

[homer65]

Partitionieren: MySQL :: MySQL 5.1 Reference Manual :: 18.1 Overview of Partitioning in MySQL

Wußte ich gar nicht, das MySQL auch Partitionieren kann. Schick. Ich denke, das ist das Mittel der Wahl, um große Tabellen in den Griff zu kriegen.

 

[ARadauer]

mit mehreren Hundertmillionen Datensätzen

wow... da muss man aber schon genau wissen was man tut und das nicht nur auf dba seite... da muss auch der Anwendungsentwickler entsprechende queries absetzen...

 

[Hobbes]

Danke für die Antworten. Vor allem an jastjack Da keine komplizierten Abfragen oder Joins geplant sind, werde ich also das Experiment wagen

Weitere Meinungen und Diskussionen werde ich aber mit Interesse verfolgen.

 

[Gast2]

Schau dir auf jeden Fall die Partitionierung an! Das bringt eine Menge und ist bei großen Tables wirklich sinnvoll.

 

[Hobbes]

Dass MySQL Partitionierung kann, wußte ich bislang auch nicht. Klang im ersten Moment sehr interessant. Beim genauen Lesen des Artikels sind dann aber einige Einschränkungen aufgefallen. Wenn ich es richtig verstanden habe, ist dieses Feature noch relativ neu und es hängt davon ab, in welcher MySQL-Version die Tabellen angelegt wurden. Ein Update der Datenbank wäre dann nicht immer problemlos möglich.

Oder habe ich da was falsch verstanden?

 

[Gast2]

Ja, das ist recht neu. Du musst die Tabellen anlegen in einer Version die Partionierung unterstützt. (Dachte es geht eh um ein neues Projekt?, sonst ein Migrations Skript schreiben -> alte Tabelle umbennen, neue Tabelle anlegen, Daten übernehmen). Ein Update auf spätere Versionen ist möglich. Downgrades werden nur schwierig...