Recursos para Banco de Dados Sharding e Partitioning

Question

Eu estou trabalhando com um esquema de banco de dados que está sendo executado em problemas de escalabilidade. Uma das tabelas no esquema cresceu para cerca de 10 milhões de linhas, e eu estou explorando sharding e particionamento de opções para permitir que este esquema de escala para conjuntos de dados muito maiores (por exemplo, 1 bilhão a 100 bilhões de linhas). Nossa aplicação também deve ser implementável em vários produtos de banco de dados, incluindo mas não limitado a Oracle, MS SQL Server e MySQL.

Este é um grande problema em geral, e eu gostaria de ler sobre o que opções estão disponíveis. Que recursos estão lá fora (livros, documentos, web sites) para sharding de banco de dados e particionamento estratégias?

Answer 1

Concordo com as outras respostas que você deve olhar para o seu esquema e índices antes de recorrer a fragmentação. 10 milhões de linhas está bem dentro das capacidades de qualquer um dos principais motores de banco de dados.

No entanto, se você quiser alguns recursos para aprender sobre o assunto de sharding tente estes:

• escalabilidade Melhores Práticas: Lições do eBay
• Randy Shoup sobre os Princípios de arquitectura do eBay - Vídeo e Apresentação
• alta escalabilidade do site
• Mr. Moore começa a remar no sharding (quando não fazê-lo)

Answer 2

Concordo com a observação de Mike Woodhouse que o tamanho atual não deve ser um problema - e o questionador concorda

.

A maioria dos DBMS comerciais fornecem suporte para tabelas fragmentadas em algum para ou de outra, sob um nome ou vários outros. Uma das questões-chave é se existe uma maneira sensata de dividir os dados em fragmentos. Uma maneira comum é fazê-lo com base em uma data, então todos os valores para, digamos, novembro de 2008 go em um fragmento, aqueles para Outubro de 2008 em outro, e assim por diante. Isto tem vantagens quando se trata tempo para remover dados antigos. Provavelmente, pode soltar o fragmento contendo dados a partir de Outubro de 2001 (sete anos de retenção de dados) sem afectar os outros fragmentos. Este tipo de fragmentação também pode ajudar com 'eliminação fragmento'; Se a consulta não pode claramente precisa ler os dados a partir de um determinado fragmento, então será lida esquerda, que pode dar-lhe uma vantagem de desempenho magnífico. (Por exemplo, se o otimizador sabe que a consulta é para uma data em outubro de 2008, ele irá ignorar todos os fragmentos, exceto aquele que contém os dados de outubro de 2008).

Existem outras técnicas de fragmentação - round robin distribui a carga em vários discos, mas significa que você não pode beneficiar da eliminação fragmento

.

Answer 3

10 milhões de linhas não é muito grande em termos de DBMS e eu estaria olhando primeiro para os meus indexação e de consulta planos antes de começar a planejar uma distribuição física dos dados com cacos ou partições, que não deve ser realmente necessário até que seus da tabela cultivado por um par de ordens de magnitude.

Todos os IMHO, é claro.

Answer 4

Na minha experiência, grandes mesas sempre bater-lhe no lado da I / O. A solução mais barata é a de adicionar índices com várias colunas suficientes para que todas as suas consultas podem obter os dados diretamente do índice, sem ter que carregar as páginas principais de dados. Isso faz com que suas inserções e atualizações mais I / O intensivo, mas esta pode ser OK. A próxima opção fácil no máximo a memória RAM em seu servidor. Não há razão para ter menos de 32GB se o seu banco de dados é grande. Mas no final você ainda vai encontrar-se I / O ligado, e você vai estar a olhar para a compra de um lote de discos rígidos e manter um esquema de particionamento complexo, que custa uma fortuna entre hardware e de trabalho. Espero que haja uma alternativa melhor estes dias - mover o banco de dados de girar discos rígidos para drives de estado sólido SLC - isto deve fazer a sua aleatório lê e escreve cem vezes mais rápido do que topo das unidades SAS de linha, e remova o I / O gargalo. SSDs começam em US $ 10 por gigabyte, então você está indo para gastar alguns grandes, mas ainda é muito mais barato do SANs, etc.