Introdução ao NoSQL

maio 19th, 2010 | by suissa | nosql, sql

mai
19

O termo NoSQL foi usado pela primeira vez em 1998 como o nome de um banco de dados relacional de código aberto que não possuía um interface SQL. Seu autor, Carlo Strozzi, alega que o movimento NoSQL “é completamente distinto do modelo relacional e portanto deveria ser mais apropriadamente chamado “NoREL” ou algo que produzisse o mesmo efeito”. Porém o termo só voltou a ser assunto em 2009 por um funcionário do Rackspace, Eric Evans, quando Johan Oskarsson da Last.fm queria organizar um evento para discutir bancos de dados open source distribuídos.

NoSQL são diferentes sistemas de armazenamento que vieram para suprir necessidades que os bancos de dados tradicionais(Relacionais) são ineficazes. Muitas dessas bases apresentam características muito interessantes como alta performance, escalabilidade, replicação, suporte à dados estruturados e sub colunas.

O NoSQL surgiu da necessidade de uma performance superior e de uma alta escalabilidade. Os atuais bancos de dados relacionais são muito restritos a isso, sendo necessário a distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco um servidor precisa. O NoSQL tem uma grande facilidade na distribuição horizontal, ou seja, mais dados, mais servidores, não necessariamente de alta performance. Um grande utilizador desse conceito é o google, que usa computadores de pequeno e médio porte, para a distribuição dos dados, essa forma de utilização e muito mais eficiente e econômica. Alem disso, os bancos de dados NoSQL são muito tolerantes a erros.

No caso dos bancos NoSQL toda a a informação necessária estará agrupada no mesmo registro, ou seja, em vez de você ter o relacionamento entre várias tabelas para formar uma informação ela estará em sua totalidade no mesmo registro.

Os bancos NoSQL são subdivididos pelo seu núcleo, ou seja, como ele trabalha com os dados. Que são: Wide Column Store/Column Families, Document Store, Key Value/Tuple Store, Eventually Consistent Key Value Store, Graph Databases, Object Databases, Grid Database Solutions, XML Databases. Lista retirada de http://nosql-database.org/

Key/Value Store

Esse é o tipo de banco de dados NoSQL mais simples o conceito dele é uma chave e um valor para essa chave, mas ele é o que aguenta mais carga de dados. Esses tipos de bancos de dados, são o que tem a maior escalabilidade.

Wide Columns Store

Fortemente inspirados pelo BigTable do google eles suportam várias linhas e colunas, alem disso ele permite subcolunas. Alem do BigTable do google outros que usam essa tecnologia são:

HBase(Apache)
HiperTable
Cassandra(Apache)

Document Store

Baseado em documentos XML ou JSON, podem ser localizados pelo seu id unico ou por qualquer registro que tenha no documento.

Graph Store

Com uma complexibilidade maior esses bancos de dados guardam objetos e não registros como os outros tipos de NoSQL. A busca destes itens são feitas pela navegação destes objetos.

Column Oriented Store

Esses são bancos de dados relacionais, porem eles tem caracteristicas do NoSQL a principal diferença deles é que os dados são armazenados em colunas, ajudando na escalabilidade.

Vertica
MonetDB
LucidDB
Infobright
Ingres/Vectorwise

Como apresentado no gráfico, os key-value aguentam maior quantidade de registros, enquanto os grafos são mais complexos, a vantagem disso é bla bla bla.

Em um projeto, não necessariamente você precisa usar só um banco de dados nosql, você pode usar ele com qualquer outro banco de dados. Os bancos nosql são indicados para grandes cargas de dados, exigência de velocidade na consulta e escrita em grandes volumes de dados. Ainda segundo o gráfico 90% dos sites atualmente podem usar sem problemas algum os bancos de dados tradicionais, pois o ganho de performance não seria tão siguinificativo, para os 10% restantes é aconselhavel o uso do NoSQL.

A idéia que o conceito NOSQL nos passa é que ele não pode ser generalizado como a resposta de todos seus problemas, mas sim para problemas específicos.

Banco de dados Relacionais

O que é: Baseia-se em que todos os dados estão guardados em tabelas, pelo conceito de entidade e relacionamento. Os dados são separados de forma única tentando diminuir ao máximo a redundância. Pois a informação é criada pelo conjunto dos dados, onde são as relações entre as tabelas que fazem esse serviço.

Características: tabelas, schema definido, hierarquia, redundância mínima, entidade e relacionamento, formas normais, transações ACID(Atomicidade, Consistência, Isolamento, Durabilidade).

Necessidades: Sistemas locais, sistemas financeiros, sistemas corporativos, segurança da informação, consistência dos dados.

Marcas: DB2, Firebird, InterBase, Microsoft SQL Server, MySQL, Oracle, PostgreSQL

Cases: SAP, OpenERP, Previdência Social, Caixa, Itaú, Salesforce, Vale.

Banco de Dados NOSQL

O que é: Uma solução alternativa para os bancos de dados relacionais, possuem uma alta escalabilidade e desempenho

Características: registros, schema-free, tolerância a falha, escalabilidade, clusterização, mapreduce, sharding.

Necessidades: Sistemas em nuvem, análises sociais, alta escalabilidade, performance na consulta/escrita, replicação.

Cases: Twitter, Facebook, Digg, Amazon, LinkedIN, Google, Yahoo, The New York Times, Bit.ly.

1 Comment »

MongoDB vs CouchDB – Porque escolhi o MongoDB

maio 14th, 2010 | by alex | cassandra, couchdb, escalabilidade, mongodb, mysql, nosql

mai
14

Aposto todas as minhas fichinhas que todos que quiseram estudar NoSQL ficaram na duvida de qual dos dois usar, MongoDB ou CouchDB, mesmo que tenha ido para um cassandra ou qualquer outro NoSQL.

A duvida fica muito maior, porque são dois banco de dados muito semelhantes(orientado a documentos) e bastante usados. Vou colocar aqui o meu relato sobre o MongoDB e o CouchDB.

CouchDB

Quando vi as possibilidades do NoSQL, o primeiro banco de dados que vi foi o CouchDB, fiquei louco para começar a aprender ele, fazer alguns projetos e tudo mais, porem, dei uma olhada muito rápida no site deles, e não vi uma versão pra Windows. Falem o que quiserem, mas muita, muita gente e todo mundo sabe disso, faz tudo no Windows e se não tiver uma versão pra ele, não vão usar, vão continuar com o MySQL.

Demorei meses para voltar para o NoSQL, mas sempre com aquela vontade de realmente aprender um desses novos bancos de dados. Voltando aquele tesão inicial em aprender o NoSQL, vi muitos códigos usando o CouchDB, muita gente usando, muitas coisas pela internet sobre ele. Isso foi um ponto forte pra mim em relação a outros, quando vi que o CouchDB era incubado pela Apache, a balança pesou mais um pouquinho.

Já que o NoSQL é uma técnologia extremamente nova, eu queria pensar a longo prazo, várias vezes fiquei me perguntando as vantagens entre esses bancos de dados. Confesso que quando vi uma pesquisa falando sobre os bancos de dados que as pessoas mais tinham vontade de aprender, apontando o CouchDB como segundo, ele ganhou mais um ponto, em primeiro vinha o cassandra, porem ele ainda não tinha instalação pra windows. O PHP é muito forte, e um dos fatores principais é a grande comunidade e excelente documentação que eles possuem, levei isso em consideração na hora da escolha do NoSQL.

O CouchDB vinha cada vez mais ganhando pontos comigo, mas na mesma pesquisa, o terceiro colocado era o MongoDB, resolvi olhar ele mais de perto, uma vez que queria dar o ponta pé inicial.

MongoDB

Cheguei para olhar o MongoDB só por olhar mesmo, só para ir pro CouchDB com a consciencia limpa. Lia alguma coisa sobre ele, já pensava, mas o CouchDB faz isso também. Mas uma coisa começou a me chamar a atenção, o MongoDB para instalar era só baixar no site e extrair em algum diretório. Isso me chamou a atenção, pois o CouchDB precisava de algumas dependencias para rodar. Logo baixei e instalei, naquele momento comecei a pensar mais sobre ele, um coraçãozinho cresceu.

Rodei uma linha de comando, e está lá, um NoSQL funcioando direitinho. Isso foi tão empolgante, que não achava que pudesse melhorar, olhei no site do MongoDB, e para rodar com o PHP bastava instalar uma DLL. Fui lá e instalei a dll.

A facilidade me encantou, porem ainda pesava a incubadora do CouchDB e todas os outros pontos. Analizando mais um pouco o CouchDB vi que era preciso vários includes para fazer ele funcionar com PHP, menos pontos pra ele, uma vez que o MongoDB se saiu muito bem nessa. Agora fui colocar lado a lado a documentação.

Não precisei olhar muito para saber o escolhido, na imensa documentação do php.net esta uma documentação para o MongoDB. Foi ali que parei de ler o CouchDB e ler sobre o MongoDB. MongoDB funcioando na minha maquina, documentação no php.net, documentação no próprio site do MongoDB era incrivel, não tive mais tempo para o CouchDB.

Benchmark

Felix Geisendörfer fez uma referência em PHP, que foi super-fácil para portar para MongoDB. Seu benchmark diz a respeito da inserção dos dados e não sobre consultas e atualizações. Agora comparando seus resultados para CouchDB com o meu para MongoDB (tempo em ms):

Como você pode ver o MongoDB é um pouco melhor. Aqui estão os números:

N º de inserções	Couch Tempo Total (seg)	Couch / Doc (ms)	Mongo Tempo Total (seg)	Mongo / Doc (ms)
1	0,0015	1,46	0,0005	0,5
2	0,0015	0,75	0,0004	0,2096
3	0,0017	0,56	0,0005	0,1604
4	0,0017	0,44	0,0005	0,1190
5	0,0018	0,36	0,0005	0,1060
6	0,0019	0,32	0,0006	0,0931
7	0,0021	0,3	0,0006	0,0847
8	0,0022	0,27	0,0007	0,0789
9	0,0023	0,25	0,0007	0,0734
10	0,0025	0,25	0,0007	0,0721
50	0,007	0,14	0,0024	0,0476
100	0,0136	0,14	0,0044	0,0442
500	0,0687	0,14	0,0253	0,0505
1000	0,1361	0,14	0,0372	0,0372
2500	0,4686	0,19	0,0278	0,0372
5000	0,9165	0,18	0,0488	0,0371
7500	1,5116	0,2	0,0835	0,0098
10000	2,3111	0,23	0,1065	0,0111
25000	6,8684	0,27	0,2711	0,0107
50000	15,8227	0,32	0,5430	0,0109
100000	35,3071	0,35	1,7697	0,0177
250000	104.0009	0,42	6,4533	0,0258
500000	230.6021	0,46	11,7684	0,0235
750000	352.7959	0,47	17,0473	0,0227
1000000	487.3284	0,49	18,4376	0,0184

Analisando os dados do gráfico e da tabela podemos perceber que o tempo real do MongoDB quase sempre esta uma casa(decimal) abaixo do CouchDB, ou seja, enquanto o CouchDB demora 0,0025 o Mongo DB, para o mesmo conjunto de instruções, demora 0,0007 segundos. E por conseguinte notamos que no final da inserção de 1 milhão de registros o CouchDB demora 487.3284 e o MongoDB 18,4376 segundos ao total. É um tempo considerável a se levar em conta

Conclusão

Posso ter puxado o saco do MongoDB, mas a facilidade de instalação, sem dependencias nem nada, só instalar uma dll no meu php e rodar, foi fator decisivo. No meio do caminho da comparação, o processo foi tão simples que parei por ali. Ao ver a documentação do php.net vi que ali o MongoDB tinha o apoio que eu esperava. Apesar de muitas pessoas estarem entrando no NoSQL indo direto pro CouchDB o MongoDB tem uma comunidade bastante forte, a facilidade dele como um todo é incrivel, isso conta muitos pontos.

Eu escolhi o MongoDB, mas vou estudar o CouchDB e o Cassandra. Eles são tão faceis, que quero aprender nem que seja um pouco de cada um deles, mas estou estudando a fundo o MongoDB.

6 Comments »

I Encontro NOSQL Brasil

maio 12th, 2010 | by suissa | mongodb, nosql

mai
12

Sobre

O movimento noSQL está transformando completamente a forma com que as pessoas olham para os dados – empresas como Twitter, Facebook e Google são alguns dos usuários desta tecnologia.

Os motivos que levam estas e outras empresas ao redor do mundo a utilizar um noSQL são variadas. Em geral, envolvem escalabidade e performance que não conseguimos obter com os tradicionais bancos de dados relacional.

O noSQL Brasil é o primeiro encontro brasileiro que visa apresentar, promover e discutir as tecnologias “noSQL”. Para isso, serão realizadas palestras sobre as diversas abordagens noSQL com exemplos práticos e demonstrações, bem como um painel onde será discutido como e quando utilizar noSQL.

O movimento noSQL está transformando completamente a forma com que as pessoas olham para os dados – empresas como Twitter, Facebook e Google são alguns dos usuários desta tecnologia.

Agenda

Sábado, 15 de Maio de 2010
08.00	- Credenciamento
08.30	- Abertura Alexandre Porcelli, OpenSpotLight
09.00	- noSQL anti-patterns Gleicon Moraes, Locaweb
10.00	- Performance e simplicidade com Chave/Valor utilizando REDIS Luiz Fernando Teston, OpenSpotLight
10.45	- Coffee break
11.20	- O papel do REST no Neo4J e CouchDB, um comparativo Guilherme Silveira, Caelum
12.10	- Introdução ao MongoDB – direto da fonte! Alberto Lerner, 10gen
13.00	- Almoço livre (não incluso)
14.30	- Tio: um NoSQL made in Brasil Rodrigo Strauss, 1bit
15.20	- Nas Nuvens com KVM, JBoss REST-Easy e InfiniSpan Edgar Silva & Samuel Tauil, Red Hat Brasil
16.10	- Coffee break
17.00	- Divide et impera – Processamento massivo com Hadoop, Pig e HBase Vinicius Carvalho, SambaTech
17.50	- Estudo de caso: avaliando o Apache Cassandra como cache distribuído Julio Viegas, GlobalCode
18.40	- Painel de Discussão
19.30	- Happy Hour!

(*) Esta agenda pode ser alterada sem aviso prévio.

maiores informações

http://nosqlbr.com/

1 Comment »

Como fazer um benchmark com PHP

maio 11th, 2010 | by alex | benchmark, escalabilidade, mongodb, nosql

mai
11

Quem está começando com nosql deve estar maravilhado com todo o potencial. E para o ego ficar maior ainda, é legal medir o tempo de carregamento e fazer um benchmark no seu código.

É só você usar essa função:

[php]
function getTime(){
static $tempo;
if( $tempo == NULL ){
$tempo = microtime(true);
}
else{
echo ‘Tempo (segundos): ‘.(microtime(true)-$tempo).”;
}
}
[/php]

Com isso você vai saber o tempo extado que o seu script vai levar para carregar. Para você usar essa função é muito fácil também:

[php]
getTime();
//aqui você coloca o teu código
getTime();
[/php]

E é isso ai, aproveitem e coloquem aqui nos comentários o benchmark de vocês. @suissacorp obrigado pela função.

2 Comments »

Páginação PHP com MongoDB

maio 11th, 2010 | by alex | mongodb, mysql, nosql, uncategorized

mai
11

Um post rápido sobre a fácilidade de páginação com o MongoDB e PHP e todas as outras linguagens.

Com esse simples código, você pode começar a fazer a sua páginação em PHP e MongoDB:

[php]
$cursor->limit(400)->skip(0);
[/php]

Esse é o “substituto” do LIMIT 0,400
Essa fácilidade ainda vem com um forte aliado, o count:

[php]
$cursor->count(true);
$cursor->count();
[/php]

O primeiro count vai retornar a quantidade TOTAL de todos os registros que foram retornados na consulta sem o limit. No nosso exemplo aqui, estamos limitando a 400 registros, mas a quantidade de registros total era de 5 milhões. No segundo count retornamos só o que esta sendo exibido, no caso 400 registros.

A partir dai você já sabe, só da um for na quantidade total dos registros, e montar as páginas.
Mas tome cuidado com esse exemplo que te dei, pois ele pode retornar muitas, muitas páginas mesmo, dependendo da quantidade de registros que você tenha, por isso, faça uma páginação mais detalhada #ficadica.

Como vocês podem ver, a páginação é algo muito simples em relação ao MySQL por exemplo, pois não precisamos consultar novamente o banco de dados para saber a quantidade total de registros.

1 Comment »

Como instalar o CouchDB no Windows

maio 7th, 2010 | by suissa | couchdb, nosql

mai
07

Hoje eu já estava largando mão de tentar instalar o CouchDB no Windows pois havia ficado preso na instalação do ICU (International Components for Unicode), que é um pré-requisito. Estava seguindo este tutorial http://wiki.apache.org/couchdb/Installing_on_Windows

Quando um camarada que eu comentei no slideshare dele http://www.slideshare.net/theoziran/nosql-com-couchdb-e-php me indicou esse site http://www.brunomlopes.com/software/couch-db-binaries

Foi lá que eu encontrei o Santo Graal do CouchDB no WINDOWS, ehehehhe, UM INSTALADOR! Porém eu ja tinha instalado o Erlang, então não sei se é necessário instalar anteriormente ou ele faz tudo. Só sei que meu CouchDB ta rodando lindamente e não é nem preciso de tutorial para isso. #ficadica

http://people.apache.org/~mhammond/dist/0.10.0/setup-couchdb-0.10.0.exe

Um bom começo com é usar essas classes e ir fuçando, exatamente o que estou a fazer.

http://wiki.apache.org/couchdb/Getting_started_with_PHP

Boa Sorte.

1 Comment »

Lighttpd + MongoDB + PHP + MySQL + Servidor direto do pendrive(USB)

maio 7th, 2010 | by alex | escalabilidade, mongodb, mysql, nosql

mai
07

Quem já não teve vontade de testar o mundo nosql, mas ou não conseguiu instalar, ou teve preguiça ou não queria mudar para o linux? Aposto que mais de 90%.

Vendo essa necessidade, aproveitei o programa Lighty2Go que já vem com Lighttpd, php e MySQL, aproveitei e fiz algumas modificações e coloquei o MongoDB e PHP juntos, e de bonus o phpmoadmin, que serve para administrar o MongoDB.

Ele funciona de forma extremamente simples, depois de você baixar os arquivos extraia no pendrive ou em qualquer lugar do seu computador. Depois é só iniciar o servidor

Quando você iniciar o servidor, ele vai estar na porta 81, ou seja, para acessar ele você deve entrar em http://localhost:81

Para administrar o MySQL acesse:
http://localhost:81/phpmyadmin/

Para ver o phpinfo:
http://localhost:81/phpinfo

Para ver o phpmoadmin:
http://localhost:81/moadmin.php

Os arquivos do seu site você pode colocar tudo dentro de HTDOCS.
Fica ai esse excelente pacote, com um dos melhores servidores web o lighttpd, com a melhor programação o PHP, com o melhor banco de dados MongoDB, e o antigo melhor, MySQL.

Download

http://www.megaupload.com/?d=A1MVB1YP
http://rapidshare.com/files/384566309/Lighty2Go.rar.html

3 Comments »

Como instalar Cassandra no Windows

maio 7th, 2010 | by suissa | cassandra, escalabilidade, java, nosql

mai
07

Hoje de manhã me deparei com a facilidade de instalar o Cassandra no Windows então vamos começar baixando a última JDK(Java SE Development Kit) e vai precisar do Cassandra, lógico,http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.6.1/apache-cassandra-0.6.1-bin.tar.gz

Extraia o Cassandra para uma pasta a sua escolha. (Eu usei c:\cassandra)
Defina as seguintes variáveis de ambiente(Painel de Controle > Sistema > Avançado > Variáveis de Sistema)
1. JAVA_HOME (para o diretório onde você instalou o JRE, este não deve ser o diretório bin. Meu exemplo: C:\Arquivos de programas\Java\jdk1.6.0_20)
2. CASSANDRA_HOME (para o diretório que você extraiu os arquivos na etapa 1 – c:\cassandra)

Modifique o arquivo de configuração Cassandra como você gosta e não se esqueça de atualizar as localizações dos diretórios de um UNIX como caminho para algo em seu diretório do Windows (no meu exemplo o arquivo de configuração está localizado em c:\cassandra\conf\storage-conf.xml

<CommitLogDirectory>C:/cassandra/data/commitlog</CommitLogDirectory>
<DataFileDirectories>
<DataFileDirectory>C:/cassandra/data/data</DataFileDirectory>
</DataFileDirectories>

ATENÇÃO

Essas linhas não existem no arquivo padrão, então pode colá-las sem problema. Eu coloquei mais para o final do arquivo.

<CalloutLocation>C:/cassandra/data/callouts</CalloutLocation>
<BootstrapFileDirectory>C:/cassandra/data/bootstrap</BootstrapFileDirectory>
<StagingFileDirectory>C:/cassandra/data/staging</StagingFileDirectory>

Abra o cmd e execute o cassandra.bat arquivo (no meu exemplo está localizado em c:\cassandra\ bin\cassandra.bat)

Você pode verificar que Cassandra está funcionando, ao tentar se conectar ao servidor. Para fazer isso, abra um novo cmd e executar o cassandra-cli.bat arquivo a partir do diretório bin.

c:\cassandra\ bin\cassandra.bat
connect localhost/9160

Caso ainda assim não esteja rodando tente excutar o cassandra.bat e o cassandra-cli.bat apartir do C:\cassandra. Ex.:

cd cassandra
bin\cassandra.bat

E pronto nosso Cassandra já está pronto para uso.

1 Comment »

Armazenar arquivos com MongoDB

maio 7th, 2010 | by suissa | escalabilidade, mongodb, nosql

mai
07

O MongoDB também oferece recursos que vão além das operações de banco de dados. Por exemplo, ele oferece uma boa solução para armazenar arquivos grandes e pequenos no banco de dados.

Os arquivos são automaticamente divididos em blocos. Se MongoDB é executado em um ambiente de auto-sharded, pedaços de arquivo também são replicados em vários servidores.

Armazenar arquivos é surpreendentemente muito difícil, um problema para resolver de forma eficiente, especialmente quando você precisa gerenciar um grande número de arquivos. Salve arquivos em um sistema de arquivos local muitas vezes não é boa solução.

Um exemplo dessa dificuldade é o problema que o YouTube tinha eficientemente servir miniaturas de milhões de vídeos , ou mesmo os cortes realizados pelo Facebook eficientemente servir milhares de milhões de fotos .

MongoDB resolve este problema através da criação de duas coleções internas: os arquivos collection para manter informações sobre os metadados de arquivos e os chunks collection mantém informações sobre os pedaços do arquivo.

Se você quer armazenar um arquivo de vídeo grande, você usaria um código como este:

[php]$metadata = array(
<pre> "filename" => "path.avi",
"downloads" => 0,
"comment" => "This file is foo bar",
"permissions" => array(
"crodas" => "write",
"everybody" => "read",
)
);
$grid = $db->getGridFS();
$grid->storeFile("/file/to/path.avi", $metadata);[/php]

Como você pode ver é simples de entender. #ficadica

parte retirada do artigo: http://www.phpclasses.org/blog/post/118-Developing-scalable-PHP-applications-using-MongoDB.html

No Comments »

Eu tenho que me preocupar com SQL Injection no MongoDB?

maio 7th, 2010 | by suissa | escalabilidade, javascript, mongodb, nosql, sql

mai
07

Geralmente, com MongoDB não estamos construindo a partir de consultas SQL, logo ataques SQL Injection não são um problema.

No MongoDB as consultas são representados como BSON. Normalmente a linguagem de programação oferece uma maneira conveniente de construir estes objetos que está livre da injeção. Qualquer caracter especial não afetará o banco pois ele será apenas uma string.

Javascript

Alguns cuidados são apropriados quando utilizando Javascript. Por exemplo, quando usando o $ em uma consulta, não concatenar fornecido usuário declaração de dados para compilar o código Javascript, o que seria análogo a uma vulnerabilidade de injeção SQL. Felizmente, a maioria das consultas em MongoDB pode ser expresso sem Javascript. Além disso, podemos misturar os dois modos. É uma boa idéia para fazer todos os campos fornecidos pelo usuário ir direto para um campo BSON.

Você pode usar db.eval () com valores fornecidos usuário, você pode usar o CodeWScope ou você pode fornecer argumentos extras para sua função. Algo como: function (db.eval (userVal ){…}, user_value); Isto irá assegurar que você obterá user_value enviadas como dados em vez de código.

As vezes é útil construir um objeto BSON onde a chave é fornecida pelo usuário. Nessas situações, as chaves precisam ter substituições. O usuário pode enviar uma $ valor com a_chave.meu_objeto onde {$algo: “coisas”}. Então podemos ver alguns casos:

Inserindo. Inserção no banco de dados não fará nenhum dano. Nós não estamos executando esse objeto como uma consulta, estamos inserindo os dados no banco de dados.
Update. Atualização (consulta, obj) permite $ operadores no domínio obj. $ Onde não é suportado em atualização. Alguns operadores são possíveis, que manipulam o documento único – assim, as chaves devem ser escapadas.
Consultando. Geralmente este não é um problema, como por (x: user_obj), cifrões não são de nível superior e não ter nenhum efeito. Em teoria, pode-se deixar o usuário criar uma consulta completamente dele e fornecê-la ao banco de dados. Nesse caso, a verificação por $ nas chaves é importante. No entanto, isso seria um caso muito raro.

Artigo semi traduzido de http://www.mongodb.org/pages/viewpage.action?pageId=7209106

No Comments »