nosql

[luizak 0]

Boa noite gente,

 

Estou começando meus estudos com nosql, mas estou meio perdida. O nosql é um sgbd assim como o sql server? outra coisa andei pesquisando também sobre o mongodb, um site disse que ele é um banco do nosql... não tou entendendo nada disso. Alguem pode me explicar de forma bem clara.

[Fernando C 128]

explicar de forma bem clara.

 

Dificil.. é uma tecnologia nova, com diversas ramificações (existem basicamente três tipos e cada um tem seus SGDBs)

e SEM uma linguagem padronizada como a SQL..

por isso o nome - que significa "NOT ONLY SQL", e não "não SQL" ou "sem SQL".etc..

e para complicar 1 pouquinho mais não é pq vc vai utliza-la que não vai utilizar 1 banco SQL, eles seriam "complementares",

dependendo de sua aplicação..

Bom, tem uma otima materia aqui:

http://www.devmedia.com.br/revista-sql-magazine-111/28108

onde o autor explica os prblemas da SQL, tem exemplos práticos, medições de desempenho (essa parte realmente espanta; a diferença é gritante, mas não sei direito os critérios, ambiente etc.)

a matéria não é gratuita se vc não for assinante, mas eu recomendo; vale a pena até encomendar a revista.

mas caso descubramos outras, é sempre bom trocar ideia.. boa sorte e até +...

[luizak 0]

ok, vou dar uma pesquisada obrigada.

[Vinicius Ianni 189]

O termo nosql se refere a bancos de dados que não usam os conceitos que regem o sql de forma geral.

Este link explica bem isso.

 

Existem vários bancos de dados que usam este conceito, e eles podem ser divididos pela forma como manipulam os dados que armazenam.

 

Basicamente, seriam:

 

Banco de dados que trabalham no esquema chave/valor (Key/Value);
Bancos de dados orientados a documentos;
Bancos de dados de famílias de colunas;
Bancos de dados de grafos;

 

Por terem essas variações, além de cada familia poder ser melhor indicada para um determinado projeto, isso nos dá uma grande versatilidade quando precisamos manipular grandes volumes de informação.

 

Escrevi há algum tempo atrás uma pequena série de artigos sobre o assunto, sendo que este deve lhe ajudar a clarear suas duvidas.

 

O mongodb é um banco de dados nosql, que é orientado a documentos, e além de ser de facil compreensão e aprendizado, é muito utilizado em vários projetos, e muito bem documentado.

[luizak 0]

Já andei dando uma leitura nestes links que você passou... deu uma boa clareada... obrigada...

 

Mas, o que seria um banco de dados orientado a documentos? pesquisei e achei uma definição em um dos links que você me passou diz assim.... Em geral, os bancos de dados orientados a documento não possuem esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum.

Como assim? senão tem esquema então como é que funciona?

[Vinicius Ianni 189]

A forma que usei para entender o conceito de banco de dados orientado a documentos, foi fazendo uma analogia a uma biblioteca, livraria ou algo do tipo.

 

Um mesmo assunto pode ser abordado numa materia de jornal, um artigo cientifico, um livro inteiro dedicado ao tema, um pdf com poucas páginas abordando algum aspecto desse assunto e por ai vai.

 

Esses documentos terão cada um um determinado formato, e será um grande desperdicio de recursos se você criar uma tabela que contenha todos os campos que julgue necessários armazenar neste momento, ou criar várias tabelas, cada uma dedicada a um determinado formato (livro, jornal, pdf, monografia, etc...)

 

Além disso, existe a possibilidade desse assunto ser abordado num meio que seu banco de dados inicialmente não suporta, digamos, uma revista, um video, uma gravação em audio....

 

Qual seria a forma de armazenar isso ?

Inserir novos campos na tabela existente para acomodar isso, ou criar uma tabela distinta só para esse formato.

 

Se optarmos pela primeira abordagem, provavelmente os outros registros terão os novos campos não preenchidos, pois não contemplam seus requisitos.

Dependendo do banco de dados utilizado, isso pode implicar no incremento do espaço utilizado em disco, o que pode tem grande impacto dependendo do volume de dados armazenados.

 

Além disso, o tempo de resposta a uma consulta, dependendo dos parametros fornecidos, também sofrerá um aumento, e dependendo no numero de requisições simultaneas, isso pode se tornar uma grande problema.

 

Mas e se houver poucos registros nesse formato ?

Como justificar esse aumento de custo ?

 

O fato de ser sem esquema, não significa que os dados ficarão armazenados de forma bagunçada.

Vejamos a definição do MongoDB sobre isso:

 

"O MongoDB usa esquemas dinâmicos.

Você pode criar coleções, sem a definição da estrutura, ou seja, os campos ou os tipos de seus valores, dos documentos na coleção.

Você pode alterar a estrutura de documentos simplesmente adicionando novos campos ou excluir os existentes.

Os documentos em uma coleção não precisam ter um conjunto idêntico de campos.

Na prática, é comum para os documentos de uma coleção de ter uma estrutura muito homogénea, no entanto, isto não é um requisito.

Os esquemas flexíveis do MongoDB significam que a migração do esquema e o aumento é muito fácil, na prática, e você raramente, ou nunca, precisará escrever scripts que executam "ALTER TABLE" ou operações do tipo, o que simplifica e facilita o desenvolvimento iterativo de software com MongoDB."

 

Documentos = registros.

Coleção = tabela.

 

Imagina que você tem um projeto para coletar tudo o que é mencionado sobre determinado assunto em multiplas fontes de origem (redes sociais, sites de noticias, sites especializados nesse assunto, etc...)

 

Inicialmente as fontes de origem serão 2 redes sociais, 3 sites de noticias e 1 site academico.

Você precisará coletar onde o assunto foi publicado, o que foi publicado e a data da publicação.

 

Passado algum tempo de coleta e registro, novos sites são adicionados a essa lista e também deseja registrar a hora da publicação e o autor.

 

Ao invés de alterar a tabela (coleção) para inserir esses novos campos e inserir uma flag qualquer nos campos dos registros anteriormente gravados, você apenas modifica sua aplicação para ela passar a inserir na coleção esses novos valores.

 

Os registros (documentos) que foram gravados até momentos antes da modificação no programa/script não sofrem quaisquer alterações, e permanecem disponiveis para as consultas, sem o incremento de espaço ocupado em disco.

 

Isso pode soar meio abstrato ou sem muita serventia, principalmente se ainda pensamos de forma "sql" mas ao usarmos muitas fontes de origem para a coleta de dados, haverá fontes que não provêem a mesma quantidade de informação que outras.

Digamos, uma fonte fornece data/hora/geolocalização de onde foi publicado, outra somente data e hora, algumas publicarão também o autor original e quem compartilhou / curtiu / favoritou isso, outras informarão também se foi publicado via dispositivo mobile ou não, algumas podem informar além do dispositivo utilizado na publicação, qual é o modelo e fabricante, e por ai vai....

 

Como as informações sobre um mesmo assunto podem variar enormemente de acordo com quem publica, podemos querer registrar tudo o que estiver disponivel, e se criarmos um campo novo para cada um isso se tornará um serviço de maluco, afinal basta o lancamento de um novo device e teremos de modificar e atualizar tudo para ficar "compativel".

 

Com a ideia do esquema dinamico ou sem esquema, registra-se somente o que temos a disposição naquele momento, se houver mais informações, registra-se também.

 

A mesma coleção, pode conter campos como:

 

{autor:"Jose da Silva", titulo:"A variação da umidade relativa do ar em campos de girassol", data:"20/11/2013", tags: ["agricultura","sensor de umidade","tecnologia"]}

{autor:"Mariana da Silva",titulo:"usando sensores de umidade na localização de infiltrações em prédios residenciais",data:"19/01/2012",hora:"22:23:02",dispositivo:"Galaxy Note",tags:["predio","umidade","sensor","tecnologia"]}

{origem:"Jornal dos curiosos por tecnologia",titulo:"Usando sensores de umidade, barometro e altimetro de forma combinada",data:"11/2013"}

 

Note que alguns possuem campos em comum, outros possuem mais ou menos campos nos documentos, essa é a vantagem do esquema dinamico, podemos armazenar os dados tais como eles nos são apresentados, sem nos preocuparmos em "adequar" a informação recebida com o a forma que o banco de dados exige para armazenar esses dados.

 

Isso nos dá uma grande versatilidade e liberdade, e podemos assim, nos focar na analitica dos dados, oferecendo resultados mais precisos e acurados e de forma bem rápida.

[rodrigoords 1]

Olá,

 

Banco de dados de documentos, são orientados a agregados, assim como bancos de chave/valor e famílias de colunas, entender esse conceito facilita muito entender a lógica desse tipo de banco de dados.

Um ótimo artigo para se estudar pode ser encontrado aqui: https://oak.cs.ucla.edu/cs144/handouts/nosqldbs.pdf

Um livro muito bom para quem está começando os estudos é : NoSQL Essencial (Pramod J. Sadalage, Martin Fowler).

 

Basicamente um agregado é um contêiner de dados, que não tem um schema pré definido.

por exemplo:

 

Você pode ter um agregado de cliente

 

//cliente

{

id:01,

name: Rodrigo

IdPedido:001

}

 

e um agregado de pedidos

 

//pedido

{

id:001

item:Livro NoSQL

preço: R$ 50,00

}

 

neste caso para se consultar o cliente e o pedido seria necessário um relacionamento entre os dois, porém você pode fazer um agregado como.

 

//cliente

{

id:01,

name: Rodrigo

Pedidos[{

id:001

item:'Livro NoSQL"

preço: R$ 50,00

},

{

id:002

item: 'Aulas NoSQL"

preço: R$ 10,00

}]

}

em que nesse caso ao retornar um cliente, você também retorna todos os pedidos vinculados a ele, sem necessidade de relacionamento com ou agregado.

Banco de dados de documentos funcionam basicamente dessa forma.

espero ter ajudado.