Archivierung von Daten in partitionierten Tabellen - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Archivierung von Daten in partitionierten Tabellen

MySQL unterstütztpartitionierendfür die InnoDB-Speicher-Engine, und Sie können diese Funktion verwenden, um große Tabellen zu partitionieren. Partitionen innerhalb der Tabelle werden als separate physische Tabellen gespeichert, obwohl das SQL, das mit der partitionierten Tabelle arbeitet, die gesamte Tabelle liest. Dies gibt Ihnen die Freiheit, nicht benötigte Partitionen aus der Tabelle zu entfernen, ohne dass Sie einen Vorgang ausführen müssenrow-by-rowlöscht, sodass Sie historische Zeilen in Ihrer Datenbank archivieren können.

Sehen Sie sich den folgenden Beispielcode an.TABLE ordersexistiert innerhalb derorderprocessingSchema. Seine historischen Daten sind in der Partition vorhandenphistorical, das Daten aus dem Jahr 2021 und früher enthält. In derselben Tabelle sind heiße Daten auf Anwendungsebene in den Live-Partitionen für jeden Monat des Jahres 2022 vorhanden. Um die Daten auf der Partition zu archivierenphistorical, Sie können ein Archiv erstellentable orders_2021_and_oldermit der gleichen Struktur in derarchiveSchema. Sie können dann das MySQL verwendenPARTITION AUSTAUSCHENum die Partition zu verschiebenphistoricalin diesen Tisch. Beachten Sie, dass die Archivtabelle nicht partitioniert ist. Nach der Archivierung können Sie Ihre Daten überprüfen und nach Amazon S3 verschieben.

CREATE TABLE orders (
      orderid bigint NOT NULL AUTO_INCREMENT,
      customerid bigint DEFAULT NULL,
      ............
      ............
      order_date date NOT NULL,
      PRIMARY KEY (`orderid`,`order_date`))
    PARTITION BY RANGE (TO_DAYS(order_date)) (
          PARTITION pstart   VALUES LESS THAN (0),
          PARTITION phistorical VALUES LESS THAN (TO_DAYS('2022-01-01')),
          PARTITION p2022JAN VALUES LESS THAN (TO_DAYS('2022-02-01')),
          PARTITION p2022FEB VALUES LESS THAN (TO_DAYS('2022-03-01')),
          PARTITION p2022MAR VALUES LESS THAN (TO_DAYS('2022-04-01')),
          PARTITION p2022APR VALUES LESS THAN (TO_DAYS('2022-05-01')),
          PARTITION p2022MAY VALUES LESS THAN (TO_DAYS('2022-06-01')),
          PARTITION p2022JUN VALUES LESS THAN (TO_DAYS('2022-07-01')),
          PARTITION p2022JUL VALUES LESS THAN (TO_DAYS('2022-08-01')),
          PARTITION p2022AUG VALUES LESS THAN (TO_DAYS('2022-09-01')),
          PARTITION p2022SEP VALUES LESS THAN (TO_DAYS('2022-10-01')),
          PARTITION p2022OCT VALUES LESS THAN (TO_DAYS('2022-11-01')),
          PARTITION p2022NOV VALUES LESS THAN (TO_DAYS('2022-12-01')),
          PARTITION p2022DEC VALUES LESS THAN (TO_DAYS('2023-01-01')),
          PARTITION pfuture       VALUES LESS THAN MAXVALUE
      );
CREATE TABLE orders_2021_and_older (
        orderid bigint NOT NULL AUTO_INCREMENT,
        customerid bigint DEFAULT NULL,
        ............
        ............
        order_date date NOT NULL,
        PRIMARY KEY (`orderid`,`order_date`));
mysql> alter table orderprocessing.orders exchange partition phistorical with table archive.orders_2021_and_older;
  Query OK, 0 rows affected (0.33 sec)

Wenn du das benutztEXCHANGE PARTITIONUm historische Daten zu archivieren, empfehlen wir die folgenden Best Practices:

  • Erstellen Sie ein separates Schema zum Speichern von Archivdaten in Ihrer Anwendung. Dieses Schema wird Archivtabellen enthalten, in denen archivierte Daten gespeichert werden. Eine Archivtabelle in Ihrem Archivschema sollte dieselbe Struktur wie Ihre Live-Tabelle haben, einschließlich ihrer Indizes und ihres Primärschlüssels. Die Zielarchivtabelle kann jedoch keine partitionierte Tabelle sein. Der Austausch von Partitionen zwischen zwei partitionierten Tabellen ist in MySQL nicht zulässig.

  • Folgen Sie einer Namenskonvention für Ihre Archivtabelle, anhand derer Sie die darin gespeicherten historischen Daten identifizieren können. Dies ist nützlich, wenn Sie Prüfungsaufgaben ausführen oder Jobs entwerfen, die diese Daten nach Amazon S3 verschieben.

  • Führen Sie dieEXCHANGE PARTITIONDDL-Anweisung (Data Definition Language) in einem Ausfallfenster, wenn kein Datenverkehr in Ihren Aurora MySQL-kompatiblen Writer, Amazon RDS für MySQL oder Amazon RDS für MariaDB-Instances eingeht.

    Es könnte möglich sein zu rennenEXCHANGE PARTITIONbei wenig frequentierten Fenstern in Ihrer Anwendung oder Ihrem Microservice. Es sollte jedoch keine Schreibvorgänge und keine oder nur sehr wenige Auswahlen in der partitionierten Tabelle geben. Bestehende lang andauernde Auswahlabfragen können dazu führen, dassEXCHANGE PARTITIONDDL wartet, was zu Ressourcenkonflikten in Ihrer Datenbank führt. Entwerfen Sie Skripts, die verifizieren, dass all diese Bedingungen erfüllt sind, bevor Sie sie ausführenEXCHANGE PARTITIONauf Ihrem System.

Wenn Ihr Anwendungsdesign partitionierte Daten unterstützen kann und Sie derzeit über eine unpartitionierte Tabelle verfügen, sollten Sie erwägen, Ihre Daten in partitionierte Tabellen zu verschieben, um die Archivierung Ihrer Daten zu unterstützen. Weitere Informationen finden Sie in der MySQL-Dokumentation.