select kcu.table_schema || '.' ||kcu.table_name as foreign_table,
'>-' as rel,
rel_tco.table_schema || '.' || rel_tco.table_name as primary_table,
string_agg(kcu.column_name, ', ') as fk_columns,
kcu.constraint_name
from information_schema.table_constraints tco
join information_schema.key_column_usage kcu
on tco.constraint_schema = kcu.constraint_schema
and tco.constraint_name = kcu.constraint_name
join information_schema.referential_constraints rco
on tco.constraint_schema = rco.constraint_schema
and tco.constraint_name = rco.constraint_name
join information_schema.table_constraints rel_tco
on rco.unique_constraint_schema = rel_tco.constraint_schema
and rco.unique_constraint_name = rel_tco.constraint_name
where tco.constraint_type = 'FOREIGN KEY'
group by kcu.table_schema,
kcu.table_name,
rel_tco.table_name,
rel_tco.table_schema,
kcu.constraint_name
order by kcu.table_schema,
kcu.table_name;Category Archives: Banco de Dados
DBDiagram.io Exemplo
Exemplo de modelo de dados DBDiagram.io
//// -- LEVEL 1
//// -- Tables and References
// Creating tables
Table users as U {
id int [pk, increment] // auto-increment
full_name varchar
created_at timestamp
country_code int
}
Table countries {
code int [pk]
name varchar
continent_name varchar
}
// Creating references
// You can also define relaionship separately
// > many-to-one; < one-to-many; - one-to-one
Ref: U.country_code > countries.code
Ref: merchants.country_code > countries.code
//----------------------------------------------//
//// -- LEVEL 2
//// -- Adding column settings
Table order_items {
order_id int [ref: > orders.id] // inline relationship (many-to-one)
product_id int
quantity int [default: 1] // default value
}
Ref: order_items.product_id > products.id
Table orders {
id int [pk] // primary key
user_id int [not null, unique]
status varchar
created_at varchar [note: 'When order created'] // add column note
}
//----------------------------------------------//
//// -- Level 3
//// -- Enum, Indexes
// Enum for 'products' table below
Enum products_status {
out_of_stock
in_stock
running_low [note: 'less than 20'] // add column note
}
// Indexes: You can define a single or multi-column index
Table products {
id int [pk]
name varchar
merchant_id int [not null]
price int
status products_status
created_at datetime [default: `now()`]
Indexes {
(merchant_id, status) [name:'product_status']
id [unique]
}
}
Table merchants {
id int
country_code int
merchant_name varchar
"created at" varchar
admin_id int [ref: > U.id]
Indexes {
(id, country_code) [pk]
}
}
Table merchant_periods {
id int [pk]
merchant_id int
country_code int
start_date datetime
end_date datetime
}
Ref: products.merchant_id > merchants.id // many-to-one
//composite foreign key
Ref: merchant_periods.(merchant_id, country_code) > merchants.(id, country_code)
Instalando MySQL 8 no Windows
Este post demonstra a instalação e configuração do MySQL 8 (versão 8.0.16) no Windows, via arquivo zip.
Baixando o MySQL
Acesse o site https://dev.mysql.com/downloads/ e baixe o MySQL Community Server 8.0.16 (Zip Archive).
Descompactando o MySQL
Após baixar o arquivo mysql-8.0.16-winx64.zip, descompacte-o no diretório destino. Para este exemplo, descompactamos em C:\opt\mysql-8.0.16-winx64\
Inicializando o MysQL
Abra um Prompt de Comando e digite:
cd C:\opt\mysql-8.0.16-winx64\bin
C:\opt\mysql-8.0.16-winx64\bin\mysqld --initialize
Subindo o MySQL
Na pasta bin, digite:
C:\opt\mysql-8.0.16-winx64\bin\mysqld --console
Testando conexão
Com o servidor no ar, abra outro Prompt de Comando e digite:
C:\opt\mysql-8.0.16-winx64\bin\mysql -u root -h localhost
Ocorrerá um erro de autenticação, pois não foi enviada a senha. Veja o erro abaixo:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
Verificando senha do MySQL
Localize o arquivo com extensão .err (no meu caso o arquivo é Lenovo-I7.err) e abra no editor. Verifique que a senha é apresentada no arquivo.
A temporary password is generated for root@localhost: hjD8X3e8Jq&W
Conectando com a senha
Agora, utilize o comando abaixo, com a senha obtida no arquivo de erro.
C:\opt\mysql-8.0.16-winx64\bin\mysql -u root -h localhost -p
Quando solicitar a senha, informe:
Enter password: hjD8X3e8Jq&W (aparecerá com asteriscos)
Deverá aparecer o prompt com o MySQL conectado
mysql >
Alterando a senha do usuário root
Conectado no MySQL, digite:
mysql> alter user 'root'@'localhost' identified by 'root'; Query OK, 0 rows affected (0.01 sec)
Baixando o servidor
Para baixar o servidor, de forma normal, digite:
C:\opt\mysql-8.0.16-winx64\bin\mysqladmin -u root -p shutdown Enter password: root
Instalando como serviço
Para instalar o MySQL como serviço do Windows, digite:
C:\opt\mysql-8.0.16-winx64\bin\mysqld --install "MySQL 8.0.16" Service successfully installed.
NOTA: Importante executar o Prompt de Comando como Administrador!!!
Para verificar o serviço, execute o comando abaixo (na janela que se abrirá, perceba que existe o serviço MySQL 8.0.16:
services.msc
Exemplo de Modelagem Cassandra
Escolher o modelo de dados certo é a parte mais difícil de usar o Cassandra. Se você tiver um histórico relacional, o CQL parecerá familiar, mas a maneira como você o utiliza pode ser muito diferente. O objetivo deste post é explicar as regras básicas que você deve ter em mente ao projetar seu esquema para o Cassandra. Se você seguir essas regras, obterá um bom desempenho imediato. Melhor ainda, seu desempenho deve ser dimensionado linearmente à medida que você adiciona nós ao cluster.
Não-objetivos
Os desenvolvedores que vêm de um background relacional geralmente carregam regras sobre modelagem relacional e tentam aplicá-las a Cassandra. Para evitar perder tempo com regras que realmente não importam com o Cassandra, quero destacar algumas não- metas:
Minimize o número de gravações
As gravações em Cassandra não são gratuitas, mas são muito baratas. O Cassandra é otimizado para alta taxa de transferência, e quase todas as gravações são igualmente eficientes [1] . Se você pode realizar gravações extras para melhorar a eficiência de suas consultas de leitura, quase sempre é uma boa compensação. As leituras tendem a ser mais caras e são muito mais difíceis de ajustar.
Minimize a duplicação de dados
Desnormalização e duplicação de dados é um fato da vida com Cassandra. Não tenha medo disso. Geralmente, o espaço em disco é o recurso mais barato (comparado à CPU, memória, IOPs de disco ou rede), e Cassandra é arquitetada em torno desse fato. Para obter as leituras mais eficientes, você geralmente precisa duplicar os dados.
Além disso, a Cassandra não tem o JOIN s, e você não quer realmente usá-los de maneira distribuída.
Objetivos Básicos
Estas são as duas metas de alto nível para seu modelo de dados:
- Espalhar dados uniformemente ao redor do cluster
- Minimize o número de partições lidas
Há outras metas menores a serem lembradas, mas estas são as mais importantes. Na maioria das vezes, vou me concentrar no básico de alcançar esses dois objetivos.Existem outros truques que você pode usar, mas você deve saber como avaliá-los primeiro.
Regra 1: espalhar dados uniformemente em torno do cluster
Você deseja que todos os nós do cluster tenham aproximadamente a mesma quantidade de dados. Cassandra torna isso fácil, mas não é um dado. As linhas são espalhadas pelo cluster com base em um hash da chave de partição , que é o primeiro elemento da PRIMARY KEY . Então, a chave para espalhar dados uniformemente é esta: escolha uma boa chave primária . Vou explicar como fazer isso daqui a pouco.
Regra 2: Minimizar o número de partições lidas
Partições são grupos de linhas que compartilham a mesma chave de partição. Quando você emite uma consulta de leitura, deseja ler as linhas do menor número possível de partições.
Por que isso é importante? Cada partição pode residir em um nó diferente. O coordenador geralmente precisará emitir comandos separados para separar nós para cada partição solicitada. Isso adiciona muita sobrecarga e aumenta a variação na latência. Além disso, mesmo em um único nó, é mais caro ler de várias partições do que de uma única, devido à maneira como as linhas são armazenadas.
Regras conflitantes?
Se é bom minimizar o número de partições das quais você lê, por que não colocar tudo em uma única partição grande? Você acabaria violando a Regra nº 1, que é espalhar dados uniformemente pelo cluster.
O ponto é que esses dois objetivos geralmente estão em conflito, então você precisa tentar equilibrá-los.
Modelo em torno de suas consultas
A maneira de minimizar as leituras de partição é modelar seus dados para atender às suas consultas. Não modele em torno de relações. Não modele em torno de objetos.Modelo em torno de suas consultas. Veja como você faz isso:
Etapa 1: determine quais consultas devem ser suportadas
Tente determinar exatamente quais consultas você precisa dar suporte. Isso pode incluir muitas considerações que você pode não pensar no início. Por exemplo, você pode precisar pensar sobre:
- Agrupamento por um atributo
- Ordenação por um atributo
- Filtrando com base em algum conjunto de condições
- Impondo exclusividade no conjunto de resultados
- etc …
As alterações em apenas um desses requisitos de consulta geralmente garantirão uma alteração do modelo de dados para máxima eficiência.
Etapa 2: tente criar uma tabela onde você possa satisfazer sua consulta lendo (aproximadamente) uma partição
Na prática, isso geralmente significa que você usará aproximadamente uma tabela por padrão de consulta. Se você precisar oferecer suporte a vários padrões de consulta, geralmente precisará de mais de uma tabela.
Para colocar isso de outra forma, cada tabela deve pré-construir a “resposta” para uma consulta de alto nível que você precisa dar suporte. Se você precisa de diferentes tipos de respostas, geralmente precisa de tabelas diferentes. É assim que você otimiza para leituras.
Lembre-se, a duplicação de dados está bem. Muitas de suas tabelas podem repetir os mesmos dados.
Aplicando as regras: exemplos
Para mostrar alguns exemplos de um bom processo, vou orientá-lo no design de um modelo de dados para alguns problemas simples.
Exemplo 1: pesquisa de usuário
O requisito de alto nível é “nós temos usuários e queremos procurá-los”. Vamos seguir os passos:
Etapa 1 : Determinar quais consultas específicas para suporte
Digamos que queremos ser capazes de procurar um usuário pelo nome de usuário ou pelo e-mail. Com o método de pesquisa, devemos obter o conjunto completo de detalhes do usuário.
Etapa 2 : tente criar uma tabela onde você possa satisfazer sua consulta lendo (aproximadamente) uma partição
Como queremos obter todos os detalhes para o usuário com o método de pesquisa, é melhor usar duas tabelas:
| 1234567891011 | CREATE TABLE users_by_username (username text PRIMARY KEY,email text,age int) CREATE TABLE users_by_email (email text PRIMARY KEY,username text,age int) |
Agora, vamos verificar as duas regras para este modelo:
Espalha os dados uniformemente? Cada usuário recebe sua própria partição, então sim.
Partições mínimas são lidas? Nós só temos que ler uma partição, então sim.
Agora, vamos supor que tentamos otimizar para os não- objetivos e, em vez disso, criamos esse modelo de dados:
| 12345678910111213141516 | CREATE TABLE users (id uuid PRIMARY KEY,username text,email text,age int) CREATE TABLE users_by_username (username text PRIMARY KEY,id uuid) CREATE TABLE users_by_email (email text PRIMARY KEY,id uuid) |
Esse modelo de dados também distribui os dados de maneira uniforme, mas há uma desvantagem: agora temos que ler duas partições, uma de users_by_username (ou users_by_email ) e outra de usuários . Portanto, as leituras são aproximadamente duas vezes mais caras.
Exemplo 2: grupos de usuários
Agora o requisito de alto nível mudou. Os usuários estão em grupos e queremos que todos os usuários entrem em um grupo.
Etapa 1 : Determinar quais consultas específicas para suporte
Queremos obter as informações completas do usuário para cada usuário em um grupo específico. Ordem dos usuários não importa.
Etapa 2 : tente criar uma tabela onde você possa satisfazer sua consulta lendo (aproximadamente) uma partição
Como podemos encaixar um grupo em uma partição? Podemos usar um PRIMARY KEY composto para isso:
| 1234567 | CREATE TABLE groups (groupname text,username text,email text,age int,PRIMARY KEY (groupname, username)) |
Observe que a PRIMARY KEY tem dois componentes: groupname , que é a chave de particionamento, e username , que é chamado de chave de clustering. Isso nos dará uma partição por nome de grupo . Dentro de uma determinada partição (grupo), as linhas serão ordenadas por nome de usuário . Buscar um grupo é tão simples quanto fazer o seguinte:
| 1 | SELECT * FROM groups WHERE groupname = ? |
Isso satisfaz o objetivo de minimizar o número de partições que são lidas, porque precisamos apenas ler uma partição. No entanto, ele não funciona tão bem com o primeiro objetivo de espalhar uniformemente os dados ao redor do cluster. Se tivermos milhares ou milhões de pequenos grupos com centenas de usuários cada, teremos uma distribuição bastante uniforme. Mas se houver um grupo com milhões de usuários, todo o fardo será suportado por um nó (ou um conjunto de réplicas).
Se quisermos distribuir a carga de maneira mais uniforme, há algumas estratégias que podemos usar. A técnica básica é adicionar outra coluna à PRIMARY KEY para formar uma chave de partição composta. Aqui está um exemplo:
| 12345678 | CREATE TABLE groups (groupname text,username text,email text,age int,hash_prefix int,PRIMARY KEY ((groupname, hash_prefix), username)) |
A nova coluna, hash_prefix , contém um prefixo de um hash do nome de usuário. Por exemplo, pode ser o primeiro byte do hash módulo quatro. Juntamente com groupname , essas duas colunas formam a chave de partição composta. Em vez de um grupo residindo em uma partição, ela agora está espalhada em quatro partições.Nossos dados estão mais uniformemente distribuídos, mas agora temos que ler quatro vezes mais partições. Este é um exemplo dos dois objetivos conflitantes. Você precisa encontrar um bom equilíbrio para seu caso de uso específico. Se você fizer um monte de leituras e grupos não ficarem muito grandes, talvez mudar o valor do módulo de quatro para dois seria uma boa escolha. Por outro lado, se você fizer muito poucas leituras, mas qualquer grupo pode crescer muito, mudar de quatro para dez seria uma escolha melhor.
Existem outras maneiras de dividir uma partição, que abordarei no próximo exemplo.
Antes de prosseguirmos, deixe-me apontar algo sobre esse modelo de dados: estamos duplicando as informações do usuário muitas vezes, uma vez para cada grupo. Você pode ser tentado a tentar um modelo de dados como esse para reduzir a duplicação:
| 123456789101112 | CREATE TABLE users (id uuid PRIMARY KEY,username text,email text,age int) CREATE TABLE groups (groupname text,user_id uuid,PRIMARY KEY (groupname, user_id)) |
Obviamente, isso minimiza a duplicação. Mas quantas partições precisamos ler? Se um grupo tiver 1000 usuários, precisamos ler 1001 partições. Isso é provavelmente 100 vezes mais caro para ler do que nosso primeiro modelo de dados. Se as leituras precisam ser eficientes, isso não é um bom modelo. Por outro lado, se as leituras são extremamente raras, mas as atualizações das informações do usuário (digamos, o nome de usuário) são extremamente comuns, esse modelo de dados pode realmente fazer sentido. Certifique-se de levar em consideração sua proporção de leitura / atualização ao projetar seu esquema.
Exemplo 3: grupos de usuários por data de associação
Suponha que continuemos com o exemplo anterior de grupos, mas precisemos adicionar suporte para obter os usuários X mais recentes em um grupo.
Podemos usar uma tabela semelhante à última:
| 12345678 | CREATE TABLE group_join_dates (groupname text,joined timeuuid,username text,email text,age int,PRIMARY KEY (groupname, joined)) |
Aqui estamos usando um timeuuid (que é como um timestamp, mas evita colisões) como a coluna de clustering. Dentro de um grupo (partição), as linhas serão ordenadas no momento em que o usuário ingressou no grupo. Isso nos permite obter os usuários mais novos em um grupo da seguinte forma:
| 1234 | SELECT * FROM group_join_datesWHERE groupname = ?ORDER BY joined DESCLIMIT ? |
Isso é razoavelmente eficiente, pois estamos lendo uma fatia de linhas de uma única partição. No entanto, em vez de sempre usar o DESC associado ao ORDER BY , o que torna a consulta menos eficiente, podemos simplesmente inverter a ordem de cluster:
| 12345678 | CREATE TABLE group_join_dates (groupname text,joined timeuuid,username text,email text,age int,PRIMARY KEY (groupname, joined)) WITH CLUSTERING ORDER BY (joined DESC) |
Agora podemos usar a consulta um pouco mais eficiente:
| 123 | SELECT * FROM group_join_datesWHERE groupname = ?LIMIT ? |
Como no exemplo anterior, poderíamos ter problemas com os dados sendo distribuídos uniformemente ao redor do cluster, caso algum grupo ficasse muito grande. Nesse exemplo, dividimos as partições de forma aleatória, mas, nesse caso, podemos utilizar nosso conhecimento sobre os padrões de consulta para dividir as partições de uma maneira diferente: por um intervalo de tempo.
Por exemplo, podemos dividir partições por data:
| 123456789 | CREATE TABLE group_join_dates (groupname text,joined timeuuid,join_date text,username text,email text,age int,PRIMARY KEY ((groupname, join_date), joined)) WITH CLUSTERING ORDER BY (joined DESC) |
Estamos usando uma chave de partição composta novamente, mas desta vez estamos usando a data de associação. Cada dia, uma nova partição será iniciada. Ao consultar os usuários mais novos do X, primeiro consultaremos a partição de hoje, depois a de ontem e assim por diante, até que tenhamos usuários X. Talvez tenhamos que ler várias partições antes que o limite seja atingido.
Para minimizar o número de partições que você precisa consultar, tente selecionar um intervalo de tempo para dividir as partições que geralmente permitem que você consulte apenas uma ou duas partições. Por exemplo, se normalmente precisamos dos dez usuários mais novos, e os grupos geralmente adquirem três usuários por dia, devemos dividir por intervalos de quatro dias em vez de um único dia [2] .
Resumo
As regras básicas de modelagem de dados cobertas aqui aplicam-se a todas as versões (atualmente) existentes do Cassandra e são muito prováveis de se aplicarem a todas as versões futuras. Outros problemas de modelagem de dados menores, como lidar com marcas de exclusão , também podem precisar ser considerados, mas esses problemas têm maior probabilidade de mudar (ou serem atenuados) por versões futuras do Cassandra.
Além das estratégias básicas abordadas aqui, alguns dos recursos mais extravagantes do Cassandra, como coleções , tipos definidos pelo usuário e colunas estáticas , também podem ser usados para reduzir o número de partições que você precisa ler para satisfazer uma consulta. Não se esqueça de considerar essas opções ao projetar seu esquema.
Fonte: https://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling
Cassandra e Docker – Ubuntu
Este post apresenta a instalação e utilização do Apache Cassandra, usando Docker.
Baixando a Imagem Docker
$ sudo docker pull cassandra
Esse comando efetuará o download da última versão do Cassandra (latest)
Verificando a Imagem
$ sudo docker images
Resultado
REPOSITORY TAG IMAGE ID CREATED SIZE
cassandra latest 8ea89760ce2b 5 weeks ago 323MB
Subindo o Cassandra
$ sudo docker run --name node1 -d cassandra:lastest
Resultado
f451246389a40761b5a70cbb2d665801f3b2356afcd3abf6ee9a7aa4bd1fe064
Baixando o Cassandra
$ sudo docker stop f451246389a40761b5a70cbb2d665801f3b2356afcd3abf6ee9a7aa4bd1fe064
Removendo
$ sudo docker rm node1
Verificando processos
$ docker exec -it node1 nodetool status
Ferramenta shell CQL
Dentro do container é possível executar o cqlsh.
$ docker exec -it node1 cqlshConnected to Test Cluster at 127.0.0.1:9042.[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]Use HELP for help.cqlsh>
Criando Keyspace
cqlsh> CREATE KEYSPACE myspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 3};
Criando uma tabela
CREATE TABLE myspace.exam (patient_id int,id int,date timeuuid,details text,PRIMARY KEY (patient_id, id));
Inserindo dados
INSERT INTO exam (patient_id,id,date,details) values (1,1,now(),'first exam patient 1');INSERT INTO exam (patient_id,id,date,details) values (1,2,now(),'second exam patient 1');INSERT INTO exam (patient_id,id,date,details) values (2,1,now(),'first exam patient 2');INSERT INTO exam (patient_id,id,date,details) values (3,1,now(),'first exam patient 3');
Consultando dados
cqlsh:patient> select * from exam where patient_id=1;
Instalando MySQL no Ubuntu usando Docker
Baixando a Imagem
$ sudo docker pull mysql/mysql-server:latest
Rodando o MySQL
$ sudo docker run -it –name mysql -e MYSQL_ROOT_PASSWORD=root -p 3306:3306 -d mysql
Verificando Logs
$ sudo docker logs mysql
Parando o MySQL
$ sudo docker stop mysql
Reiniciando o MySQL
$ sudo docker start mysql
Removendo o MySQL
$ sudo docker rm mysql
Forma alternativa
$ sudo docker run -d –name=mysql-server -p 3306:3306 -v mysql-data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root mysql
Listando imagens
$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
mysql latest ecac195d15af 23 hours ago 516MB
mongo latest 0e120e3fce9a 3 months ago 449MB
amazon/dynamodb-local latest 7984b9b533e7 5 months ago 613MB
$ sudo docker rmi ecac195d15af
MongoDB – Docker – Ubuntu
Introdução
Neste post, vamos instalar e rodar o MongoDB, usando Docker no Ubuntu.
Pré-requisitos
Ter o Docker instalado no Ubuntu. Veja como instalar aqui.
Pesquisando bibliotecas MongoDB
Aqui, vamos verificar quais bibliotecas MongoDB estão disponíveis para download no Ubuntu.
# docker search mongodb
Resultado:
No nosso exemplo, vamos utilizar a versão oficial “mongo”.
Baixar a biblioteca
Vamos baixar a biblioteca “mongo”
# docker pull mongo
Aguarde o processo de instalação concluir.
Verificar imagem baixada
# docker images
Rodar a imagem
# docker run --name testemongo -p 27017:27017 -d mongo
Parar a imagem
# docker stop testemongo
Reiniciar a imagem
# docker start testemongo
Entrar no container
Agora, vamos entrar no container para subir o MongoDB do container.
# docker exec -it testemongo /bin/bash
Subir o MongoDB
Dentro do container, vamos iniciar o MongoDB.
# mongo
Resultado:
Pronto! O MongoDB está disponível para utilização.
Instalando MongoDB no Ubuntu em 4 passos
Introdução
Este post tem por objetivo demonstrar como instalar o MongoDB no Ubuntu, de forma fácil. O procedimento foi executado no Ubuntu 16.04 LTS e funcionou perfeitamente.
Configurando o Repositório
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4
Adicionar o Repositório
Ubuntu 18.04 LTS
$ echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb.list
Ubuntu 16.04 LTS
$ echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb.list
Atualizar biblioteca
$ sudo apt update
Instalar o MongoDB
$ sudo apt install mongodb-org
Pronto! A etapa de instalação esta concluída. Agora veremos como utilizar o MongoDB.
Gerenciando MongoDB Service
Habilitando o MongoDB
$ sudo systemctl enable mongod
Iniciando o MongoDB
$ sudo systemctl start mongod
Parando o MongoDB
$ sudo systemctl stop mongod
Verificando a versao
$ mongod --version
Fonte: https://tecadmin.net/install-mongodb-on-ubuntu/
MongoDB – Primeiros Comandos – Linux
Introdução
Este post tem o objetivo de iniciar a utilização do MongoDB, usando comandos.
Pré-requisitos
Para começarmos, é necessário ter executado o procedimento do post Instalar MongoDB no Ubuntu.
Console do MongoDB
Para abrir o console do MongoDB, utilize o comando
$ mongo
Listando bancos
> show dbs
admin 0.000GB
escola 0.000GB
local 0.000GB
Criando ou entrando no banco
Para entrar ou criar um banco, utilize o comando “use”. Se o banco não existir, será criado automaticamente.
> use escola
switched to db escola
Criando tabela e inserindo dado
Podemos criar uma tabela e inserir o dado ao mesmo tempo. Para isso, utilizamos o comando db.[[TABELA]].insert.
> db.aluno.insert({‘nome’:’Luis Fernando Chaim’,’dataNasc’:new Date(‘1972-05-22’)})
WriteResult({ “nInserted” : 1 })
Listando tabelas
> show collections
aluno
Pesquisando dado
Para pesquisar os dados de uma tabela, utilizar db.[[TABELA]].find().
> db.aluno.find()
{ “_id” : ObjectId(“5a02e14ef52458010bddaf80”), “nome” : “Luis Fernando Chaim”, “dataNasc” : ISODate(“1972-05-22T00:00:00Z”) }
> db.aluno.find({nome: ‘Luis Fernando Chaim’})
Exemplos
db.professores.insert({nome: ‘Jean’, idade:26, disciplinas:[‘Tecnicas de Programacao’, ‘Topicos Avancados’], sexo: ‘m’})
db.professores.insert({nome: ‘John’, idade:46, disciplinas:[‘Tecnicas de Programacao’, ‘Topicos Avancados’], sexo: ‘m’})
db.professores.insert({nome: ‘Joseph’, idade:53, disciplinas:[‘Tecnicas de Programacao’, ‘Topicos Avancados’], sexo: ‘m’})
db.professores.find()
Então nosso comando find() nos retornará a lista de todos os registros. Se eu quiser passar alguma cláusula para a busca, posso fazer da seguinte forma:
db.professores.find({nome: ‘Jean’})
//db.professores.find({nome: ‘Jean’, idade:26})
Lembrando que se nossa consulta for falsa, ele não escreverá nenhum resultado, como podemos ver na tela abaixo:
Para fazermos comparações entre valores, usaremos uma sintaxe um pouco diferente. Vamos ter como exemplo a busca por professores com idade acima de 30 anos.
db.professores.find({idade: {$gt:30}})
Como podemos notar com o exemplo, utilizamos um operador condicional o $gt que significa great than, ou maior que, em português.
Também podemos usar os seguintes operadores condicionais: $gte, $lt, $lte, $all, $in, $nin, $ne, $exists, $mod
Ou seja podemos ver que na função find() podemos passar 1 paramêtro que vai fazer a comparacao de valores para delimitar a busca. Tendo em vista que se utilizarmos operadores de comparação como >, >=, <, <= e outros, teremos que usar a seguinte regra:
db.collection.find({campo: {$operador: valor}})
Podemos passar um paramêtro para a comparação de valores, mas também posso passar outro parâmetro, informando quais campos eu quero que retornem na busca; neste caso, nosso exemplo ficará:
db.collection.find({campo: {$operador: valor}}, {campo1: 1, campo2: 1, campoN: 1})
Como visto no exemplo acima ele sempre retorna o _id de cada registro, para que isto não ocorra podemos repassar no paramêtro dos campos _id:0
Porém, caso eu não queira comparar nenhum valor, terei que passar null no primeiro paramêtro, podendo ficar da seguinte maneira:
db.collection.find(null, {campo1: 1, campo2: 1, campoN: 1})
Uma outra função bem útil é a ordenação da busca, que se assemelha ao ORDER BY do SQL. No MongoDB temos a função sort() que recebe um paramêtro para ordernar.
db.collection.find(null, {nome:1, idade:1, _id:0}).sort({idade:1})
Onde passaremos o 1 paras ASC ou seja, do menor para o maior, ou -1 que é o DESC, do maior para menor.
Além de ordenar, também podemos limitar a busca, parecido com o LIMIT do SQL, passando um valor inteiro para a função limit().
db.collection.find(null, {nome:1}).sort({idade:1, nome:-1}).limit(2)
Outra função que auxilia ao limit() é a skip(), que receberá um valor inteiro para pular até aquele registro. Até agora, nossas funções convertidas em SQL ficam assim:
select nome, idade from professores ORDER BY idade ASC LIMIT1,2
Bom, já aprendemos como inserir dados e listá-los esta na hora de modificarmos os registros. Para isto, utilizamos a função update({busca}, {atualizacao}).
Assim como temos o modificador $set, também temos o $unset, que elimina a chave.
db.professores.update({nome: ‘Jean’}, {$unset: {disicplinas: 1}})
Também podemos apenas incrementar ou decrementar um valor inteiro utilizando o modificador $inc
db.professores.update({nome: ‘Jean’}, {$inc: {idade: 5}})
//incrementa em 5 a idade do professor Jean
db.professores.update({nome: ‘Jean’}, {$inc: {idade: -5}})
//incrementa em 5 a idade do professor Jean
Agora para removermos documentos, utilizamos a função remove(json). Onde passamos como parâmetro a clausula de comparação.
Porém, caso queiramos limpar toda a collection, é mais rapido usando drop()
Instalar MongoDB no Ubuntu
Introdução
Este post demonstra a instalação do MongoDB no Ubuntu.
Procedimento
- Importar a chave oficial do MongoDB
- sudo apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv 0C49F3730359A14518585931BC711F9BA15703C6
- Atualizar a lista de atualizações
- sudo apt-get update
- Instalando MongoDB
- sudo apt-get install mongodb-org
- O item 3 não funcionou no meu Ubuntu 17, então substitui o comando para
- sudo apt-get install mongodb
- Criar pasta /data/db e fornecer permissão de escrita
- sudo chmod 775 -R /data
- Subindo servidor
- sudo mongod
- Baixando servidor
- sudo mongod stop
- Verificando serviço
- ps -ef|grep mongo