Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

MySQL:Dividindo uma tabela grande em partições ou tabelas separadas?


Bem, se você está esperando por uma nova resposta, isso significa que você provavelmente leu minhas respostas, e eu pareço um disco quebrado. Consulte Blog de particionamento para os poucos casos de uso em que o particionamento pode ajudar no desempenho. O seu não soar como qualquer um dos 4 casos.

Reduzir device_id . INT é 4 bytes; você realmente tem milhões de dispositivos? TINYINT UNSIGNED é de 1 byte e um intervalo de 0..255. SMALLINT UNSIGNED é de 2 bytes e um intervalo de 0..64K. Isso vai diminuir um pouco a tabela.

Se o seu real questão é como gerenciar tantos dados, então vamos "pensar fora da caixa". Leia.

Gráficos... Quais intervalos de datas você está representando graficamente?
  • A 'última' hora/dia/semana/mês/ano?
  • Uma hora/dia/semana/mês/ano arbitrário?
  • Um intervalo arbitrário, não vinculado aos limites de dia/semana/mês/ano?

O que você está grafando?
  • Valor médio de um dia?
  • Máx./min ao longo de um dia?
  • Velas (etc) para o dia ou semana ou qualquer outra coisa?

Independentemente do caso, você deve construir (e manter incrementalmente) uma Tabela de Resumo com dados. Uma linha conteria informações de resumo por uma hora. eu sugeriria
CREATE TABLE Summary (
    device_id SMALLINT UNSIGNED NOT NULL,
    sensor_id TINYINT UNSIGNED NOT NULL,
    hr TIMESTAMP NOT NULL,
    avg_val FLOAT NOT NULL,
    min_val FLOAT NOT NULL,
    max_val FLOAT NOT NULL
    PRIMARY KEY (device_id, sensor_id, hr)
) ENGINE=InnoDB;

A tabela de Resumo pode ter 9 GB (para a quantidade atual de dados).
SELECT hr,
       avg_val,
       min_val,
       max_val
    FROM Summary
    WHERE device_id = ?
      AND sensor_id = ?
      AND hr >= ?
      AND hr  < ? + INTERVAL 20 DAY;

Daria a você os valores hi/lo/avg para 480 horas; suficiente para representar graficamente? Pegar 480 linhas da tabela de resumo é muito mais rápido do que pegar 60*480 linhas da tabela de dados brutos.

Obter dados semelhantes por um ano provavelmente sufocaria um pacote de gráficos, então pode vale a pena construir um resumo do resumo -- com resolução de um dia. Seria cerca de 0,4 GB.

Existem algumas maneiras diferentes de construir a(s) tabela(s) de Resumo; podemos discutir isso depois que você refletir sobre sua beleza e ler o blog de tabelas de resumo . Pode ser que reunir uma hora de dados e, em seguida, aumentar a tabela Resumo seja a melhor maneira. Isso seria um pouco como o flip-flop discutido meu blog Staging table .

E, se você tivesse os resumos de hora em hora, você realmente precisa dos dados minuto a minuto? Considere jogá-lo fora. Ou, talvez, dados após, digamos, um mês. Isso leva ao uso de particionamento, mas apenas para seu benefício na exclusão de dados antigos conforme discutido no "Caso 1" do Blog de particionamento . Ou seja, você teria partições diárias, usando DROP e REORGANIZE todas as noites para mudar a hora da tabela "Fato". Isso levaria a diminuir sua pegada de 145 GB, mas sem perder muitos dados. Novo espaço ocupado:cerca de 12 GB (resumo por hora + detalhes minuto a minuto dos últimos 30 dias)

PS:O blog da tabela de resumo mostra como obter o desvio padrão.