[Banco de Dados] A base está extremamente gigante, e agora?

Persistência de dados é uma coisa bem difícil quando se trabalha de modelos SQL, pois você sempre tem que prever o que pode acontecer para que seu desenho tenha uma vida útil maior, mas o que fazer quando uma tabela cresce e cresce e continua crescendo, atacando diretamente a performance de todo seu ecossistema?

Claro que podemos escalar nosso banco, mas chega uma hora que haja dinheiro para gastar com isso (ainda mais que a grande maioria dos bancos relacionais, escalam verticalmente), podemos também usar técnicas bem conhecidas, como adicionar novos index para otimizar (mas calma, indexar tudo pode ser sentença de morte).

Uma outra solução é tirar um pouco da responsabilidade do banco e na camada da aplicação fazer esse processamento, por exemplo: Precisamos achar uma linha específica (sem indexação) no meio de milhares (milhões, bilhões, etc.), podemos levantar múltiplas threads e rodar em paralelo, capturando “pedaços” da tabela onde vai ser realizada a busca. Com um index definido fica bem mais fácil essa busca, pois vai existir um subset e dependendo da lógica de busca dentro set podemos otimizar data de criação, id sequenciais e etc, lhe dando um parâmetro para trabalhar com um pedaço menor de busca.

Também temos particionamento (acho que é a técnica mais utilizada nessas situações) que basicamente é ir criando esses “subsets” da tabela por número de linha (geralmente) e alocando-os juntos em memória (similar ao que acontece com indexão, porém teremos “outra tabela”), a grande diferença é que esse particionamento irá gerar uma key podendo dar uma luz de qual subset procurar (pensando que dividimos nossa tabela pela metade e indexamos ela, nossa busca será bem mais assertiva).

Agora chegamos no último nível, que é fazer um Sharding. Sharding é exatamente a mesma ideia de particionamento, porém você vai levantar outro banco (isso mesmo, cada banco irá ficar com uma parte dos dados). Claro que isso complica muito as coisas, pois as aplicações que acessam os bancos vão precisar saber qual banco acessar e dependendo da operação pode ser muito difícil caso precise envolver mais de um banco (por exemplo, uma transação). Por isso é melhor realizar esse tipo de estratégia com dados legados (que provavelmente só serão usados para leituras).

Em resumo, faça o máximo para evitar essas tabelas gigantes. Claro que sistemas críticos com anos de operação vão ter muita coisa, mas você que está começando seu lindo DER agora pense bem, hoje existem muitas features legais em bancos relacionais que permitem economizar um bocado de espaço em tabelas intermediárias ou outras coisas do tipo, por exemplo, lhe permitindo criar campos com arrays e até json. Abraços!