Tenho um grande e complicado conjunto de dados de neurociência que estou tentando organizar em um banco de dados para acesso simultâneo e consistente com meu laboratório. Esta é minha primeira incursão além de experimentos muito menores com SQLite, e eu mordi mais do que posso mastigar.
A tabela primária que contém as gravações neurais tem cerca de 10 bilhões de linhas. Antes de preencher esta tabela com dados, estabeleci uma chave primária composta (id, experiment_id)
onde id
é exclusivo para cada linha. Fiz isso para poder particionar a tabela por experiment_id
. Isso parecia uma boa ideia na época. No entanto, uma vez que a tabela foi preenchida, a adição de índices adicionais falhou no phpMyAdmin (o pop-up de erro indicou que a nova chave estava corrompida).
Diante desse obstáculo, encontrei https://mariadb.com/kb/en/partition-maintenance/ , que tem como primeiro marcador "# 1: Não use o PARTITIONing até saber como e por que isso ajudará. ", seguido por "o tamanho da tabela raramente é um problema de desempenho". Então, na esperança de "fazer de novo", criei uma nova tabela com as mesmas colunas (menos a id
coluna), mas sem esquema de particionamento e sem índices e executei:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;
INSERT INTO tfconv_2 (experiment_id, electrode_id, trial_id, frequency_id, time_id, value_real, value_imag)
SELECT experiment_id, electrode_id, trial_id, frequency_id, time_id, value_real, value_imag
FROM tfconv;
COMMIT;
Isso durou vários dias (o que não foi uma surpresa, já que levou dias para colocar os dados na tabela original em primeiro lugar). Enquanto o MariaDB trabalhava, pude ver a contagem de linhas na página de resumo do phpMyAdmin subindo para a nova tabela. Monitorando recursos em meu servidor, parecia que o processo estava funcionando de maneira regular e sistemática para copiar os dados para a nova tabela.
Então, uma vez, quando fui verificar, a contagem de linhas na nova tabela havia diminuído. SHOW PROCESSLIST
revelou:
Id User Host db Command Time State
10237 root localhost singlecell Killed 217191 Reset for next command
Com esse pano de fundo, tenho três perguntas:
- Por que essa consulta pode ter falhado? (Os arquivos de log de erros ficaram silenciosos durante a janela de tempo relevante.)
- Se eu tentar criar uma tabela sem partições novamente, você recomenda que eu faça algo diferente?
- Existe uma maneira de configurar índices na tabela particionada original, que possa evitar a corrupção?