Esse método usa uma fórmula matemática (uma função hash) na chave de fragmentação para atribuir dados. Por exemplo, o sistema pode calcular o ID do usuário (mod 4) para atribuir um usuário a 1 dos 4 servidores.

Embora as funções de hash ajudem a distribuir os dados de maneira consistente, elas só garantem uma distribuição uniforme se a chave de fragmentação tiver alta cardinalidade e baixo desvio de frequência. Se você escolher uma chave de fragmentação com um valor comum, como um "Sobrenome" em que "Silva" aparece 1.000 vezes mais do que "Pyne", a função hash enviará todos os registros "Silva" para o mesmo fragmento. Isso cria um "shard quente" apesar do uso de uma fórmula matemática.

Adicionar novos servidores também é difícil com esse método porque a fórmula muda, o que geralmente exige que você "reparticione" ou mova seus dados pelo novo cluster de servidores.

Os dados são atribuídos com base em intervalos de valores. Por exemplo, você pode colocar os IDs de usuário de 1 a 1.000 no servidor A e de 1.001 a 2.000 no servidor B. Isso é muito intuitivo e ótimo para consultas que precisam ler uma sequência de dados (consultas de intervalo). A desvantagem são os "pontos críticos": se todos os seus novos usuários forem atribuídos ao servidor B, ele fará todo o trabalho enquanto o servidor A ficar ocioso.

Essa estratégia usa uma tabela de pesquisa (um diretório) que rastreia exatamente qual fragmento contém quais dados. Ela oferece mais flexibilidade porque você pode mover dados entre fragmentos sem mudar uma fórmula. No entanto, essa tabela de pesquisa se torna um gargalo: toda consulta precisa verificar o diretório primeiro, o que aumenta a latência. Se o diretório falhar, todo o banco de dados ficará inacessível.

O particionamento geográfico atribui dados a servidores específicos com base na localização física de um usuário. Por exemplo, os dados dos usuários na França são armazenados em servidores na UE, enquanto os usuários dos EUA estão em servidores na América do Norte. Isso reduz significativamente a latência (velocidade) para os usuários e ajuda as empresas a cumprir leis de residência de dados como o GDPR.

Às vezes chamado de particionamento funcional, isso envolve dividir os dados por recurso em vez de por linha. Por exemplo, você pode colocar todas as tabelas de "Perfil do usuário" no Servidor A e todas as tabelas de "Upload de fotos" no Servidor B. Embora isso organize os dados de maneira lógica, é funcionalmente semelhante a uma arquitetura de dados de microsserviços e não resolve o problema se um recurso específico (como o Fotos) crescer demais para um único servidor.

O fragmentação é um tipo específico de particionamento horizontal em que os dados são distribuídos em servidores completamente diferentes. Isso resolve os limites de capacidade de hardware (armazenamento) e os gargalos de capacidade de gravação, já que diferentes servidores podem processar gravações simultaneamente.

• Fragmentação manual: em um ambiente de fragmentação manual, o desenvolvedor ou administrador de banco de dados é responsável por definir as chaves de fragmentação, criar a infraestrutura para cada fragmento e escrever a lógica para rotear consultas. Isso oferece controle granular sobre o local exato dos dados. No entanto, ela exige muita manutenção. Se um fragmento ficar muito grande, você precisa "reparticionar" os dados manualmente, o que envolve mover milhões de linhas para novos servidores e tentar minimizar o tempo de inatividade do aplicativo.
• Fragmentação automática: a fragmentação automática, que geralmente é encontrada em bancos de dados NoSQL como o Bigtable ou em bancos de dados SQL distribuídos como o Spanner, lida com a distribuição de dados e tráfego automaticamente. O sistema monitora o tamanho dos dados e a carga em cada servidor. Se um fragmento específico se tornar um "ponto de acesso" ou crescer demais, o mecanismo de banco de dados vai dividir automaticamente o fragmento e mover os dados para um servidor menos congestionado. Isso reduz a carga operacional da sua equipe e ajuda a garantir um desempenho consistente à medida que seu aplicativo é escalonado.

O particionamento envolve dividir uma tabela grande em partes menores e mais gerenciáveis (como dividir uma tabela de registros por mês), mas mantendo-as na mesma instância de servidor. Isso resolve problemas de armazenamento, facilitando o arquivamento ou a exclusão de dados antigos sem afetar o restante da tabela. No entanto, isso não resolve problemas do servidor. Como todas as partições ainda residem em uma única máquina, elas continuam a compartilhar a mesma CPU e RAM, o que significa que o particionamento não ajuda se o servidor atingir seus limites de desempenho.

A replicação é o processo de copiar todo o banco de dados para vários servidores. Essa pode ser uma boa opção para disponibilidade de leitura. Se um servidor falhar, outro pode assumir. No entanto, ela não ajuda no escalonamento de gravação, porque cada dado gravado precisa ser copiado para cada réplica, limitando a velocidade de gravação à capacidade de uma única máquina.

Além disso, a maioria dos modelos de replicação permite apenas um "gravador" (o nó principal) por vez. Se você tentar permitir que vários servidores aceitem gravações simultaneamente, corre o risco de conflitos de gravação, em que dois servidores tentam atualizar o mesmo registro com informações diferentes. Resolver esses conflitos é tecnicamente difícil e pode levar à perda ou inconsistência de dados se não for tratado por um sistema distribuído sofisticado.

Um banco de dados distribuído, como o Spanner, oferece os benefícios do particionamento sem a sobrecarga manual. Esses sistemas são projetados para funcionar em um cluster de máquinas desde o início. Eles lidam automaticamente com a distribuição, o rebalanceamento e a replicação de dados de maneira transparente. Alguns desses sistemas têm vários gravadores e lidam automaticamente com conflitos de gravação. Isso permite que você faça o escalonamento horizontal sem perder a consistência de um banco de dados relacional tradicional.