A importância dos bancos relacionais em cenários de Big Data


No mês de março tive o privilégio de escrever para o Editorial do MSDN Newsletter. Tenho acompanhado um pouco o cenário de Big Data e, com um pouco de conhecimento do mercado corporativo, decidi falar sobre onde o SQL Server se encaixa. Segue o texto na íntegra:

Neste mês anunciamos o lançamento oficial do SQL Server 2014, que estará disponível comercialmente em 1° de Abril.

Em meio a todo o alvoroço do Big Data, qual seria a importância de um banco de dados relacional como o SQL Server? Todos falam de Big Data como uma estratégia diferencial para as empresas. A fim de me manter atualizado sobre esse assunto, tenho estudado NoSQL e Hadoop para saber como empregar melhor essas tecnologias no nosso dia a dia. Estava curioso para saber se seriam essas as ferramentas que levariam à adoção do Big Data em massa. A realidade é que muitas empresas têm interesse, mas o caminho mais fácil parece ser através de um tradicional banco de dados relacional.

Ambientes corporativos possuem uma variedade de sistemas interligados. Desde sistemas usando tecnologia de ponta como também aplicações legadas que não podem ser desativadas. É arriscado jogar todos os sistemas no lixo e começar do zero um sistema unificado. Em raras ocasiões há justificativa para tamanho investimento. Portanto, a convivência de diferentes sistemas é um requisito primordial nas empresas. É nesse meio que o banco de dados relacional brilha. Além das características essenciais como auditoria, controle de acesso e backup de dados, ele possui o conceito de separação do modelo lógico e físico.

O modelo lógico de dados foi concebido por Codd (1970), no qual o banco de dados relacional é composto por tabelas e relacionamentos usando chaves primárias e estrangeiras. O desenvolvedor utiliza comandos padronizados SQL ou extensões específicas como T-SQL. O modelo físico de dados permite definir as estruturas de armazenamento, que a grosso modo seria a definição dos índices necessários para suportar as consultas.

A modelagem física, ao contrário da modelagem lógica, é um processo iterativo e pode ser ajustada no dia a dia. Um administrador de banco de dados pode extrair métricas de uso dos dados e otimizar a forma de armazenamento sem a necessidade de alterar o código da aplicação. SQL Server 2014 trará agora o diferencial da tecnologia "in-memory", capaz de melhorar o desempenho em 10 vezes e reduzir o espaço consumido pelos dados. Todas essas funcionalidades podem ser adotadas pelas aplicações baseadas no banco de dados SQL Server, bastando migrar para a nova versão e ajustando o modelo físico.

Ao observar essa evolução, minha conclusão é que as tecnologias possuem seu nicho específico e nenhuma delas canibaliza as demais. Big Data é o grande "hype", que estende as funções analíticas sobre os dados armazenados, gerando a demanda por novas tecnologias. Enquanto que o NoSQL especializa a tarefa de aquisição de dados em escala, o Hadoop evolui a ideia de "map-reduce" para aumentar a capacidade analítica. O banco de dados relacional continua firme em sua posição e mais vivo do que nunca como uma plataforma crítica de integração de sistemas.

Com o lançamento oficial do SQL Server 2014, estou trabalhando em uma surpresa. Fiquem ligado!

Comments (6)

  1. Flávio H. de Carvalho disse:

    Olá Fabrício, concordo com a visão de que deve sim existir um banco de dados relacional para favorecer alguns tipos de arquiteturas de sistemas e os legados insubstituíveis. Acho que a Microsoft já devia ter seu NoSQL nesta versão do SQL Server, caso não tenha!

  2. Oi Flavio! Há alguns anos começou o projeto Velocity, que seria a versão NoSQL do SQL Server. Ele utilizaria a interface REST para permitir as operações CRUD de dados. A arquitetura do produto era distribuída e permitia utilizar redundância e distribuição de carga. Hoje ele se tornou o AppFabric (migrou da família SQL) e se juntou ao Azure. Por isso, frequentemente quando as pessoas perguntam sobre a implementação Microsoft do NoSQL, apontamos para o caminho do Azure Tables.

    Esse é um assunto bem extenso e dá para ficar falando por um bom tempo! O que mais você acha que falta no SQL Server?

    Abraços, Fabricio

  3. Leonardo Pedroso Costa disse:

    Fabricio,

    hoje sinto falta do índice bitmap no sql server para tratamento de colunas com baixa cardinalidade. Tem alguma nesse sentido vindo por aí?

  4. Oi Leonardo,

    SQL Server utiliza bitmap filters, que são índices bitmap criados em tempo de execução, para realizar as operações de HASH da tabela Fato com as tabelas de Dimensão. Entretanto, não existe uma forma de armazenar essa informação em disco – o que seria o índice bitmap.

    A partir do SQL 2012 (e melhorado no SQL 2014), existe o novo recurso de ColumnStore. Esse recurso permite armazenar as tabelas de baixa cardinalidade com alta eficiência, usando uma combinação de dicionário, run-length-encoding e compactação. O truque é representar a informação em colunas ao invés de linhas, estratégia similar adotada no Sybase IQ por exemplo.

    Como nunca tivemos o recurso de bitmap index no SQL, não consigo comparar qual deles é melhor. Entretanto, acredito muito nessa tecnologia como uma alternativa. Tem um link que pode esclarecer melhor o funcionamento interno.

    rusanu.com/…/inside-the-sql-server-2012-columnstore-indexes

    Obrigado pela sua dúvida e mande outras perguntas se minha explicação não ficou clara.

    Abraços, Fabricio

  5. Leonardo Pedroso disse:

    Bacana Catae,

    nesse ponto: "Esse recurso permite armazenar as tabelas de baixa cardinalidade com alta eficiência" você já sanou minha dúvida.

    Vou analisar a utilidade dele em tabelas de produção cujos dados sofrem operações DML (versão 2014) e ver se em tabelas transientes o ganho é o mesmo que em tabelas de B.I.

    Abração, e muito obrigado.

  6. Otimo!! Mande feedback sobre a feature.

Skip to main content