Aufteilen der Datenbanktabelle in häufig abgefragte Daten + andere Daten

Spaltet die Datenbanktabelle bis zu am häufigsten angeforderten Daten und der Rest der Daten gibt erhebliche Leistungssteigerung? Ich habe letzte Woche oder so verbracht, sehr technische Tutorials und Konferenzen zu beobachten, aber es ist mir immer noch nicht klar, wie groß die Spaltenanzahl, die Spaltenposition und die Zeilenanzahl in der Leistung sind (wenn die ganze Tabelle in den Speicher passt/RAM).Aufteilen der Datenbanktabelle in häufig abgefragte Daten + andere Daten

Ich habe 4 verschiedene Optionen skizziert. Was wären die Vor- und Nachteile für jeden Ansatz?

Einige Details:

Meist lautet: mindestens 80% - Wert auf Leistung ist
10 verschiedene Kategorien - jeweils mit ~ 100K Einträgen/Reihen
30 Gesamtwerte in jedem Kategorie
5 häufig abgefragte Werte (in beiden Listen und einzelnen Postsichten verwendet)
25 weniger häufig abgefragte Werte (Nur in einzelnen Postansicht)
fest: wenn ich sage Wert, ich meine Einheit/Datenbankspalte

Quelle

2016-05-01 Solo

Warum nicht einfach große Probendaten erstellen und einige Tests durchführen? –

@PaulSpiegel Ich dachte, dass vielleicht jemand auf diesem Gebiet gut genug ist und weiß, wovon er redet. Dieser Test würde große Vorbereitungen erfordern und vielleicht hat jemand anderes die gleiche Frage in der Zukunft. – Solo

Leistungsabstimmung ist keine einfache Angelegenheit und Vereinfachung schwierig; aber es ist normalerweise mehr mit der Anzahl der Zeilen als mit der Anzahl der Spalten beschäftigt. 'select *' wird nicht empfohlen und Sie sollten nur die benötigten Spalten angeben. Das Tabellendesign sollte den Regeln der Normalisierung folgen. –

Hier ein Testfall ist:

Erstellen Sie Testdaten mit 1M Zeilen:

drop table if exists posts; 
create table posts (
    id int not null primary key, 
    summary varchar(255), 
    post text 
) as 
    select seq as id 
    , repeat(rand(1), 10) as summary 
    , repeat(rand(1), 100) as post 
    from seq_1_to_1000000 
; 

drop table if exists small_data; 
create table small_data (
    id int not null primary key, 
    summary varchar(255) 
) as select p.id, p.summary from posts p 
; 
drop table if exists big_data; 
create table big_data (
    id int not null primary key, 
    post text 
) as select p.id, p.post from posts p; 

show table status where Name in('posts', 'small_data', 'big_data'); 

Name  | Engine | Row_format | Rows | Avg_row_length | Data_length 
big_data | InnoDB | Compact | 870341 |   2361 | 2055208960 
posts  | InnoDB | Compact | 838832 |   2627 | 2204106752 
small_data | InnoDB | Compact | 985832 |   229 | 226197504

So gibt es drei Tabellen.

posts ~ 2,1 GB. enthält alle Daten (ID, Zusammenfassung ~ 200 Bytes, Post ~ 2000 Bytes).
small_data ~ 215 MB. enthält (ID, Zusammenfassung)
big_data ~ 1,9 GB. enthält (id, Post)

select p.id, p.summary 
from posts p 
order by id asc 
limit 10 
offset 500000

Erster Lauf: 16,552 sec. Zweiter Lauf: 16,723 s.

select p.id, p.summary 
from small_data p 
order by id asc 
limit 10 
offset 500000

Erstdurchlauf: 0,702 Sek. Zweiter Lauf: 0,093 s.

Sie können sehen, es kann einen großen Unterschied geben. Aber es kommt auf Ihre Daten und Ihre Anfragen an. Sie sollten also Ihre eigenen Benchmarks machen.

Hinweise:

Getestet auf 10.0.19-MariaDB.
seq_1_to_1000000 ist eine Tabelle mit 1M Sequenznummern. Sie müssen es zuerst erstellen oder das MariaDBs Sequence Plugin verwenden.

Quelle

2016-05-01 22:41:06

Aufteilen der Datenbanktabelle in häufig abgefragte Daten + andere Daten

Antwort

Verwandte Themen