Atualmente, estou usando information_schema.TABLES para calcular o uso total do espaço em disco agrupado pelo nome do banco de dados, mas ele está executando muito lentamente. Em servidores com centenas de bancos de dados, o cálculo pode levar minutos.
Qual é o método mais rápido de calcular o uso de espaço em disco por banco de dados? Devo estar apenas olhando para o sistema de arquivos? Existe um método para acelerar information_schema?
Estou trabalhando em um banco de dados para armazenar dados de "séries temporais" (o valor de X era Y neste momento). As próprias linhas são muito pequenas e de tamanho estático, com a chave primária consistindo em duas colunas smallint, 1 coluna tinyint e 1 coluna timestamp. O uso do comprimento do índice é muito baixo por linha (cerca de 12 bytes), mas o banco de dados será usado para armazenar uma quantidade muito grande de dados.
Portanto, o problema é que o servidor acabará tendo menos RAM física do que o tamanho do index_length no MySQL para essa tabela. Quais são as implicações de isso acontecer? Eu sei que em teoria o Linux pode trocar a memória para o disco, mas isso duplicará o uso do disco (já que já existe um arquivo .MYI)? Quais são as implicações de desempenho de não poder armazenar todo o índice na RAM? Ainda posso esperar seleções abaixo de 10 ms com unidades SATA II em RAID 1?
Em resposta ao primeiro comentário para mais informações
Minha pergunta era mais teórica do que prática no momento. O projeto no qual estou trabalhando é bem financiado o suficiente para que tecnicamente possamos arcar com os custos de RAM, mas prefiro saber as implicações de não ter RAM suficiente para cobrir os índices. Mas de qualquer forma, vou tentar responder de qualquer maneira.
Tecnicamente, o projeto tem RAM ilimitada, então a única razão para ter menos é manter os custos baixos.
Os dados são armazenados em tabelas MyISAM para fins de armazenamento "histórico", mas existem em um NDBCluster nas primeiras 24 horas ou mais (o NDB Cluster usa cerca de 4x o índice RAM do que MyISAM).
Certamente posso atualizar a RAM, mas isso adiciona muita complexidade.
A resposta para a quantidade de uso de MB para o índice é 2,29 MB, mas não faz sentido. No momento, estou apenas testando o uso do índice para a estrutura de dados. Os 2,29 MB consistem em 155.301 linhas (cerca de 15,5 bytes por linha).
...
Portanto, há apenas 1 mesa com a qual realmente me importo. O resto deles são muito pequenos em tamanho. A estrutura da tabela é a seguinte:
CREATE TABLE IF NOT EXISTS `monitor`.`result` (
`server` SMALLINT UNSIGNED NOT NULL ,
`ref_id` SMALLINT UNSIGNED NOT NULL ,
`request` TINYINT UNSIGNED NOT NULL ,
`recorded` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ,
`resolution` TINYINT NOT NULL ,
`value` MEDIUMINT UNSIGNED NOT NULL ,
PRIMARY KEY (`server`, `request`, `recorded`, `ref_id`) )
ENGINE = MyISAM
A razão pela qual existe uma coluna "ref_id" é restringir o que o conjunto de dados está se referindo além do nível do servidor. Por exemplo, podemos ter estatísticas sobre um usuário ou dispositivo em um servidor.
Por que eu precisaria de tanta RAM
Pode parecer que a tabela acima não usaria tanta RAM e, na maioria dos casos práticos, não. Eu gostaria de armazenar o máximo de dados possível. Entendo que posso armazenar menos dados, mas gostaria que a resolução dos dados fosse a mais alta possível. O espaço em disco é barato, então não estou nem remotamente preocupado com esse custo, mas a RAM, por outro lado, pode se tornar cara. Mesmo que o modelo de negócios torne viável não ter que se preocupar com a RAM de forma alguma, eu gostaria de manter os custos baixos sempre que possível.
Para colocar em perspectiva, gostaria de armazenar, digamos, no máximo 100 estatísticas a cada minuto para cada servidor monitorado. Você pode ver que o número de linhas aumenta rapidamente com mil servidores (100 × 1.000 × 1.044 × 365 = 38.106.000.000). O orçamento anual para mil servidores é de US$ 120.000 (muita RAM), mas o objetivo é manter os custos baixos.
Refinando a pergunta
Eu realmente aprecio as respostas que foram fornecidas até agora, então vou ser um pouco mais específico para abordar minhas preocupações de forma mais específica.
As respostas até agora me levaram a pensar que preciso simplesmente fazer alguns benchmarks por conta própria e ver o que acontece (desenvolvimento para você!). Portanto, neste ponto, o "problema" que enfrento é que o uso de RAM será inevitavelmente de centenas de gigabytes.
Questão 1 ) Portanto, se eu decidir colocar uma quantidade incrivelmente grande de dados na RAM, eles precisarão ser distribuídos por vários servidores. Já faço isso com o NDBCluster, mas o NDBCluster usa quase 3 vezes mais RAM para armazenar os dados idênticos (15 bytes versus cerca de 48 bytes). Qual é o método aceito para armazenar tantos dados na RAM em um cluster de servidores? Devo implementar algum sistema de nível de aplicativo para integração com vários servidores MyISAM?
Questão 2 ) O MyISAM é a escolha certa em Mecanismos de Banco de Dados? Eu testei um pouco com o InnoDB e parecia usar muito mais RAM do que o MyISAM para lidar com o índice. E as soluções não MySQL?
Questão 3 ) Vale a pena armazenar o índice em um disco? Nesse ponto, eu nem devo criar um índice se ele não estiver na RAM de qualquer maneira (duvido seriamente).
Questão 4 ) Se eu seguir o caminho de não colocar os dados na RAM, que tipo de configuração de disco é recomendada para este projeto? Um RAID de SSDs?
Questão 5 ) Vale a pena não incluir a coluna de valor e resolução no índice? Quanto de desperdício de tempo de CPU estamos falando em assumir que o índice está no disco e não na RAM?
Muito obrigado por qualquer conselho, com certeza selecionarei uma resposta assim que essas perguntas forem respondidas (se possível)