Há dois anos e meio, dois jovens pesquisadores da IBM lançaram sobre os bancos de dados uma nova linguagem, concebida em termos relacionais, dedicada à proposta de que os dados podem ser manipulados de forma declarativa e fácil. Nos anos que se seguiram à publicação de Don Chamberlin e Ramond Boyce SEQUEL: uma linguagem de consulta estruturada em inglês O modelo relacional e o SQL foram ampliados e adaptados a um número significativo de tecnologias: OLTP, OLAP, bancos de dados de objetos, bancos de dados objeto-relacionais e até mesmo NoSQL. O SQL inspirou o design da linguagem de consulta para bancos de dados não relacionais: SQL para bancos de dados de objetos, SQL para objeto-relacional, SQL para XML, SQL para espacial, SQL para pesquisa, SQL para JSON, SQL para séries temporais, SQL para fluxos e assim por diante. Toda ferramenta de BI interage com os dados usando uma variedade de SQL. De fato, o SQL é o mais linguagem de quarta geração bem-sucedida.
"O SQL é um dispositivo cujo mistério só é superado por seu poder." Lukas Eder
Como Don disse recentemente, o SQL foi baseado no fundamento de álgebra relacional com o objetivo de facilitar o processo, fornecendo uma linguagem de consulta semelhante ao inglês com os seguintes objetivos:
- Uma linguagem e um processamento declarativos (em vez de processuais)
- Tornar a linguagem composable para ajudar a escrever consultas complexas com facilidade
- Trabalhar com o modelo relacional desenvolvido por Edger F Codd.
Enquanto o Big Data tentava complementar e substituir os sistemas relacionais para armazenamento de dados, eles tentavam falar a mesma língua: SQL. Hive, Impala, drill e BigSQL falam uma linguagem inspirada em SQL, otimizam e executam de forma semelhante à execução MPP do SQL. Eles também estão adicionando novos recursos de SQL regularmente. Tudo isso em todos os tipos de armazenamento de dados e modelos que você imaginar. A separação dos formatos de armazenamento de dados, do modelo de dados e do processamento de consultas no SQL gerou benefícios significativos. Nos quarenta e cinco anos desde que o SQL foi introduzido, muitos bancos de dados surgiram e desapareceram; muitos processamentos de dados surgiram e desapareceram. Alguns integrantes do movimento NoSQL insinuaram, mesmo que inadvertidamente, a morte do SQL e dos bancos de dados SQL. O campo do SQL levou isso na esportiva e Don Chamberlin disse recentemente: "Quando um idioma é tão bem reconhecido que outros idiomas começam a se definir como não sendo aquele, ele deve estar indo muito bem."
Os bancos de dados, por outro lado, simplesmente adotaram o No-SQL. Embora a definição atual seja "Not Only SQL" (Não somente SQL), as abordagens originais eram ficar sem SQL e tentar linguagens e estruturas alternativas, como map-reduce. Uma década depois, todos os bancos de dados NoSQL populares têm uma variação do SQL: N1QL no Couchbase, CQL no Cassandra, ElasticSearch SQL no Elastic. Você diz: "O MongoDB não tem SQL". Eu digo: "Aperte os olhos! Você verá uma implementação SQL muito simplista." Ao usar um design simplista, um tanto processual e ad-hoc no MongoDB, as consultas perdem a capacidade de composição, as otimizações e muitas das inovações feitas com o SQL.
Embora o modelo relacional tenha sido muito bem-sucedido, os bancos de dados suportam uma variedade de modelos de dados: JSON, gráfico, XML, série temporal, espacial, coluna ampla, colunar, documento e muito mais. A maioria desses bancos de dados, se não todos, tem sua versão de SQL. N1QL é SQL para JSON; SQL/XML, SQL do InfluxDB, SQL/Spatial, CQL no Cassandra etc. Até mesmo os bancos de dados NoSQL implementaram linguagens de consulta inspiradas em SQL e SQL. Até mesmo no novo e descolado mundo da "ciência de dados", Habilidades em SQL são altamente recomendadas. Lukas Eder defende esse ponto em suas palestras imperdíveis. Veja os links para suas palestras na seção de referência abaixo.
Atualmente, há mais projetos SQL em bancos de dados NOSQL do que em bancos de dados SQL.
| Modelos/formatos de dados | Implementação de SQL |
| JSON | Couchbase N1QL: SQL para JSON |
| Coluna larga | Cassandra CQL |
| Hadoop/Big Data | Hive, Impala, Drill, BigSQL |
| Série temporal | Influxdb |
| Gráfico | Banco de dados SQL Graph, Oracle Graph |
| Banco de dados NoSQL | Apache Phoenix |
| Espacial | Oracle Spatial (inglês) |
| Pesquisa | Elastic SQL |
POR QUE A SQL É TÃO BEM-SUCEDIDA?
- Declarativo: Você declara a saída e os mecanismos de consulta descobrem a maneira ideal de executar a consulta. O otimizador, especialmente o otimizador baseado em custo, inventou Pat Selinger, et al em 1979, ajudou a melhorar continuamente o desempenho. Isso estabeleceu um alto padrão para todos os novos participantes. A artigo recente sobre o Apache Hive é um exemplo da complexidade e da sofisticação envolvidas.
- O SQL era usado não apenas para "consultar", mas também para atualizar os dados e fazer transações. Procedimentos armazenados e UDFs ampliaram o alcance combinando a linguagem procedural com o SQL declarativo.
- O SQL tem sido maleável. Ele foi padronizado muitas vezes, cada vez adicionando um livro cheio de recursos, uma loja cheia de sintaxes e um dicionário cheio de palavras-chave. Com certeza, nem todo SQL é igual. Até mesmo as implementações tradicionais de SQL em RDBMS não são exatamente compatíveis, a menos que você tenha o cuidado de escrever seu SQL para ser compatível. Apesar de tudo isso, o espírito original do SQL permaneceu. Um exemplo de SQL que se presta à evolução é SQL++. Don Chamberlin e Prof. Mike Carey discutir a necessidade de oferecer suporte a modelos de dados complexostornando os dados em JSON facilmente acessíveis a usuários e desenvolvedores. O livro de Don SQL++ para usuários de SQL: Um tutorial ensina a você os desenvolvimentos recentes do SQL++, linguagem projetada para processamento de dados no modelo de dados JSON flexível, mas de forma compatível com SQL.
- O SQL, assim como o idioma inglês do qual foi emprestado, está aberto a novas ideias e extensões para novos tipos de dados, métodos de acesso e casos de uso.
- A independência do SQL em relação à representação de dados permitiu que ele fosse usado em dados não relacionais: CSV, JSON e todos os formatos de big data. Algumas pessoas confundem a rigidez da representação do modelo relacional com a rigidez do SQL. Na verdade, em um determinado esquema, o SQL permite selecionar-juntar-grupar-agregar-projetar qualquer um dos formatos de dados.
Avaliação do suporte a SQL:
Agora que o SQL está em toda parte, você precisa fazer a devida diligência quanto ao nível de suporte.
- Descubra o características da carga de trabalho e o objetivo de cada carga de trabalho. Por exemplo, aplicativos interativos ou análises interativas ou análises em lote ou carga de trabalho de BI, etc.
- As declarações apoiadas refletem os recursos operacionais.
- Recursos de linguagem em termos de expressões (escalar, agregada, booleana), junções (interna, esquerda/direita/externa completa), subconsultas, tabelas derivadas, classificação e paginação (LIMIT/OFFSET).
- Indexação: O SQL sem os índices corretos é apenas um protótipo de máquina de Turing.
- Otimizador: A reescrita de consultas, a escolha do caminho de acesso correto e a criação do caminho ideal de execução de consultas é o que torna o SQL uma 4GL bem-sucedida. Alguns têm um otimizador baseado em regras, outros têm um otimizador baseado em custos e outros têm ambos. É fundamental avaliar a qualidade do otimizador. Os benchmarks típicos (TPC-C, TPC-DS, YCSB, YCSB-JSON) não o ajudarão aqui.
- Como diz o ditado: "Há três coisas importantes nos bancos de dados: desempenho, desempenho e desempenho". É importante medir o desempenho de sua carga de trabalho. YCSB e a extensão YCSB-JSON facilitará essa avaliação.
- SDKs: SDKs avançados e suporte a idiomas aceleram seu desenvolvimento.
- Suporte de ferramentas de BI: Para a análise de grandes volumes de dados, é importante o suporte das ferramentas de BI, geralmente por meio de drivers de conectividade de banco de dados padrão.
Gerald Sangudi, o criador do N1QL, comentou certa vez que o SQL é bem-sucedido porque representa as operações fundamentais do processamento de dados. O SQL suporta um rico conjunto de operações select-join-nest-unnest-group-aggregate-having-window-order-paginate-set-ops. É assim que nós (ou as máquinas) pensamos ao especificar as operações de dados? Embora ainda não se saiba, outras linguagens, como python e java, estão adicionando operadores para essas operações em dados. Talvez outras sigam o exemplo. O SQL foi aonde o modelo relacional não foi. Não é exagero dizer isso:
O SQL está morto. Vida longa ao SQL.
Referências:
- SQL++ para usuários de SQL: Um tutorial
- Lukas Eder - 2000 linhas de Java? Ou 50 linhas de SQL? A escolha é sua!
- Dez truques de SQL que você não imaginava que fossem possíveis
- Como os bancos de dados SQL modernos criam algoritmos com os quais você nunca teria sonhado por Lukas Eder
- Histórico do SQL
- Eugene Wigner: A eficácia irracional da matemática nas ciências naturais
- Alon Halevy, Peter Norvig e Fernando Pereira: The Unreasonable Effectiveness of Data (A eficácia irracional dos dados)
- Diferença entre 3GL e 4GL
