Details zum Vergleich der MySQL-Datenkomprimierungsleistung

Die vom Datenwürfel benötigten Daten werden nach dem Schreiben selten oder nie aktualisiert. Diese Art von Daten eignet sich gut zur Komprimierung, um den Festplattenverbrauch zu reduzieren. MySQL selbst bietet zwei Komprimierungsmethoden – archive Engine und myisampack -Methode für MyISAM -Engine. Heute haben wir diese beiden Methoden separat getestet und ihre Vor- und Nachteile hinsichtlich Datenträgernutzung und Abfrageleistung verglichen. Warum ich das tue, sollten Sie verstehen. Ich werde es später erläutern. Und schauen Sie sich den Text an:

1. Testumgebung

1.1 Hardware und Software

Eine 64-Bit Linux Entwicklungsmaschine mit 2.6.18-92 Kernel, 4 GB Arbeitsspeicher und vier 2800Mhz Dual-Core AMD Opteron (tm) Processor 2220 CPUs.

MySQL befindet sich auf einer SAT-Festplatte mit 7200 U/min, nicht im raid .

An MySQL wurde keine Optimierung vorgenommen und query cache wurde deaktiviert, um zu verhindern, dass query cache die Testergebnisse beeinflusst.

1.2 Tabellenstruktur

2.424.753 Datensätze, tatsächliche Daten eines Shards in der Produktionsumgebung;

Die gemeinsamen Indizes ( partition_by1,idx_rank ) und ( partition_by1,chg_idx ) werden jeweils festgelegt, wobei partition_by1 ein varchar-Typ mit einer Länge von 32 ist und zum Abrufen verwendet wird; die anderen beiden Felder sind Gleitkommazahlen und werden hauptsächlich zum Sortieren verwendet;

Als Unterspalte fungiert autokid als PRIMARY KEY und wird nur verwendet, um die Atomizität beim Laden der Daten sicherzustellen. Es hat keine praktische Bedeutung.

2. Testzweck

2.1 Vergleich des Kompressionsraums

Je höher die Komprimierungsrate, desto weniger Speicherplatz wird belegt, was die Datenspeicherkosten direkt senkt.

2.2 Vergleich der Abfrageleistung

Nach der Komprimierung sollte es zu keiner merklichen Verschlechterung der Abfrageleistung kommen. Da Archive keine Indizierung unterstützen, ist eine Leistungsverschlechterung unvermeidlich. Wir sollten auch eine Vorstellung davon haben, wie stark die Leistung reduziert wird und ob dies akzeptabel ist.

3. Testwerkzeuge

3.1 MySQL-Lappen

Das offizielle Tool ist natürlich die beste Wahl. Eine Einführung in mysqlslap finden Sie in der offiziellen Dokumentation.

3.2 Testabfrage

Insgesamt wurden 9973 tatsächliche SQL-Anweisungen abgefangen, die auf die Tabelle topranks_v3 in der Produktionsumgebung zugriffen. Davon wurden 7 mit der größten Anzahl von Besuchen extrahiert, mit einer Parallelität von 50 und 10-mal wiederholt. Der Befehl lautet wie folgt:

./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info

4. Testfazit

Basierend auf den in der obigen Tabelle angegebenen Testdaten können wir einfach die folgenden Schlussfolgerungen ziehen:

• Für die Testtabelle beträgt der von Archive Archivtabelle belegte Speicherplatz etwa 18.7% des vorherigen Speicherplatzes, und der nach myisampack belegte Speicherplatz beträgt etwa 24,6 % des vorherigen Speicherplatzes. Der Unterschied zwischen den beiden ist nicht groß. Allein aus der Perspektive der Speicherplatznutzung scheint es, dass wir archive Archivtabelle auswählen müssen.
• Schauen wir uns die Abfrageleistung an und vergleichen sie mit der Benchmark-Tabelle. In Bezug auf die Gesamtzeit und die Systemlast ist die Abfrageleistung pack bei 50 % Parallelität mit der der Benchmark-Tabelle vergleichbar; während archive Archivtabelle bei einfacher Parallelität mehr als 5 Minuten benötigt (ich kann nicht länger warten, also beende ich sie)!

Wir scheinen daher den Schluss ziehen zu können, dass ARCHIVE Engine bei Tabellen, die Online-Abfragen erfordern, grundsätzlich ignoriert werden kann.

Warum ist ARCHIVE Engine während dieses Tests so langsam?

Wir wissen, dass mysql eine archive -Engine zur Reduzierung des Festplatten-Overheads bereitstellt, es gibt jedoch auch eine Voraussetzung: Die archivierten Daten müssen nicht oder nur selten online abgefragt werden, und es spielt keine Rolle, ob die Abfrage gelegentlich langsam ist. Aus den oben genannten Gründen ist es archive nicht gestattet, andere Indizes als Auto-Increment-Spalten zu erstellen.

Mit diesem Konsens wollen wir nun einen SQL-Test durchführen, um zu analysieren, warum es einen so großen Unterschied in der Abfrageleistung vor und nach der Nichtverwendung des Index gibt.

In unserem Test-SQL gibt es eine solche Zeile:

Wählen Sie c1, c2, ..., cn aus mysqlslap.rpt_topranks_v3
WO ... UND partition_by1 = '50008090'
BESTELLEN NACH Zusatzmenge3 DESC
LIMIT 500

Wie bereits erwähnt, hat die Testtabelle einen Index für das Feld partition_by1 . Daher gehen wir vorläufig davon aus, dass diese Abfrage den Index partition_by1 für die Benchmark-Tabelle und myisampack -Tabelle verwenden sollte. ERKLÄRUNG:

mysql> ERKLÄREN
    -> AUSWÄHLEN ... AUS mysqlslap.rpt_topranks_v3
    -> WO ... UND partition_by1 = '50008090'
    -> ORDER BY Zusatzmenge3 DESC
    -> GRENZE 500\G
*************************** 1. Reihe ***************************
           ID: 1
  select_type: EINFACH
        TABELLE: rpt_topranks_v3
         Typ: ref
mögliche Schlüssel: idx_toprank_pid,idx_toprank_chg
          SCHLÜSSEL: idx_toprank_pid
      Schlüssellänge: 99
          Verweis: const
         Reihen: 2477
        Zusätzlich: USING WHERE; USING filesort
1 Zeile IM SET (0,00 Sek.)

Wie erwartet verwendet diese Abfrage den Index des Felds partition_by1 , findet die Zielzeilenanzahl 2477 und sortiert anschließend das Feld added_quantity3 . Da added_quantity3 keinen Index hat, wird filesort verwendet.

Werfen wir einen Blick auf die EXPLAIN-Ergebnisse dieses SQL in der Archivtabelle:

mysql> ERKLÄREN
    -> AUSWÄHLEN ... AUS mysqlslap.rpt_topranks_v3_<strong>Archiv</strong>
    -> WO ... UND partition_by1 = '50008090'
    -> ORDER BY Zusatzmenge3 DESC
    -> GRENZE 500\G
*************************** 1. Reihe ***************************
           ID: 1
  select_type: EINFACH
        TABELLE: rpt_topranks_v3_archive
         Typ: ALLE
mögliche Schlüssel: NULL
          SCHLÜSSEL: NULL
      key_len: NULL
          Ref: NULL
         Reihen: 2424753
        Zusätzlich: USING WHERE; USING filesort
1 Zeile IM SET (0,00 Sek.)

EXPLAIN sagt: „ Ich habe keine Indizes zur Verfügung, also kann ich nur die gesamte Tabelle nach 2424753 Zeilen durchsuchen und dann eine filesort durchführen.“ Wenn es Ihnen um Leistung geht, dann tun Sie MySQL offensichtlich Unrecht.

Dies ist das Ende dieses Artikels über die Einzelheiten des Leistungsvergleichs bei MySQL-Datenkomprimierung. Weitere Informationen zum Leistungsvergleich bei MySQL-Datenkomprimierung finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!