Supportnet / Forum / Datenbanken
Grenze bei Mysql
Frage
Hi!
mich würde mal interessieren, wo die Grenze bei mysql liegt. Also wieviel Datensätze in einer Tabelle verkraftet mysql?
Ich habe gerade eine Datenbank mit php/mysql erstellt, und nun sind schon fast 25.000 Datensätze in einer Tabelle und es werden immer mehr.
Sollte ich bei der Größenordnung besser auf eine andere Datenbank wechseln? Wenn ja, welche und wo sind dort die Grenzen?
Danke für eure Tipps!
Antwort 1 von MixMax
Scalability and Limits
Handles large databases. We are using MySQL Server with some databases that contain 50 million records and we know of users that use MySQL Server with 60,000 tables and about 5,000,000,000 rows.
Up to 32 indexes per table are allowed. Each index may consist of 1 to 16 columns or parts of columns. The maximum index width is 500 bytes (this may be changed when compiling MySQL Server). An index may use a prefix of a CHAR or VARCHAR field.
ich glaube wenn das system (Rechner, Betriebssystem) mitmacht gibts kaum grenzen. (also max Dateigröße des Dateisystems etc)
http://www.mysql.com/documentation/mysql/bychapter/manual_Introduct...
Handles large databases. We are using MySQL Server with some databases that contain 50 million records and we know of users that use MySQL Server with 60,000 tables and about 5,000,000,000 rows.
Up to 32 indexes per table are allowed. Each index may consist of 1 to 16 columns or parts of columns. The maximum index width is 500 bytes (this may be changed when compiling MySQL Server). An index may use a prefix of a CHAR or VARCHAR field.
ich glaube wenn das system (Rechner, Betriebssystem) mitmacht gibts kaum grenzen. (also max Dateigröße des Dateisystems etc)
http://www.mysql.com/documentation/mysql/bychapter/manual_Introduct...
Antwort 2 von Unforgiven_II
Eine recht gute Antwort darauf gibt es von Kristian Köhntopp:
"MySQL speichert Daten mit Index in Baumstrukturen. Auf diese Datenstrukturen kann mit logarithmischer Komplexität zugegriffen werden, d.h. für eine Tabelle mit n Datensätzen sind log(b, n) Zugriffe notwendig, bis der gesuchte Datensatz gefunden ist. b ist die Basis des Logarithmus. Wäre b gleich 2, dann wären zum Zugriff auf eine Tabelle mit 1.000 Datensätzen maximal 10, auf eine Tabelle mit 1.000.000 Datensätzen maximal 20 und auf eine Tabelle mit 1.000.000.000 maximal 30 Zugriffe notwendig, um einen beliebigen Zieldatensatz über den Index zu finden. Tatsächlich ist die Basis jedoch nicht 2, sondern weit größer. Sie ist abhängig von der internen Blockgröße der Datenbank und der mittleren Satzlänge in einem Index. Man kann annehmen, daß sie je nach Art der Daten zwischen 20 und 40 liegt. Damit wären zum Finden eines Datensatzes aus 1.000 Datensätzen maximal 3, aus 1.000.000 Datensätzen maximal 5 und aus 1.000.000.000 Datensätzen maximal 7 Vergleiche und Plattenzugriffe notwendig.
Entsprechend sind die Erfahrungen, die mit MySQL berichtet werden: Im Rahmen der Begrenzungen des Betriebssystems (maximale Dateigröße 2 GB?) kommt MySQL mit beliebig großen Tabellen problemlos klar.
Beschränkungen ergeben sich in MySQL aus dem Fehlen bestimmter Eigenschaften wie Erzwingung referentieller Integrität (keine foreign key Prüfungen, siehe dazu auch die Bemerkungen über PostgreSQL) und Transaktionen. Das Fehlen dieser Eigenschaften macht die Implementierung von Datenbankschemata sehr mühsam, die schreibend auf mehr als eine Tabelle zur Zeit zugreifen.
Man kann abschätzen, ob MySQL für eine Aufgabe das passende Tool ist, indem man sich das geplante Datenbankschema und die geplanten Transaktionen auf diesem Schema ansieht, alle n:m und Sternbeziehungen isoliert und dann feststellt, in welchen dieser Beziehungen schreibende Zugriffe notwendig sind, die mehr als eine Tabelle aktualisieren.
MySQL ist geeignet für alle Modelle, die read-mostly sind oder die weitaus überwiegend Schreibzugriffe auf einzelne Tabellen haben. MySQL ist nicht optimal geeignet, wenn ein Modell sehr viele Schreibzugriffe hat, wenn ein Modell mehr als 2 Schreibzugriffe hat, die mehr als eine Tabelle gleichzeitig aktualisieren oder wenn ein Modell zwingend auf referentielle Integrität angewiesen ist, aber mehr als eine Anwendung schreibend auf den Bestand zugreift."
"MySQL speichert Daten mit Index in Baumstrukturen. Auf diese Datenstrukturen kann mit logarithmischer Komplexität zugegriffen werden, d.h. für eine Tabelle mit n Datensätzen sind log(b, n) Zugriffe notwendig, bis der gesuchte Datensatz gefunden ist. b ist die Basis des Logarithmus. Wäre b gleich 2, dann wären zum Zugriff auf eine Tabelle mit 1.000 Datensätzen maximal 10, auf eine Tabelle mit 1.000.000 Datensätzen maximal 20 und auf eine Tabelle mit 1.000.000.000 maximal 30 Zugriffe notwendig, um einen beliebigen Zieldatensatz über den Index zu finden. Tatsächlich ist die Basis jedoch nicht 2, sondern weit größer. Sie ist abhängig von der internen Blockgröße der Datenbank und der mittleren Satzlänge in einem Index. Man kann annehmen, daß sie je nach Art der Daten zwischen 20 und 40 liegt. Damit wären zum Finden eines Datensatzes aus 1.000 Datensätzen maximal 3, aus 1.000.000 Datensätzen maximal 5 und aus 1.000.000.000 Datensätzen maximal 7 Vergleiche und Plattenzugriffe notwendig.
Entsprechend sind die Erfahrungen, die mit MySQL berichtet werden: Im Rahmen der Begrenzungen des Betriebssystems (maximale Dateigröße 2 GB?) kommt MySQL mit beliebig großen Tabellen problemlos klar.
Beschränkungen ergeben sich in MySQL aus dem Fehlen bestimmter Eigenschaften wie Erzwingung referentieller Integrität (keine foreign key Prüfungen, siehe dazu auch die Bemerkungen über PostgreSQL) und Transaktionen. Das Fehlen dieser Eigenschaften macht die Implementierung von Datenbankschemata sehr mühsam, die schreibend auf mehr als eine Tabelle zur Zeit zugreifen.
Man kann abschätzen, ob MySQL für eine Aufgabe das passende Tool ist, indem man sich das geplante Datenbankschema und die geplanten Transaktionen auf diesem Schema ansieht, alle n:m und Sternbeziehungen isoliert und dann feststellt, in welchen dieser Beziehungen schreibende Zugriffe notwendig sind, die mehr als eine Tabelle aktualisieren.
MySQL ist geeignet für alle Modelle, die read-mostly sind oder die weitaus überwiegend Schreibzugriffe auf einzelne Tabellen haben. MySQL ist nicht optimal geeignet, wenn ein Modell sehr viele Schreibzugriffe hat, wenn ein Modell mehr als 2 Schreibzugriffe hat, die mehr als eine Tabelle gleichzeitig aktualisieren oder wenn ein Modell zwingend auf referentielle Integrität angewiesen ist, aber mehr als eine Anwendung schreibend auf den Bestand zugreift."
Antwort 3 von semi
Laut mySQL-Manual ist die Grösse einer Tabelle nur durch die max. Grösse einer Datei beim gegebenen Dateisystem begrenzt.
Standarmässig sollen es angeblich 4 GB sein. mySQL bietet auch die Möglichkeit, die Daten einer Tabelle zu komprimieren.
Eine Alternative wäre Oracle. Was dort die max. Grösse ist, weiss ich leider nicht.
Wenn es sich bei den 25000 Datensätzen um irgendwelche Daten handelt, die nicht ständig verfügbar sein müssen (z.B. Log-Einträge), dann kannst Du die Tabelle auf mehrere gleiche Tabellen verteilen. Einer Art Backup älterer Datensätze, die nur bei Bedarf abgefragt werden. Dann noch eine zusätzliche Tabelle, die Informationen über die einzelnen Tabellen verwaltet (Tabellennamen, Größe, Datumsbereich der Datensätze o.ä.).
Etwas mehr Programmieraufwand, dürfte aber eine akzeptable Lösung sein.
Gruß,
Michael
Standarmässig sollen es angeblich 4 GB sein. mySQL bietet auch die Möglichkeit, die Daten einer Tabelle zu komprimieren.
Eine Alternative wäre Oracle. Was dort die max. Grösse ist, weiss ich leider nicht.
Wenn es sich bei den 25000 Datensätzen um irgendwelche Daten handelt, die nicht ständig verfügbar sein müssen (z.B. Log-Einträge), dann kannst Du die Tabelle auf mehrere gleiche Tabellen verteilen. Einer Art Backup älterer Datensätze, die nur bei Bedarf abgefragt werden. Dann noch eine zusätzliche Tabelle, die Informationen über die einzelnen Tabellen verwaltet (Tabellennamen, Größe, Datumsbereich der Datensätze o.ä.).
Etwas mehr Programmieraufwand, dürfte aber eine akzeptable Lösung sein.
Gruß,
Michael
Antwort 4 von MixMax
Dateigröße bei FAT32 = 4 GB
bei NTFS = Partitions/Laufwerksgröße (bzw vielleicht habe ich einfach keine partitionen die da ran reichen)
bei NTFS = Partitions/Laufwerksgröße (bzw vielleicht habe ich einfach keine partitionen die da ran reichen)
Antwort 5 von semi
Zitat:
Another solution can be the included MERGE library, which allows you to handle a collection of identical tables as one.
Quelle: mySQL-ManualAnother solution can be the included MERGE library, which allows you to handle a collection of identical tables as one.