Seguros e robustos! Saiba por que os bancos SQL ainda são um dos mais utilizados

O SQL, Structured Query Language, traz uma linguagem de abstração para banco de dados relacionais, levando maior segurança e consistência de dados para o profissional que o utiliza.

Para avaliar a eficiência da linguagem, por exemplo, instituições que trabalham com dados críticos, como aeroportos e bancos, optam pelo SQL a fim de garantir que suas transações sejam seguras e que não comprometam os serviços providos.

No entanto, será que você conhece tudo o que o SQL disponibiliza? Como estar atento as novidades que o mercado apresenta a cada dia? Para responder essas e demais perguntas acerca do tema, entrevistamos Eduardo Thomas Koller, CTO e Co-founder da BossaBox e Dirceu Resende, Head de BI na Power Tuning. Confira!

1 - O SQL é uma das principais linguagens para banco de dados em ascensão (popularidade) nos dias de hoje, mesmo que tecnicamente não seja uma linguagem de programação especificamente. Como isso acontece e por que?

Eduardo - O SQL é uma linguagem antiga, desenvolvida em 1970. Apesar disso, com o crescente uso de bancos de dados estruturados (e sua maioria baseados em SQL), a linguagem foi se desenvolvendo extensamente de acordo com as necessidades que surgiam. Toda aplicação que tem algum tipo de persistência de dados necessita de uma maneira para guardar os mesmos, e com o aumento do surgimento e crescimento de produtos digitais, logicamente a necessidade de bancos de dados cresceu em conjunto. Além disso, o SQL é usado não só por programadores no momento de desenvolvimento de aplicações, mas também por profissionais de inteligência para extrair métricas de produto e negócio.

Dirceu - O SQL é um linguagem de banco de dados criada em 1974 e que até hoje, é utilizada por praticamente todos os SBGD's relacionais, e com extensões em SGBD's NoSQL para que eles permitam a utilização do SQL para consultas. É uma linguagem muito simples de se aprender e praticamente universal entre os diversos SGBD's, graça ao SQL ANSI (1986) e o ISO (1987), que procuram padronizar a linguagem entre os diversos SGBD's.

Embora muitos SGBD's utilizem extensões da linguagem SQL (T-SQL no SQL Server e PostgreSQL e PL/SQL no Oracle, por exemplo), onde existem funções diferentes entre os SGBD's ou que até nem existam no SQL ANSI, as principais instruções de DDL e DML são iguais, independente do banco de dados.

Isso dá uma flexibilidade muito grande para quem trabalha com essa linguagem, seja um desenvolvedor, analista de BI, cientista de dados, etc. Pois, a mesma query que se utiliza para extrair dados de um Oracle, pode-se extrair os de um SQL Server, caso a estrutura de tabelas/colunas seja a mesma. Isso desperta interesse dos profissionais em aprender a linguagem, pois ela é praticamente universal e, uma vez que se conhece o SQL, podem-se consultar dados de qualquer SGBD relacional sem precisar ter que estudar ou aprender tudo de novo, diferente de uma linguagem de programação, onde existe uma curva de aprendizado necessária bem maior entre uma linguagem e outra.

Até alguns anos atrás, apenas a área técnica de TI tinha o interesse e a necessidade de aprender SQL. Com o crescimento da área de dados, onde muitas pessoas da área de negócio (sem formação de TI) começam a querer consultar dados para analisá-los de forma mais ágil, a demanda por cursos e conteúdo sobre SQL tem crescido bastante, uma vez que a maioria dos dados atualmente é armazenada em bancos de dados relacionais e esses profissionais querem ler esses dados direto da fonte (ou de um ambiente de DW, também relacional).

2 - Apesar de o SQL possuir um padrão estrutural, entre os diversos SGBD existentes (Oracle, PostgreSQL, SQLite, Microsoft SQL Server, MySQL, etc), pequenas variações nos comandos podem ocorrer. Ou seja, no momento em que a organização ou a equipe optam por um banco de dados ou outro, o desenvolvedor/DBA precisará aprender as especificidades da linguagem SQL para o SGDB escolhido. Em sua opinião, quais os principais comandos SQL que todo desenvolvedor e/ou DBA (Database Administrator) precisa saber para se dar bem na área?

Eduardo - Acho que além das instruções principais como SELECT, INSERT, UPDATE, DELETE e as cláusulas como JOIN, GROUP BY, ORDER BY, etc, é possível realizar muito mais se exploradas as funções (AVG, COUNT, MIN, MAX, etc…) e salvar muito tempo se estudadas as procedures. O ideal é entender como usar tudo que o SQL disponibiliza em conjunto, e claro, sempre atento à performance. Para se dar bem na área, conhecer truques e padrões para otimização de performance é chave.

Dirceu - Criado pela IBM em 1974, o SQL possui uma padronização na sua linguagem criado pelo American National Standards Institute (ANSI) em 1986 e ISO em 1987, e possui várias atualizações em cima do padrão criado originalmente para adicionar novos recursos à linguagem padrão. Atualmente, estamos no dialeto SQL:2016, que adicionou suporte ao JSON, dentro de outras melhorias.

Embora tenha um padrão, muitos SGBD's utilizam suas próprias linguagens de consultas baseado no SQL, sendo consideradas extensões dessa linguagem, como é o caso do T-SQL no SQL Server e PostgreSQL e o PL/SQL no Oracle, por exemplo, onde existem funções diferentes entre os SGBD's ou que até nem existam no SQL ANSI.

Isso dá um poder muito grande aos SGBD’s, pois lhes permite adicionar diversos recursos que ainda não fazem parte do SQL ANSI, como a possibilidade de executar scripts C#, Java, Python e R dentro do próprio banco de dados, como é o caso do SQL Server, que abre um leque de infinitas possibilidades do ponto de vista da programação.

Para quem quer ser um administrador de banco de dados (DBA), esse profissional deve conhecer pelo menos o básico do DQL (Data Query Language = SELECT), mas focar nas atividades de alta disponibilidade, backup, replicação de dados, performance tuning, troubleshooting e automação de tarefas.

Embora muitos conceitos sejam compartilhados e parecidos entre os diversos SGBD’s, cada um possui uma forma diferente de implementar isso. E o DBA deve estar atento a como atuar em cada SGBD. Ou seja, um especialista em administração de Oracle, vai conhecer boa parte dos conceitos de administração de um SQL Server e aprender esse novo SGBD vai ser mais simples, levando em consideração a experiência e os conhecimentos já adquiridos, mas na prática ele não vai saber fazer nada no SQL Server caso ele não estude como esse SGBD funciona.

Para o DBA, os principais comandos que ele deve conhecer, são os comandos de DDL (Data Definition Language), como CREATE/ALTER/DROP de objetos, que podem ser databases, tabelas, procedures, views, etc, onde cada tipo de objeto possui parâmetros diferentes. Ele também deve conhecer bastante de DCL (Data Control Language), como GRANT/REVOKE/DENY.

Para desenvolvedores, eles precisam conhecer muito sobre DML (Data Manipulation Language), com comandos como INSERT/DELETE/UPDATE para manipular dados armazenados no banco, além de DQL (Data Query Language) para realizar consultas aos dados e criar relatórios no sistema. Também é importante conhecer o básico de DDL, para modelar corretamente as tabelas novas e existentes dos sistemas.

Para analistas de dados, eles basicamente necessitam de DQL para consultar dados e analisar em suas ferramentas de visualização.

3 - Por que dominar a linguagem SQL vem se tornando cada vez mais essencial para profissionais que trabalham com programação back-end e, principalmente, administração de banco de dados?

Eduardo - O padrão há um tempo atrás era todo time ter um profissional especialista em bancos de dados, mas isso vem mudando. A responsabilidade pela arquitetura e performance dos bancos de dados tem sido cada vez mais colocada nas mãos de desenvolvedores back-end (que têm muito contato com bancos de dados pela natureza do seu trabalho). Isso aconteceu devido à ascensão de serviços gerenciados de bancos de dados, em que a responsabilidade pela infraestrutura e disponibilidade dos mesmos é do provedor de serviço, tirando uma responsabilidade dos profissionais de infraestrutura e banco de dados.

Dirceu - Atualmente, o volume de dados coletados e armazenados nos sistemas só tende a crescer e ficar cada vez maior, muito em virtude da cultura Data-Driven, que tende a obter informações relevantes, insights e análises em cima de dados.

Machine Learning, Big Data, Mineração de dados e dentre outras áreas dentro da análise de dados tem entregado bons resultados ao extrair informações em cima de dados que aparentemente, não eram muito importantes ou não tinham muita relação, o que faz com que cada vez mais, as empresas queiram coletar a maior quantidade possível de dados de seus clientes, processos, vendas, etc.

Tudo isso aumenta a demanda e a necessidade por criar estratégias eficientes de armazenamento e consulta desses grandes volumes de dados, especialmente em relatórios, que costumam realizar diversos cruzamentos de dados e análises de informações históricas.

Uma consulta não otimizada que retornava rapidamente os dados em uma tabela de 30 mil registros, pode não entregar mais o desempenho aceitável pelo cliente quando o volume sobe para 30 milhões de registros, o que faz com que os profissionais que lidam com dados em bancos relacionais tenham que ser cada vez mais especialistas em SQL, para que eles consigam entregar uma boa performance, mesmo com esses volumes de dados maiores.

E tudo isso acaba recaindo sobre o banco de dados, onde os DBA’s e os desenvolvedores, especialmente os de back-end, que é onde as rotinas mais pesadas da empresa se encontram, acabam tendo que se especializar em otimização de consultas de banco de dados, garantindo a melhor performance possível, seja criando índices, alterando parâmetros do banco de dados, utilizando Query Hints, ou reescrevendo as consultas de uma forma mais otimizada, o que chamamos de Performance Tuning.

4 - O que faz com que o banco de dados seja ou não relacional é a forma a qual os dados são inseridos e organizados nele e, muitas vezes, a escolha de um banco com bases de dados relacionais é a melhor escolha para a maior parte das empresas. Sendo assim, quais são os motivos para se escolher a utilização de um banco NOSQL atualmente? Quais os prós e contras disso?

Eduardo - O principal motivo pelo qual bancos de dados estruturados baseados em SQL foram padrão por tanto tempo no mercado é porque até certo tempo atrás, espaço de armazenamento era caro. Bancos de dados relacionais (principalmente quando normalizados) evitam duplicidade de informação, então economizam espaço. Com a evolução da tecnologia e do hardware, espaço de armazenamento foi se tornando cada vez mais barato, e o volume de informação cresceu substancialmente. Dessa forma, bancos de dados não estruturados vieram à tona. As vantagens do NoSQL em relação ao SQL são específicas: não há necessidade de dados estruturados, o que torna mudanças nos modelos de dados mais fáceis; trabalhar com grandes volumes de dados é mais fácil; a arquitetura da infraestrutura dos bancos de dados NoSQL tende a ser distribuída, exatamente para facilitar o trabalho com um grande volume de dados; entre outras. Porém, deve-se ficar atento, pois essa mudança de paradigma pode causar principalmente ineficiência e inconsistência de dados se os devidos cuidados não forem tomados.

Dirceu - Embora muitas pessoas achem que o NoSQL veio para substituir os bancos relacionais, em qualquer cenário, a verdade é que o NoSQL vem para atender alguns cenários específicos onde o banco relacional acaba sendo muito burocrático, quando não precisaria ser.

Antes de mais nada, o NoSQL só é recomendado para projetos onde não é necessário que ele tenha suporte às propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade), ou seja, se não precisa ter suporte à transações e garantir a integridade dos dados, um banco NoSQL pode ser considerado.

Os bancos NoSQL possuem basicamente 4 tipos de forma de armazenamento de dados: Documentos (MongoDB e Couchbase), chave/valor (Riak, Amazon’s Dynamo), grafos (Neo4J) e colunas (HBase, Cassandra), conseguindo atender algumas necessidades de forma mais simples, nativa e performática que utilizando tabelas e colunas no modo relacional.

As maiores vantagens de um banco NoSQL, é a sua facilidade em escalar horizontalmente (um banco pode estar em vários servidores diferentes, processando dados em paralelo) ao invés de escalar verticalmente (um único servidor processa os dados).

Essa arquitetura faz com que o hardware desses servidores, trabalhando de forma horizontal, possa ser bem mais baratos que o hardware de um banco relacional, que precisa ser bem potente em caso de grandes volumes de dados, pois geralmente um cluster não trabalha de forma paralela e independente, sem precisar aguardar commit de transações entre os nós, como os bancos NoSQL. Ou seja, desempenho de leitura e, especialmente escrita, é um bom motivo para optar por bancos NoSQL.

Outro grande benefício é a utilização nativa de estruturas JSON em sua forma binária e indexada automaticamente, facilitando bastante a utilização desse tipo de banco em sistemas que já trabalham com dados em JSON, pois eles gravam e fazem a leitura direto no formato JSON, enquanto nos bancos relacionais, é necessário tratar o JSON na leitura e na escrita, além do fato da indexação precisar ser feita manualmente, de acordo com determinados campos.

O terceiro grande benefício de bancos NoSQL, é em relação a liberdade de modelagem dos dados. Enquanto nos bancos relacionais a estrutura é rígida e definida antes da inserção dos dados, precisando ser modificada em caso de alterações na estrutura dos dados, nos bancos NoSQL o documento que é armazenado (JSON), então qualquer mudança de estrutura não implica em alterar nada no armazenamento dos documentos. É totalmente transparente e rápido de implementar no sistema, não precisando fazer qualquer alteração no banco, mesmo que um documento armazenava 4 informações e agora vai precisar armazenar 40, por exemplo. E isso será tratado na leitura dos dados. Ou seja, bancos NoSQL são ótimos quando o schema e a estrutura dos dados mudam constantemente (o que não exclui a responsabilidade de haver uma modelagem dos dados, mesmo no NoSQL).

Entre os contras de bancos NoSQL, é que não existe padronização de consultas entre eles, ou seja, se você estudar bastante o MongoDB e quiser migrar para o Cassandra, terá que estudar a forma de consulta toda de novo, pois é totalmente diferente.

Além disso, a maioria dos bancos NoSQL não possui suporte a transações (ACID) e quando o tem, a performance e os recursos são piores que dos bancos relacionais.

Por ser uma tecnologia ainda recente, a quantidade de material de estudo ainda é pequena, quando comparada com material de bancos relacionais tradicionais, como SQL Server, Oracle e PostgreSQL.

Ao utilizar bancos NoSQL, a integridade dos dados deve ser persistida e validada na aplicação e não no banco de dados, o que pode aumentar a complexidade do desenvolvimento de sistemas (e a responsabilidade dos desenvolvedores).

Por não ter suporte ao ACID, os bancos NoSQL não possuem backup físico e consistente como nos bancos relacionais, e por isso, apenas é possível realizar dumps (não consistentes) e a garantia de disponibilidade dos dados está no fato dele estar distribuído em vários nós, mas não existe tanta preocupação com essa parte como nos bancos relacionais.

E por falar em segurança, os bancos relacionais possuem uma série de recursos de backup, criptografia, mascaramento de dados e proteções contra invasões e privacidade dos dados que ainda está bem à frente dos bancos NoSQL.

Bancos NoSQL não possuem relacionamento entre objetos e por isso, projetos de DW e BI costumam preferir utilizar bancos relacionais, embora bancos NoSQL costumam ser utilizados em projetos de Big Data, por conta do alto desempenho.

Muitas empresas acabam optando por utilizar bancos relacionais e não relacionais em conjunto, onde os bancos não-relacionais são utilizados no Front-end, pela facilidade de evolução de schema e performance, e esses dados passam a ser migrados para bancos relacionais e lidos no back-end, por conta de segurança, relacionamentos, etc.

5 - Muitos profissionais do mercado de TI estão receosos com o futuro, principalmente os DBAs, diante das mudanças e avanços tecnológicos que ocorreram nos últimos anos, tais como: Virtualização, Cloud, NoSQL, Big Data e até mesmo o polêmico "Oracle Autonomous Database". Nesse contexto, quais os desafios da linguagem SQL em meio às inovações tecnológicas do mercado de trabalho atualmente? Além disso, quais as perspectivas para o futuro desse tipo de linguagem de programação e dos profissionais DBA?

Eduardo - SQL é e, na minha opinião, ainda será por um bom tempo o padrão de mercado. Em relação à linguagem em si, acredito que SQL foi a base para a popularidade dos bancos de dados, e essa popularidade faz com que, inclusive, bancos NoSQL criem soluções para que SQL possa ser usado como uma abstração sobre os mesmos. Os profissionais DBA devem ficar atentos à mudanças e novidades, mas acredito que isso é importante para qualquer outro profissional no mundo da tecnologia.

Dirceu - O SQL é uma linguagem que existe desde 1974, mas vem sofrendo melhorias e modificações para suportar as novas tecnologias e necessidades do mercado. A sua última atualização foi o dialeto SQL:2016, que introduziu o suporte ao formato JSON, entre outras melhorias.

Os desafios do SQL é conseguir atender a todas essas tecnologias emergentes, especialmente na área de Analytics, Big Data e ciência de dados, provendo formas simples de entregar os dados requisitados de forma fácil, simples e performática.

Por conta disso, acredito que o SQL ainda será muito utilizado, uma vez que a maioria das informações corporativas ainda estão armazenadas em sistemas relacionais (que usam SQL) e acredito que não há perspectiva disso mudar num futuro próximo, o que reforça a tese que o SQL ainda tem vários anos pela frente, e, aprender essa linguagem é essencial e um conhecimento que deve permanecer em alta por mais vários anos.

Um claro exemplo de que os SGBD’s estão se movimentando quanto à necessidade de modernização e acompanhar o avanço tecnológico, é a criação do recurso de PolyBase, no SQL Server 2016 e melhorado no SQL Server 2019, que permite realizar a leitura de dados de diversas fontes (estruturadas e não estruturadas), como Oracle, Azure Blob Storage, Hadoop e MongoDB, utilizando consultas SQL como se fossem tabelas de um banco, de forma totalmente transparente.

Outro exemplo disso é o recurso Big Data Clusters, que transforma o SQL Server 2019 em um ambiente de Big Data integrado ao banco de dados, permitindo consumir dados estruturados e não estruturados utilizando Spark e Kafka, armazenar com HDFS, e treinar modelos com SparkML ou Azure Machine Learning Services, tudo dentro do próprio SGBD.

Sobre a carreira de DBA, os principais players de mercado estão buscando cada vez mais reduzir o trabalho repetitivo dos DBA’s e automatizar tarefas, como é o caso do Automatic Tuning, do SQL Server e o Oracle Autonomous Database, que acabam prometendo demais pelo que de fato, entregam.

Acredito que dentro de alguns anos, especialmente com o crescimento de bancos de dados rodando na nuvem, algumas atividades do dia a dia do DBA devem ser eliminadas, como criação de rotinas de backup, demandas de alta disponibilidade, manutenção de discos e demais atividades que são mais da área de infraestrutura.

No futuro, o DBA deverá ficar mais perto do negócio, pensando mais na empresa do que somente na tecnologia. E suas atividades serão mais voltadas para segurança e privacidade dos dados, Performance Tuning, planejamento de capacidade, automatização, DevOps, arquitetura de soluções, modelagem de dados e outras demandas que são mais “mentais” do que “braçais”.

Se você chegou até aqui, aproveite para ler também >

• CMDB: saiba como transformar dados em resultados

• Cloud 2.0: conheça a nova geração da nuvem

• Wi-Fi 6: o que esperar da nova geração sem fio

Live University – Ebusiness

Se deseja aprimorar seus conhecimentos na área de TI e acompanhar as tendências, você está no lugar certo! Conheça os cursos de Ebusiness, a escola de Tecnologia da Informação da Live University. Na LiveU você encontra workshops, eventos, MBA, pós-graduação e muito mais. Clique aqui e comece já!