Mysql, handlersocket e partizionamento?

Question

Il plug-in Handlersocket è a conoscenza del possibile partizionamento su un tavolo? Non ho trovato menzioni sulla documentazione di questo, non so nemmeno se il partizionamento è trasparente per il socket del gestore o è qualcosa che fa lo sql optimizer.

Answer 1

Risposta breve:

HandlerSocket funziona bene contro le tabelle partizionate (nel senso che tutte le operazioni sono supportate), ma non è a conoscenza di partizionamento. L'eliminazione delle partizioni non viene tentata e, pertanto, si verifica un sovraccarico delle prestazioni quando si utilizza l'handlersocket con le tabelle partizionate.

Risposta lunga:

Il partizionamento in MySQL è implementata a diversi livelli: parser, gestore generico, Query Optimizer. Il gestore generico (ha_partition) fornisce il partizionamento ai motori che non lo supportano nativamente (tutti tranne NDB). Questo gestore implementa un tipo di sequenza di responsabilità: si collega tra il server ei normali gestori del motore sottostante (uno per partizione).

Quando una query viene eseguita, il gestore ha_partition inoltra le operazioni a tutti i gestori sottostanti corrispondenti a ciascuna partizione. Questo è il motivo per cui è possibile avere lo stesso supporto di partizionamento per InnoDB, MyISAM, ecc ...

L'eliminazione delle partizioni (ovvero il filtraggio di ricerche inutili/scansioni su partizioni) è implementata in Query Optimizer, non nel gestore ha_partition. Quindi, in pratica, quando una ricerca viene eseguita tramite ha_partition, se l'ottimizzatore non ha limitato l'elenco delle partizioni, le ricerche vengono eseguite su tutte le partizioni e quindi viene utilizzato un algoritmo di unione per leggere i cursori n in parallelo.

I seguenti presentation di Mattias Jonsson e Mikael Ronström (Oracle) sono molto utili per capire come il partizionamento è implementato in MySQL.

Ora il plug-in HandlerSocket si basa direttamente sul gestore generico. Non c'è conoscenza delle partizioni a livello di HandlerSocket. Quando la query HandlerSocket viene applicata a una tabella partizionata, il gestore ha_partition verrà utilizzato in modo trasparente.

La buona notizia è che HandlerSocket funziona bene contro tabelle partizionate senza costi aggiuntivi. La cattiva notizia è che non beneficia dell'eliminazione delle partizioni poiché è implementata solo nel Query Optimizer di SQL.

Ecco un esempio per dimostrarlo (testato su Percona Server 5.5). Useremo 2 tabelle: mytable_np non è partizionato, mytable è partizionato.

create table mytable_np (id int, x varchar(100), primary key(id), key(x)) 
engine=InnoDB ; 

insert into mytable_np values (1, 'A'); 
insert into mytable_np values (11, 'B'); 
insert into mytable_np values (21, 'C'); 
insert into mytable_np values (31, 'D'); 
insert into mytable_np values (41, 'E'); 
insert into mytable_np values (51, 'F'); 
commit; 

create table mytable (id int, x varchar(100), primary key(id), key(x)) 
engine=InnoDB 
partition by range (id) (
    partition p0 values less than (10), 
    partition p1 values less than (20), 
    partition p2 values less than (30), 
    partition p3 values less than (40), 
    partition p4 values less than (50), 
    partition pend values less than (1000) 
); 

insert into mytable values (1, 'A'); 
insert into mytable values (11, 'B'); 
insert into mytable values (21, 'C'); 
insert into mytable values (31, 'D'); 
insert into mytable values (41, 'E'); 
insert into mytable values (51, 'F'); 
commit; 

le seguenti query si può fare per eseguire un semplice accesso chiave primaria:

select * from mytable where id = 51 ; 

select * from mytable_np where id = 51 ; 

I seguenti script netcat/Telnet possono essere utilizzati per eseguire query utilizzando HandlerSocket (attenzione ai caratteri TAB):

Per valutare il numero di ricerche, è possibile eseguire la seguente query prima e dopo ogni esecuzione di query per contare il numero di accessi chiave del gestore:

show global status like 'Handler_read_key' ; 

Se misuriamo il numero di chiave gestore accessi fatto in quattro casi, abbiamo ottenuto:

SQL query against non partitioned table:  2 
SQL query against partitioned table:   2 
HandlerSocket against non partitioned table: 2 
HandlerSocket against partitioned table:  7 

Nei primi tre casi, abbiamo una ricerca per trovare la riga, più un ulteriore accesso chiave per controllare questa è l'ultima riga da leggere. Nell'ultimo caso, abbiamo una ricerca per partizione non vuota. Ce ne sono 6 La chiave si trova in una sola di esse e viene fatto un ulteriore accesso per verificare che ci sia una sola riga corrispondente. Quindi il risultato è 7.

Questo esempio dimostra che anche nel caso più semplice (accesso alla chiave primaria), HandlerSocket non è in grado di eliminare le partizioni. Una penalità di prestazioni dovrebbe sempre essere prevista quando HandlerSocket viene utilizzato contro le partizioni. Più partizioni, più in alto (lineare).