Projetando um armazenamento de objeto para objetos ~10B e usando mySQL para armazenar metadados. Sabemos que precisamos fragmentar e estamos procurando heurísticas gerais para dimensionar. Agradeceria dicas e ouviria sobre os cálculos no verso do envelope que todos vocês usaram
A fragmentação de itens individuais não é muito difícil - você só precisa de uma camada para descobrir a qual máquina ir para obter o item.
A fragmentação de algo que você precisa digitalizar ou pesquisar pode ser complicada. Você teria que entregar a consulta para cada máquina possível, deixá-los fazer a varredura/pesquisa, recuperar os resultados e juntá-los. GROUP BY, ORDER BY e LIMIT têm soluços. Você acaba fazendo algumas coisas tanto nas máquinas fragmentadas quanto no agregador central.
Você mencionou o armazenamento de linhas de metadados de 10B. Isso soa como alguns TB. Isso é facilmente manuseado em uma única máquina hoje em dia. A tabela pode ser PARTICIONADA, mas não se apresse até entender o que PARTITION faz e o que não dá a você.
Enquanto isso, seus "objetos" podem estar espalhados por dezenas, até milhares, de máquinas. Agora você tem mais dois problemas - saber onde procurar e lidar com travamentos.
Saber onde procurar - um hash é simples, até que você precise de mais fragmentos. Ter uma "pesquisa" adiciona outra coluna aos metadados e talvez um índice. Prefiro um compromisso entre os dois.
Crashes - com mil máquinas, você deve planejar uma morte a cada semana. Onde está o backup dele? Ou você tem outra cópia online? Duas cópias são seguras o suficiente? Todas as mil máquinas estão no mesmo local, correndo o risco de um único tsunami, tornado ou o que quer que seja?
Oh, voltando ao verso do envelope -- 10B INSERTs, uma linha de cada vez, podem levar um ano para terminar. Considere LOAD DATA e/ou INSERTs em lote.
INDEXANDO a tabela de metadados do monstro versus cache. Digamos que você tenha 5 índices diferentes de AUTO_INCREMENT ou CURRENT_TIMESTAMP - serão 5 acertos de disco aleatórios para atualizar os índices. Com terabytes de coisas, não há como armazená-las em cache de forma eficaz. Ops, agora você está limitado a cerca de 20 linhas inseridas por segundo, não importa como você faz os INSERTs. Com cerca de 30 milhões de segundos/ano, leva uma década para inserir suas 10 bilhões de linhas. Cuidado com a indexação! Adicionar striping de RAID ajuda em um pequeno fator. Os SSDs ($$$!) Ajudam talvez em um fator de talvez 5. (E seria difícil passar de 1 TB de SSDs em uma única máquina.)
Essas URLs informarão sobre a opção de ponteiro de dados nas tabelas MyISAM.
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_myisam_data_pointer_size
http://dev.mysql.com/doc/refman/5.0/en/full-table.html
De acordo com essas URLs, uma tabela MyISAM pode teoricamente ser
256 TB (para myisam_data_pointer_size = 6 (padrão)
65536 TB (para myisam_data_pointer_size = 7 (máximo)
O maior espaço de tabela InnoDB é de 64 TB.
A maior tabela individual pode ser de 64 TB se você habilitar innodb_file_per_table .
Este URL fornecerá mais números no maior BLOB, TEXT, VARCHAR, VARBINARY, LONGTEXT e BLOBs para InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-file-space.html
Clique aqui para Número Máximo de Colunas por Tabela
Quanto ao número máximo de tabelas por banco de dados, isso depende do sistema operacional. Se houver limite para o número de arquivos em uma pasta em um determinado sistema operacional (vamos chamá-lo de OSFILEMAX), MAXTABLES é OSFILEMAX dividido por 3 (.frm, .MYD, .MYI) para tabelas MyISAM, MAXTABLES é OSFILEMAX por 2 (. frm, .ibd) se estiver usando InnoDB com innodb_file_per_table ativado e MAXTABLES é OSFILEMAX (.frm) se estiver usando InnoDB com innodb_file_per_table desativado.
Espero que essas URLs e outras respostas fornecidas ajudem você !!!
Se você estiver interessado em sharding, confira http://www.scalebase.com - eles fornecem uma solução de sharding transparente e também podem recomendar a política de sharding correta para você