A interpretação educada de "NoSQL" tornou-se
Not Only SQL . Se você tiver dados que são realmente relacionais, ou se sua funcionalidade depende de coisas como junções e ACIDity, você deve armazenar esses dados de maneira relacional. Neste post, explicarei como uso o MySQL junto com dois Armazenamentos de dados NoSQL. O armazenamento de dados moderno e em escala da Web trata de entender como escolher a(s) melhor(es) ferramenta(s) para o(s) trabalho(s). Dito isso, o NoSQL é realmente uma reação ao fato de que o método relacional e o modo de pensar foram aplicados a problemas nos quais não é realmente um ajuste muito bom (tipicamente tabelas enormes com dezenas de milhões de linhas ou mais). Quando as tabelas ficam tão grandes, a "prática recomendada" típica do SQL é fragmentar manualmente os dados -- ou seja, colocando os registros de 1 a 10.000.000 na tabela A, 10.000.001 a 20.000.001 na tabela B e assim por diante. Então, normalmente na camada do modelo de aplicação, as pesquisas são realizadas de acordo com esse esquema. Isso é o que chamamos de
application-aware dimensionamento. É demorado e propenso a erros, mas para escalar algo enquanto mantém o MySQL para o armazenamento de tabelas longas, tornou-se um MO mais ou menos padrão. NoSQL representa, para mim, o application-unaware alternativo. Valor-chave
Quando um protótipo do MySQL começou a ficar grande demais para seu próprio bem, eu pessoalmente movi o máximo de dados possível para o Membase extremamente rápido , que supera o Memcached e adiciona persistência. O Membase é um armazenamento de valor-chave distribuído que escala mais ou menos linearmente (a Zynga o usa para lidar com meio milhão de operações por segundo, por exemplo) adicionando mais servidores de commodity em um cluster. Portanto, é uma ótima adequado para a era da nuvem do Amazon EC2 , Joyent , etc
É bem conhecido que os armazenamentos de valores-chave distribuídos são a melhor maneira de obter uma escala linear enorme. A fraqueza do valor-chave é a capacidade de consulta e indexação. Mas mesmo no mundo relacional, a melhor prática para escalabilidade é descarregar o máximo de esforço possível nos servidores de aplicativos, fazendo junções na memória em servidores de aplicativos comuns em vez de pedir ao cluster RDB central para lidar com toda essa lógica. Como a
simple select mais application logic são realmente a melhor maneira de alcançar escala massiva mesmo em MySQL, a transição para algo como Membase (ou seus concorrentes como Riak
) não é muito ruim. Lojas de documentos
Às vezes - embora eu argumente com menos frequência do que muitos pensam - o design de um aplicativo requer inerentemente índices secundários, capacidade de consulta de intervalo, etc. A abordagem NoSQL para isso é por meio de um
document store como MongoDB
. Assim como o Membase, o Mongo é muito bom em algumas áreas onde os bancos de dados relacionais são particularmente fracos, como application-unaware dimensionamento, auto-sharding , e maintaining flat response times even as dataset size balloons . É significativamente mais lento que o Membase e um pouco mais complicado de fazer escala horizontal pura, mas o benefício é que é altamente consultável. Você pode consultar parâmetros e intervalos em tempo real ou pode usar Mapear/Reduzir para realizar operações em lote complexas em conjuntos de dados realmente enormes. No mesmo projeto que mencionei acima, que usa o Membase para fornecer toneladas de dados de jogadores ao vivo, usamos o MongoDB para armazenar dados analíticos/métricos, que é realmente onde o MongoDB brilha.
Por que manter as coisas em SQL
Mencionei brevemente o fato de que informações 'verdadeiramente relacionais' devem permanecer em bancos de dados relacionais. Como o comentarista Dan K. aponta, perdi a parte em que discuto as desvantagens de deixar o RDBMS, ou pelo menos deixá-lo completamente.
Primeiro, há o próprio SQL. SQL é bem conhecido e tem sido um padrão da indústria por um longo tempo. Alguns bancos de dados "NoSQL", como o App Engine do Google O Datastore (criado no Big Table) implementa sua própria linguagem semelhante a SQL (o Google é chamado, graciosamente, de GQL para
Google Query Language ). O MongoDB adota uma nova abordagem para o problema de consulta com seus deliciosos objetos de consulta JSON
. Ainda assim, o próprio SQL é uma ferramenta poderosa para obter informações dos dados, o que geralmente é o ponto principal dos bancos de dados. O motivo mais importante para permanecer com o RDBMS é ACID , ou
Atomicity, Consistency, Isolation, Durability . Não vou refazer o estado do Acid-NoSQL, pois é bem abordado em este post
em SO. Basta dizer que há uma razão racional RDBMS da Oracle
tem um mercado tão grande que não vai a lugar nenhum:alguns dados precisam de conformidade pura com ACID . Se os seus dados tiverem (e se isso acontecer, você provavelmente está bem ciente desse fato), então o seu banco de dados também. Mantenha esse pH
baixo! Editar: Confira a postagem de Aaronaught aqui. Ele representa a perspectiva business-to-business muito melhor do que eu poderia, em parte porque passei toda a minha carreira no espaço do consumidor.
