Figura 12.: Migrac¸˜ao de dados entre r´eplicas
O MongoDB permite que seja poss´ıvel ler dados de r´eplicas secund´arias. Quando isto acontece o MongoDB torna-se inevitavelmente consistente e, assim, ´e poss´ıvel ler resultados desatualizados. Isto ´e, como a replicac¸˜ao dos dados da r´eplica principal para as secund´arias ´e efetuada de forma ass´ıncrona os dados que se encontram na secund´aria podem n˜ao ser
os da operac¸˜ao de escrita mais recente. Recorre-se `a Figura12para exemplificar a descric¸˜ao
acima. Num sistema com duas r´eplicas, a principal (a) e a secund´aria (b), em que ambas tˆem o valor de X definido como 2, o Actor (A) atualiza o sistema com o valor de X igual a
3(instruc¸˜ao 1). A r´eplica principal (a) ´e atualizada para o valor de X igual a 3. Antes que a
alterac¸˜ao fosse propagada para a r´eplica secund´aria (b) o Actor (A) questiona a secund´aria para saber o valor de X (instruc¸˜ao 2). A r´eplica secund´aria (b) devolve o valor de X que possu´ıa no momento que neste caso era 2. S ´o depois o valor de X foi atualizado para 3 (instruc¸˜ao 4). Com isto, apesar de o valor de X na principal j´a ser 3, a leitura por parte do Actor (A) devolveu o valor anterior. Se ap ´os a instruc¸˜ao 4 fosse efetuada novamente a instruc¸˜ao 2 o resultado seria o mais recente. Desta forma ´e explicado o conceito de inevitavelmente consistente em MongoDB.
2.5 a c i d v s b a s e
Segundo o s´ıtio do neo4j24
, os dois modelos mais comuns que envolvem o aspeto da con- sistˆencia s˜ao definidos pelos acr ´onimos ACID e BASE. As propriedades das transac¸ ˜oes ACID foram durante anos consideradas padr˜ao, uma vez que se reconhece ser cr´ıtico a existˆencia deste tipo de organizac¸˜ao em aspetos que se relacionam com a perda de dados, sendo uma caracter´ıstica requerida para a garantia da consistˆencia de dados em aplicac¸ ˜oes do mercado financeiro, sa ´ude e informac¸˜ao confidencial, tal como se pode ver
Cap´ıtulo 2. bases de dados
pela informac¸˜ao dispon´ıvel no s´ıtio do MarkLogic25
. Segundo Brewer (2012), as proprie-
dades ACID focam-se sobre aspetos de consistˆencia sendo essenciais em qualquerBDdita
tradicional. A relac¸˜ao entre CAP e ACID ´e, por´em, um pouco mais complexa, e mal en-
tendida, uma vez que o A e o C em CAP n˜ao significam o mesmo que em ACID (Brewer,
2012).
2.5.1 ADIC
Quando um sistema de processamento de transac¸ ˜oes cria uma transac¸˜ao este tem de ga- rantir que as transac¸ ˜oes possuem certas caracter´ısticas. Estas caracter´ısticas s˜ao conhecidas
como propriedades ACID (Francis et al., 1998). As propriedades ACID s˜ao um conceito
bastante importante no que toca aBDs. Qualquer alterac¸˜ao de uma transac¸˜ao que afete o
sistema ou ´e completamente efetuada ou simplesmente n˜ao acontece e todos os passos s˜ao regredidos e ´e preservado o estado inicial.
As propriedades das transac¸ ˜oes ACID s˜ao as seguintes:
ATOMICIDADE (Atomicity). Uma dada transac¸˜ao ser´a executada na totalidade ou nenhum
dos passos ser´a executado.
CONSIST ˆENCIA (Consistency). Ap ´os uma transac¸˜ao aBD encontra-se estruturalmente con-
sistente.
ISOLAMENTO (Isolation). Quando est´a a decorrer uma transac¸˜ao, esta n˜ao ´e afetada por
outra transac¸˜ao concorrente. Os acessos a dados s˜ao controlados pelaBDpara que as
transac¸ ˜oes parec¸am, de certa forma, sequenciais.
DURABILIDADE (Durability). Os dados que foram guardados n˜ao s˜ao perdidos. Isto ´e, o
resultado de uma transac¸˜ao ´e permanente.
Voltando `a comparac¸˜ao entre o MarkLogic e o MongoDB, s˜ao claras algumas conclus ˜oes. O MarkLogic ´e ACID bem como o MongoDB. Por´em, este ´ultimo ´e ACID ao n´ıvel do docu- mento, mas n˜ao o ´e ao n´ıvel de multidocumentos. Segundo o pr ´oprio website, o MarkLogic ´e ACID, visto que recorre a locks nos documentos durante a realizac¸˜ao de operac¸ ˜oes de alterac¸˜ao. Para al´em disso, consegue fazer com que as transac¸ ˜oes fiquem livres de conflitos.
Esta BD possui, ainda, marcas temporais (timestamps) ao n´ıvel dos documentos de forma
a assegurar que numa interrogac¸˜ao apenas s˜ao vistos os documentos v´alidos no espac¸o temporal em que esta decorre. Adicionalmente, no MarkLogic s˜ao guardados os registos das alterac¸ ˜oes a serem feitas antes de serem realizadas as mesmas para assegurar que estas podem ser feitas novamente em caso de falha no sistema. Por fim, ´e feito um processo
25 MarkLogic website:http://www.marklogic.com/what-is-marklogic/features/acid-transactions/
2.5. ACID VS BASE
de confirmac¸˜ao que garante que os dados a alterar sejam alterados de uma s ´o vez ou de maneira nenhuma, ocorrendo isto para todas as r´eplicas.
Por´em, no MongoDB o processo ´e um pouco diferente. O conceito de ACID ´e limitado. Ao n´ıvel do documento as transac¸ ˜oes s˜ao ACID. Isto ´e, quando a alterac¸˜ao ´e feita ao n´ıvel de um ´unico documento o modelo ACID aplica-se. Nesses casos ´e feito um lock sobre o documento at´e estar conclu´ıda a alterac¸˜ao. Se a alterac¸˜ao a efetuar incidir sobre v´arios documentos, isto j´a n˜ao ´e aplic´avel, porque enquanto ´e alterado um dado documento A, uma qualquer outra instruc¸˜ao pode estar a alterar um documento B.
2.5.2 BASE
As propriedades BASE visam acompanhar as abordagens com esquemas de alto desempe- nho. Os grandes sistemas que s˜ao baseados no CAP, mas n˜ao no ACID, s˜ao BASE. Ora,
o BASE nasceu do facto de, segundo Pritchett (s.d.), em BDsdistribu´ıdas, haver a neces-
sidade de trocar parte da consistˆencia por disponibilidade, de forma a se obter melhores caracter´ısticas em termos de escalabilidade. O ACID forc¸a a consistˆencia, mas o BASE
aceita que a consistˆencia da BDseja atingida. Como as grandes aplicac¸ ˜oes atuais, em par-
ticular as especialmente direcionadas para a web, movimentam uma quantidade de dados muito grande, estas n˜ao conseguem manter todas as propriedades ACID. Assim, de forma a atingir bons n´ıveis de desempenho, os programadores de aplicac¸ ˜oes est˜ao dispostos a sacrificar uma propriedade.
O BASE est´a focado na disponibilidade e no desempenho, elementos cr´ıticos numa aplicac¸˜ao web. Com isto, o BASE sacrifica a consistˆencia, que ser´a atingida algures ao longo do tempo. As propriedades do BASE s˜ao as seguintes:
DISPONIBILIDADE B ´ASICA (Basically Available), que significa que a BD parece funcionar a
maior parte do tempo.
ESTADO LEVE (Soft-State), isto deve-se ao facto de as escritas n˜ao terem de ser consistentes
nem as r´eplicas coerentes durante todo o tempo.
INEVITAVELMENTE CONSISTENTE (Eventually Consistent), que significa que a dado momento o
sistema torna-se consistente.
Quando no MongoDB se coloca a possibilidade de obter leituras a partir das r´eplicas, este torna-se ”inevitavelmente consistente” (como visto anteriormente).
3
P R O C E S S A M E N T O D E Q U E R I E S
O processamento de queries ´e o ato de converter um determinado crit´erio definido numa
linguagem num conjunto de comandos base de umaBD. Para al´em disso, o processamento
de queries integra uma etapa na qual ´e necess´ario escolher o m´etodo mais eficiente para ob- ter os resultados correspondentes ao crit´erio usado. Esta forma de processar interrogac¸ ˜oes
´e cada vez mais diferente entre os diferentes SGBDs. Algo que hoje j´a ´e muito not ´orio,
quando nos posicionamos nos ambientes dasBDNRs.
NasDBRs, as interrogac¸ ˜oes s˜ao, na generalidade, efetuadas recorrendo `a linguagemSQL.
No entanto isso n˜ao se verifica na maioria das BDNRs, nem nas DSs que vamos utilizar
nesta dissertac¸˜ao. Em MongoDB as queries efetuadas emJStˆem um ciclo de processamento
diferente daquele que se verifica, por exemplo, na BDR da Oracle. Neste sistema o pro-
cessamento ´e dividido, em termos gerais e segundo Anh (2009), em trˆes fases: traduc¸˜ao,
otimizac¸˜ao e execuc¸˜ao. A forma com as queries s˜ao processadas em MongoDB ser´a anali- sada j´a de seguida.
3.1 e ta pa s d e p r o c e s s a m e n t o d e u m a q u e r y
O processamento de uma query em MongoDB divide-se, inicialmente, em duas fases, a fase de planeamento e a fase de execuc¸˜ao. Na primeira, o motor de processamento pretende descobrir a melhor forma de executar uma determinada query, isto ´e, o que ´e necess´ario fazer, em que ordem e de que forma. A segunda fase, que depende da anterior, executa o plano escolhido durante a fase de processamento. Para isso, quando poss´ıvel, s˜ao utili- zados os ´ındices da colec¸˜ao afeta `a query, sendo depois feita uma travessia sobre estes de
forma a obter os resultados. Na Figura 13 podemos ver as diversas fases que comp ˜oem o
Cap´ıtulo 3. processamento de quer ies
Figura 13.: Query Plan - Adaptac¸˜ao do website do MongoDB
O Query Plan do MongoDB ´e um conjunto de passos que s˜ao executados para que se possa obter os dados. Tendo em conta a figura anterior, vejamos ent˜ao como as coisas acontecem. Inicialmente, no ponto A ´e enviada uma query para ser processada. Por´em, para que seja poss´ıvel compreender a fase que se segue - (a) - ´e necess´ario recuar um pouco
e explicar o funcionamento b´asico de uma query simples. Na Figura14 ´e poss´ıvel ver uma
query que se pretende que seja processada pelo MongoDB, recorrendo a c ´odigo emJS.