NoSQL: Particionando dados com SQL

Os profissionais que trabalham com programação e banco de dados atualmente se deparam com uma expressiva demanda para o armazenamento, gerenciamento, organização e manipulação de grandes quantidades de dados.

De fato, o termo Big Data vem sendo amplamente empregado para, dentre outros propósitos, indicar que é preciso estar preparado para lidar com um volume expressivo de dados em aplicações, sistemas, serviços e demais maneiras na qual um software é utilizado.

O armazenamento de grandes quantidades de dados geralmente é realizado pelos bancos relacionais, que suportam instruções e comandos da linguagem SQL, ou pelos bancos de dados que propõem novas ideias para tal armazenamento, agrupados pela sigla NoSQL.

Estes softwares possuem muitos recursos para lidar com diversas necessidades de armazenamento de dados e os profissionais responsáveis precisam saber como tratar a separação, distribuição e manipulação desses dados adequadamente.

Uma das principais funcionalidades para facilitar a organização e armazenamento de dados nos softwares SQL e NoSQL é o particionamento.

A correta especificação, configuração e manutenção de como os dados vão ser particionados é praticamente obrigatória quando há dados em abundância, pois neste caso há cuidados especiais além do armazenamento em arquivos, tabelas, objetos e coleções.

Com base neste contexto, este artigo apresenta quais são as principais funcionalidades de particionamento de dados nos bancos SQL, representados pelos produtos SQL Server, Oracle, MySQL e PostgreSQL, e também pelas alternativas NoSQL MongoDB e Cassandra.

O objetivo é apresentar ao leitor uma base para que ele se informe sobre como é a separação de dados nos principais bancos SQL e NoSQL e uma comparação relacionando características de particionamento desses produtos.

O leitor que acompanhar o conteúdo deste artigo se informará sobre as opções disponíveis para o particionamento de dados, até onde elas podem auxiliar o gerenciamento e a organização e quais são os benefícios que podem ser obtidos a partir da separação de dados em diferentes formas.

Particionamento de dados

Há um ditado popular muito útil para auxiliar a compreensão e a necessidade por trás do particionamento de dados: não coloque todos os seus ovos em uma única cesta. Por trás deste pedaço de sabedoria popular está a implicação que se todos os recursos estão alocados em apenas um local, há um grande risco deles serem perdidos por completo quando algo der errado.

Por outro lado, quando falamos de algoritmos, é comum empregar a técnica de dividir um problema grande em porções menores e proceder resolvendo-as uma de cada vez. Deste modo, quando finalizarmos a resolução de todas as instâncias menores, estaremos mais próximos da solução do problema original. No design de algoritmos esta técnica é conhecida como dividir e conquistar (divide and conquer).

No contexto de banco de dados, a combinação da técnica de dividir e conquistar com a atitude prudente de não alocar todos os recursos em um mesmo lugar leva à ideia de particionamento, que pode ser definida como a maneira de separar dados em diferentes objetos, como tabelas, tablespaces, partições, views ou outros.

O principal objetivo do particionamento é melhorar a organização e gerenciamento dos objetos que contêm os dados. Entretanto, recentemente esta prática vem sendo empregada para atender outro importante requisito: a possibilidade de escalar o banco, ou seja, suportar uma carga maior de acesso aos dados.

O particionamento também é um dos passos necessários para a implementação de soluções de alta disponibilidade e de processamento paralelo distribuído. Contudo, não se deve confundir particionamento de dados com a distribuição de dados entre servidores remotos, uma vez que estes são conceitos diferentes.

A implementação do particionamento deve ser realizada após a modelagem das entidades e relacionamentos do banco de dados. Durante o aprendizado dos princípios e fundamentos de modelagem é comum pensar que os dados de certas entidades devem ser organizados em objetos únicos e íntegros, uma vez que as técnicas de modelagem recomendam e enfatizam a classificação e o agrupamento de dados em entidades e, posteriormente, a criação de relacionamentos entre estas entidades.

Como consequência, nesta linha de raciocínio todos os detalhes não essenciais de implementação são abstraídos para que o modelo seja criado visando os aspectos práticos de armazenamento. Devido a isso, é muito provável que o resultado final seja um modelo onde todos os dados de uma determinada entidade estejam em uma única tabela quando o modelo físico for criado." [...] continue lendo...