Wie berechnet man die Größe einer AWS RDS-Instanz aus einem MySQL-Dump?

Question

Wir importieren eine große historische Datenbank in RDS aus einem mysqldump

Die gzippte SQL-Datei war 3 GB groß, die unkomprimierte SQL-Datei ist 18 GB groß.

Wir haben eine 30 GB große AWS RDS-Instanz erstellt und die Datei importiert … der Speicherplatz der RDS-Instanz war erschöpft.

Wir haben eine 50 GB große AWS RDS-Instanz erstellt, die Datei importiert … die RDS-Instanz hatte nicht genügend Speicherplatz.

Wie berechne ich die Größe der AWS RDS-Instanz, die ich zum Importieren dieses Dumps benötige?

Um zu versuchen, alle Fragen vorab zu beantworten ...

• Wir haben keinen Zugriff auf die Maschine, von der der Dump stammt, um zu versuchen, die Größe auf diese Weise zu bestimmen.
• Ich dachte, dass vielleicht binäre RDS-Protokolle oder langsame Protokolle den Speicherplatz beanspruchen, aber ein Blick auf die tatsächliche Datenbankgröße zeigte vorhin, dass sich alles in Wirklichkeit in der Datenbank befand ...

  mysql>  SELECT table_schema "Database Name", sum( data_length + index_length ) / 1024 / 1024 "Database Size in MB"  FROM information_schema.TABLES GROUP BY table_schema ; 
  +--------------------+----------------------+
  | Database Name      | Database Size in MB  |
  +--------------------+----------------------+
  | xxxxxxxxxx         |       41658.15374756 |
  | information_schema |           0.00976563 |
  | mysql              |           5.96341228 |
  | performance_schema |           0.00000000 |
  +--------------------+----------------------+
  4 rows in set (28.39 sec)
  

Answer 1

Es ist nicht möglich, den für die Live-Datenbank erforderlichen Speicherplatz abzuschätzen, ohne etwas über die verwendeten Indizes zu wissen. Jeder Index ist im Wesentlichen eine Karte, und je mehr „Schlüssel“ die Karte enthält, desto mehr Speicherplatz wird für diese Karte benötigt.

Die Kardinalität des Index (die „Form“ der Daten, im Wesentlichen die Anzahl eindeutiger „Schlüssel“ und wie sie den Zeilen zugeordnet werden, die diesen Schlüssel enthalten) wird auch wichtig, wenn der Datentyp für die indizierte Spalte größer als ein Bigint ist. Eine indizierte Spalte von varchar(60) mit vielen eindeutigen Kombinationen (hohe Kardinalität) nimmt bei gleicher Tabellengröße mehr Speicherplatz ein als eine mit niedriger Kardinalität, da die Schlüssel in der Zuordnung mehr Speicherplatz beanspruchen als die Datenzeiger in der Zuordnung.

UPDATE: Dank Michael hätte ich weiter unten natürlich sagen sollen, dass meine Behauptung bezüglich Kardinalität und Speichergröße von der Speicher-Engine abhängt.

Beispielsweise eine Datenbank mit zwei InnoDB-Tabellen, beide mit 2176 Zeilen mit je 3 Spalten und einem Index für eine VARCHAR(32)-Spalte. Der einzige Unterschied in den Daten der beiden Tabellen besteht darin, dass tt1 2176 eindeutige Werte für die VARCHAR-Spalte hat und tt2 einen identischen Wert für die VARCHAR-Spalte.

Sie werden sehen, dass sich die Indexgröße nur um etwa 16 KB unterscheidet:

mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_idb1';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1        |       2031 |      180224 |       147456 |
| tt2        |       2031 |      180224 |       131072 |
+------------+------------+-------------+--------------+

Beachten Sie, dass der InnoDB-Datenspeicher aus zwei Komponenten besteht: einem Datenwörterbuch, das standardmäßig in der globalen Tabellenbereichsdatei ibdata1 im MySQL-Datenverzeichnis gespeichert ist, und den Tabellendaten, die in .frm-Dateien in einem Unterverzeichnis des Datenverzeichnisses gespeichert sind.

Deshalb, Michael, sehen Sie keinen Unterschied in der Speichergröße der .frm-Dateien. Wenn Sie MySQL mit der Direktive innodb_file_per_table=1 neu starten würden, würden Sie diesen Unterschied in den Tabellenbereichsdateien sehen:

drwx------. 2 mysql mysql   4096 Dec 19 10:52 .
drwxr-xr-x. 4 mysql mysql   4096 Dec 19 10:52 ..
-rw-rw----. 1 mysql mysql     65 Dec 19 10:52 db.opt
-rw-rw----. 1 mysql mysql   8610 Dec 19 10:52 tt1.frm
-rw-rw----. 1 mysql mysql 393216 Dec 19 10:52 tt1.ibd
-rw-rw----. 1 mysql mysql   8610 Dec 19 10:52 tt2.frm
-rw-rw----. 1 mysql mysql 376832 Dec 19 10:52 tt2.ibd

InnoDB-Speicher ist insofern einzigartig, als dass Tabellendaten effektiv ein Index des Datenwörterbuchs sind, was bei einigen Vorgängen Leistungsvorteile mit sich bringt. Daher ist die Auswirkung der Kardinalität auf den Speicherbedarf (in diesem Fall etwa 10 %) ganz anders als bei einem MyISAM:

mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_msm';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1        |       2126 |       85040 |        87040 |
| tt2        |       2126 |       85040 |         7168 |
+------------+------------+-------------+--------------+

drwx------.  2 mysql mysql  4096 Dec 19 09:50 .
drwxr-xr-x. 13 mysql mysql  4096 Dec 19 10:29 ..
-rw-rw----.  1 mysql mysql    65 Dec 19 09:28 db.opt
-rw-rw----.  1 mysql mysql  8610 Dec 19 09:31 tt1.frm
-rw-rw----.  1 mysql mysql 85040 Dec 19 09:48 tt1.MYD
-rw-rw----.  1 mysql mysql 87040 Dec 19 09:48 tt1.MYI
-rw-rw----.  1 mysql mysql  8610 Dec 19 09:50 tt2.frm
-rw-rw----.  1 mysql mysql 85040 Dec 19 09:51 tt2.MYD
-rw-rw----.  1 mysql mysql  7168 Dec 19 09:51 tt2.MYI

Hoffe, das erklärt es etwas genauer.