Rascunho_Bancos de dados SQL Vs Bancos de dados NoSQL
Este capítulo é uma tradução adaptada do seguinte artigo:
Title: SQL Databases V. NoSQL Databases
Author Michael Stonebraker Massachusetts Institute of Technology
Segundo Micahel Stonebraker (2010), recentemente tem havido muita discussão sobre bancos de dados NoSQL. De fato existem no mínimo duas conferências no topic 2009, uma em cada costa. Aparentemente estas discussões vem de pessoas que propoem o seguinte:
Document-style store (onde o banco de dados no estilo de armazenamento de documentos consiste de uma coleção de de pares chave-valor (key-value). Exemplos nesta classe são os bancos de dados CouchDB e MongoDB chamados de sistemas de armazenamento de documentos.
Key-value: Armazenamento de registros Chave-valor consiste de pares chave-valor. normalmente são implementados por tabelas hash distribuídas e nós podemos chamar os valores obtidos nestes pares de chave-valor (key-values) armazenados. Exemplos nesta classe são os bancos de dados MemcacheDB e Dynamo.
Em ambos os casos normalmente denominamos estes tipos de bancos de dados como NoSQL. Existem duas possíveis razões para mudar de DBMSs (SGBDs tradicionais): desempenho e flexibilidade. O argumento da performance é algo como o seguinte. Eu inicio com mysql para meu armazenamento de dados necessário e com o tempo verifiquei uma perfomance adequada. Minhas opções foram:
a) fragmento meus dados atraves de varios sites e tenho maiores dificuldades de gerenciamento de dados distribuídos
b) abandono MYSQLs e pago uma licenças enterprise de bancos de dados SQL ou movo para algum outro SGBD não SQL.
O argumento da flexibilidade vem como o seguinte: meus dados não tem um esquema de modelo relacional rígido. Por isso, eu não poderia vincular a estrutura de um Banco de dados relacional e necessito de algo mais flexível.
Normalmente existem duas maneiras de melhorar o desempenho OLTP:
a) fornecer fragmentação automática por meio de um shared-nothing (arquitetura de computação distribuída, onde um nó é independente e auto-suficiente, e não existe um ponto único de falha no sistemas)
b) aumento de performance OLTP por servidor.
Neste casos o aumento da performance irá prover: no primeiro caso, a melhora é proporcionada pela escalabilidade com os nós sendo adicionados a um ambiente de computação; no segundo caso, uma melhora do desempenho de nós individuais.
Todos os DBMS SQL sérios - como o Greenplum, o Aster Data, o Vertica, o ParAccel e outros - escritos nos últimos 10 anos não forneceram escalabilidade compartilhada e qualquer novo esforço seria negligente se não o fizesse.
Portanto, esse componente de desempenho deve ser primordial ("table stake") para qualquer SGBD. Na minha opinião, ninguém deveria executar um DBMS que não forneça fragmentação (sharding) automática sobre nós computacionais.
Como resultado, esta característica sobrepõe às outras componentes; A saber, o desempenho OLTP de um único nó.
A sobrecarga associada aos bancos de dados OLTP nos sistemas tradicionais do SQL tem, portanto, pouco a ver com o SQL em sí, razão pela qual o "NoSQL" talvez seja um equívoco.
Em vez disso, a sobrecarga principal em um DBMS SQL OLTP (sistema gerenciador de banco de dados SQL do tipo OLTP) está na comunicação com o DBMS usando ODBC ou JDBC. Essencialmente, todos os aplicativos que são sensíveis ao desempenho usam uma interface de stored-procedure para executar a lógica do aplicativo dentro do DBMS e evitar a sobrecarga de paralisação da comunicação de ida e volta entre a aplicação e o SGBD.
A outra alternativa é executar o SGBD no mesmo espaço de endereçamento que o aplicativo, desativando assim qualquer pretensão de controle de acesso ou segurança. Tais DBMSs embutidos/incorporados são razoáveis em alguns ambientes, mas não para os OLTP convencionais, onde a segurança é certamente necessária.
Usando procedimentos armazenados ou incorporados/embutidos, o componente de trabalho útil terá uma porcentagem muito pequena do custo de transação total para os bancos de dados OLTP atuais, que normalmente cabem na memória principal. Em vez disso, um artigo de s. harizopoulos, et. al. de 2008, calcula que o tempo total de OLTP foi dividido quase igualmente entre os seguintes pontos:
Se você eliminar qualquer um dos componentes acima, você acelerará um DBMS em 25%.
Elimine três e sua aceleração é limitada por um fator de dois. Você deve se livrar de todos os quatro para executar um SGBD de forma muito mais rápida.
Embora os sistemas NoSQL tenham uma variedade de recursos diferentes, existem alguns temas comuns. Primeiro, muitos sistemas NoSQL gerenciam dados distribuídos em vários hosts e fornecem as os requisitos mínimos indicados acima. Obviamente, um sistema multi-hosts bem projetado, baseado em SQL ou em qualquer outra coisa, é muito mais escalável do que um sistema de host único.
Em segundo lugar, muitos sistemas NoSQL são baseados em disco e mantém um pool de buffers, bem como uma arquitetura multithreaded. Isso deixará intactas duas das quatro fontes de sobrecarga observadas acima. No que diz respeito às transações, geralmente há suporte para apenas transações de registro único e um sistema de réplica de consistência final, o que pressupõe que as transações são comutativas.
Efetivamente, o "padrão-ouro" das transações ACID é sacrificado pelo desempenho. No entanto, o Net-net3é que o desempenho de um único nó de um sistema NoSQL, baseado em disco, não-ACID, multithreaded é limitado por um fator modestamente mais rápido do que o mecanismo OLTP OLP do SQL. Em essência, as transações ACID são descartadas por um desempenho modesto, e esse aumento de desempenho não tem nada a ver com o SQL.
No entanto, é possível ter um bolo e comê-lo também. Para ir rápido, é preciso possuir uma interface de procedimentos armazenados (stored procedure) para um sistema em tempo de execução, que compila em uma linguagem de alto nível (por exemplo, SQL) em código de baixo nível. Além disso, um tem que se livrar de todas as quatro fontes gerais de overhead citadas acima.
O projeto de M. stonebraker, et. al., sob o título “the end of an architectural era”, de 2007 indicou claramente que isso é factível, e mostrou desempenho ardente em TPC-C. Aguardamos pacotes de código aberto, observando as versões comerciais de ideias semelhante. consequentemente esperamos por engines SQL de código aberto com alta velocidade num futuro próximo que oferecem fragmentação (sharding) automática. Além disso, elas continuarão a fornecer transações ACID juntamente com o aumento da produtividade do programador, menor manutenção e melhor independência de dados proporcionados pelo SQL. Assim, o alto desempenho não requer o descarte de ACID ou transações SQL.
Em resumo, o ofuscado desempenho depende da remoção da sobrecarga. Essa sobrecarga não tem nada a ver com SQL, mas gira em torno de implementações tradicionais de transações ACID, multithreading e gerenciamento de disco. Para ir muito mais rápido, é preciso remover todas as quatro fontes da sobrecarga discutidas acima. Isso é possível em um contexto SQL ou em algum outro contexto qualquer.
Table Stake = No negócio, os table stakes são o requisitos mínimos da entrada para um mercado ou um arranjo de negócio.
Comutativo: Que comuta; relativo a troca, uma lei de combinação referente a elementos de um conjunto e cujo resultado não se altera se trocam as posições dos elementos: a adição e a multiplicação são operações comutativas
Net-net: no âmbito dos negócios é um resultado final verdadeiro, depois obviamente das subtrações e subsídios.
Last updated
Was this helpful?