Consultas MongoDB

Pelo facto de terem sido embutidos os documentos, apenas será necessária uma consulta. Em relação à primeira consulta, ordena-se o arrdelay por ordem descendente e seleciona-se o primeiro registo.

No seguinte código é possivel então visualizar a consulta efetuada. db.teste.find({}, {

"tailnum.tailnum": 1}).sort({"arrdelay":-1}).limit(1) Relativamente à segunda consulta, como os dados do manufacturer e do tailnum estão num sub-documento e se pretende que não haja repetições dos aviões, é necessário efetuar a consulta desta forma que é equivalente ao distinct em Sql.

db.runCommand({ "distinct": "teste", "query": { "tailnum.manufacturer": "BOEING", "diverted": "1" }, "key": "tailnum.tailnum" });

Relativamente à última consulta também é necessário consultar sub-documentos e retornar valores únicos, então o código foi realizado da seguinte forma.

db.runCommand({

"distinct": "teste", "query": {

Benchmarking _____________________________________________________________________________

"origin.airport": "San Francisco International", "dest.airport": "Philadelphia Intl",

“cancelled”: “0” },

"key": "tailnum.model" });

4.3 Consultas CouchDB

Para efetuar as consultas no CouchDB é necessária, em primeiro lugar, a criação de uma

view em javascript sobre aquilo que é pretendido consultar e, de seguida, através de um url

consultar a view pretendida.

Na primeira consulta foi criada uma view com os parâmetros tailnum e arrdelay que vão ser retornados na consulta.

function(doc){

emit([doc.tailnum.tailnum, doc.arrdelay], 1); }

De seguida, foi criada uma função reduce, isto para retornar o maior valor de arrdelay. function(keys, values, rereduce) {

var max = 0,

ks = rereduce ? values : keys;

for (var i = 1, l = ks.length; i < l; ++i) { if (ks[max][0][1] < ks[i][0][1]) max = i; }

return ks[max]; }

Agora efetua-se uma consulta à view criada e é retornado o maior valor de arrdelay, bem como o avião associado.

127.0.0.1:5984/tese1/_design/teste1/_view/tese16

O campo tese1 diz respeito à base de dados, o campo teste1 diz respeito ao nome do conjunto das views e o campo tese 16 diz respeito à view que foi explicada anteriormente.

Na segunda consulta foi criada uma view com os parâmetros manufacturer = “BOEING” e diverted = “1” que é o que se pretende consultar e como retorno o tailnum.

A view criada foi a seguinte: function(doc) {

if(doc.tailnum.manufacturer == "BOEING" && doc.diverted == 1) {

Benchmarking _______________________________________________________________________________ 62 emit(doc.tailnum.tailnum, null); } }

Como se pretendia que não existissem tailnum repetidos, foi criada a função reduce para permitir retornar valores únicos.

function(key, values) { return null;

}

De seguida, fez-se uma querie à view para obter o resultado da consulta.

127.0.0.1:5984/tese1/_design/teste1/_view/tese14?group=true O valor tese1 é o nome da base de dados, o nome teste1 é o nome do conjunto das views e o nome tese14 é o nome da view apresentada anteriormente.

Em relação ao group=true, este separa o valor reduce para cada chave única no map, e todos os valores que partilham a mesma chave são agrupados e reduzidos para um único valor, eliminando assim os repetidos.

Na terceira consulta a view foi criada com os aeroportos de origem = “San Francisco International” e destino = “Philadelphia Intl” e com o cancelled = “0” e como retorno o modelo de avião.

function(doc) {

if(doc.origin.airport == "San Francisco International" && doc.dest.airport == "Philadelphia Intl" && doc.cancelled == "0") {

emit(doc.tailnum.model, null); }

}

Como também era pretendido que não houvesse repetição de modelos a mesma função

reduce foi utilizada.

function(key, values) { return null;

}

A querie feita à view foi a seguinte.

Benchmarking _____________________________________________________________________________

4.4 Criação de Índices

Com vista a aumentar o desempenho nas consultas foram criados índices nos campos utilizados por estas. Relativamente ao MySQL foram criados índices nos campos utilizados nas três consultas, nomeadamente, cancelled, arrdelay, airport, diverted, model, tailnum e manufacturer. Na seguinte figura está representado um exemplo da criação de um índice no

MySQL relativamente ao campo airport.

Figura 25 - Criação de um índice no MySQL

Já em relação ao CouchDB, as views criadas já fazem o papel de um índice.

Relativamente ao MongoDB os índices utilizados foram na primeira consulta, simples, e nas consultas dois e três compound indexes, em que todos os campos são indexados no mesmo índice.

Para a primeira consulta, foi criado um índice sobre o arrdelay por ordem descendente visto que na consulta é pretendido o valor maior.

 db.teste.createIndex({"arrdelay": -1})

Na segunda consulta foi criado um compound index em todos os campos utilizados nas consultas.

 db.teste.createIndex({"tailnum.tailnum": 1, "tailnum.manufacturer": 1, "diverted": 1})

Na terceira consulta foi criado também um compound index em todos os campos.

 db.teste.createIndex({"origin.airport": 1, "dest.airport": 1, "tailnum.model":1, "cancelled": 1})

Benchmarking

_______________________________________________________________________________

64

4.5 Resultados

Agora será analisado o desempenho das duas bases de NoSql (MongoDB e CouchDB) e Relacional (MySQL). Para tal foram usados vários tamanhos de bases de dados. A BD1 possui um milhão e meio de registos, a BD2 possui quarto milhões e setecentos mil registos, a BD3 possui cerca de quinze milhões de registos e, por fim, a BD4 possui cerca de quarenta e um milhões de registos. Posteriormente, por cada consulta será avaliado o desempenho das três bases de dados em estudo (MongoDB, CouchDB e MySQL).

4.5.1 Consulta 1

No seguinte gráfico estão representados os resultados de desempenho nas três bases de dados relativamente à consulta 1.

Figura 26 - Comparação de desempenhos na Consulta 1

4.5.2 Consulta 2

No seguinte gráfico estão representados os resultados de desempenho das três bases de dados relativamente à consulta 2.

Benchmarking _____________________________________________________________________________

Figura 27 - Comparação de desempenhos na Consulta 2

4.5.3 Consulta 3

No seguinte gráfico estão representados os resultados de desempenho nas três bases de dados relativamente à consulta 2.

Figura 28 - Comparação de desempenhos na Consulta 3

4.6 Discussão de Resultados

Relativamente à consulta um, não existem diferenças substanciais entre as três bases de dados em estudo. Com o aumento da quantidade de registos nota-se um ligeiro aumento de

Benchmarking

_______________________________________________________________________________

66

tempo, mas mesmo assim os tempos são bastantes semelhantes entre os vários tamanhos de base de dados, o que revela um bom desempenho com funções de agregação. De referir apenas que o CouchDB na base de dados maior demorou quase o dobro do tempo na consulta comparado com as restantes, mas ainda assim o tempo é bastante reduzido. Relativamente à consulta dois, os resultados de tempos são ótimos mas o facto de recorrer a mais de uma tabela começa a afetar o desempenho no MySQL, aumentando o tempo de consulta conforme o tamanho de dados aumenta. Começa-se a notar também a diferença para o MongoDB e o CouchDB principalmente na BD4 que aponta para um melhor desempenho das bases de dados NoSql em estudo, conforme o volume de dados aumenta. Contudo, os resultados quase que são apresentados instantaneamente nos quatro tamanhos de bases de dados, o que revela um bom desempenho. Entre o MongoDB e o CouchDB, nestas consultas, não existem muitas diferenças a nível de desempenho sendo até bastante semelhantes. A única diferença significativa entre estes foi o facto de no CouchDB ser necessária a criação de views antes da consulta, sendo este um processo moroso uma vez que as bases de dados possuíam milhões de registos, mas que se refletiu num bom desempenho após a criação da view. Relativamente ao MySQL, a diferença chega a ser notória nas tabelas do gráfico da consulta dois comparativamente às duas bases de dados

NoSQL, notando-se uma perda de desempenho ao nível que o volume de dados aumenta,

enquanto que no MongoDB e no CouchDB os tempos permanecem semelhantes.

De referir que na terceira consulta a mais complexa notou-se uma diferença, pois o facto de recorrer a bastantes tabelas resultou em tempos muito distintos para a realização da consulta, principalmente a partir da BD3, a qual possui cerca de quinze milhões de registos.

Com a análise efetuada é possível concluir que a utilização de documentos embutidos no

MongoDB e no CouchDB, onde todos os dados se encontram no mesmo sítio, ao contrário

do MySQL que possui os dados em várias tabelas, leva a um aumento de desempenho. Também é possível concluir que quanto maior a quantidade de dados, maior é a diferença de tempos entre o MongoDB e o CouchDB em relação ao MySQL, o que revela que as bases de dados NoSql são uma boa aposta no que diz respeito a enormes volumes de dados e que o MySQL para responder ao Big data em que o volume de dados é gigantesco, provavelmente perderia desempenho comparado com as bases de dados NoSql em estudo. Relativamente às duas bases de dados NoSql, é de salientar que no MongoDB apenas se criaram índices que em comparação às views criadas no CouchDB foi um processo mais rápido, o que revela uma superioridade do MongoDB em relação ao CouchDB.

Testes de Carga _____________________________________________________________________________