3.4.1
Paralelizac¸˜ao de operac¸˜oes nos diversos espac¸os de tuplos
As primeiras vers˜oes do DepSpace [5, 35] realizam apenas uma operac¸˜ao de cada vez, o que se torna o sistema ineficiente se considerarmos que as operac¸˜oes devem ser escritas para disco (c.f., secc¸˜ao 3.2.1).
Este novo paradigma levou a que alter´assemos o DepSpace para executar batches de operac¸˜oes nos seus espac¸os de tuplos.
Assim, quando recebe um batch de mensagens para os seus diversos espac¸os de tu- plos, o DDS divide-o em v´arios batches, cada um contendo as operac¸˜oes relativas a um ´unico espac¸o de tuplos (c.f., figura 3.4). Esses batches s˜ao depois entregues aos respec- tivos espac¸os de tuplos, que executam todas as operac¸˜oes e devolvem um batch com os resultados das operac¸˜oes executadas. O DDS ordena os resultados, pela ordem em que re- cebeu as operac¸˜oes, num ´unico batch e entrega-o `a camada de replicac¸˜ao, para que sejam encaminhados para os respectivos clientes.
Figura 3.4: Execuc¸˜ao s´ıncrona (`a esquerda) e paralela (`a direita) de operac¸˜oes nos diversos espac¸os de tuplos do DepSpace.
3.4.2
Optimizac¸˜ao das operac¸˜oes de leitura e remoc¸˜ao de tuplos
A implementac¸˜ao inicial do DepSpace considerava um espac¸o de tuplos como sendo uma lista de tuplos. Com a construc¸˜ao do DDS, a utilizac¸˜ao destas listas passou a constituir um problema, j´a que imp˜oem uma maior latˆencia em operac¸˜oes como a remoc¸˜ao ou leitura de tuplos. Esta maior latˆencia prov´em do facto de ser necess´ario percorrer todos os elementos na lista, at´e encontrar o tuplo que pretendemos remover ou ler.
Como um servic¸o de coordenac¸˜ao ´e utilizado maioritariamente para leituras de dados [11, 20], ´e importante que estas operac¸˜oes de leitura sejam r´apidas, de modo a aumentar o desempenho do sistema.
Assim, cri´amos duas novas implementac¸˜oes de espac¸os de tuplos que utilizam n ´ındices, para facilitar a pesquisa de um tuplo. Cada ´ındice i ´e composto por uma lista com todos os tuplos que tˆem apenas i campos e por um mapa com v´arias entradas. Cada
Cap´ıtulo 3. DDS – Durable DepSpace 33
uma destas entradas faz a correspondˆencia entre uma chave e um valor, como mostra a figura 3.5. A chave do mapa ´e h, que ´e o hash do i-´esimo campo de um tuplo inserido, e o valor ´e o mapa do ´ındice i + 1 que mapeia os (i + 1)-´esimos campos dos tuplos cujo hash do i-´esimo campo ´e h. A diferenc¸a entre as duas implementac¸˜oes reside na ordenac¸˜ao dos elementos dos mapas, sendo que uma das implementac¸˜oes utiliza ´ındices ordenados, atrav´es do uso de TreeMaps [33], e a outra utiliza ´ındices n˜ao ordenados, atrav´es do uso de HashMaps [30].
Figura 3.5: Espac¸o de tuplos com ´ındices.
Na pesquisa de um tuplo com x campos, em que x > 0, o sistema compara o campo i do tuplo com o elementos do ´ındice i do espac¸o de tuplos, at´e chegar ao ´ındice x, caso x < n, ou n, se x ≥ n.
Depois de encontrar a lista onde poder´a estar o tuplo pretendido, o sistema compara apenas os campos que n˜ao se encontram nos ´ındices (c.f. figura 3.5).
A adopc¸˜ao destes novos espac¸os de tuplos permite ao DDS obter um maior d´ebito de operac¸˜oes de remoc¸˜ao / leitura de tuplos, em comparac¸˜ao com o DepSpace original, conforme os resultados apresentados no cap´ıtulo 4.
3.4.3
Locking
A biblioteca BFT-SMaRt [41], permite a execuc¸˜ao de operac¸˜oes de leitura sem serem ordenadas pelo seu protocolo de ordenac¸˜ao de mensagens. Isto significa que, enquanto o DDS executa um batch de mensagens ordenadas (p.ex.,adic¸˜ao e remoc¸˜ao de tuplos), podem chegar v´arias operac¸˜oes de leitura ao sistema.
Cap´ıtulo 3. DDS – Durable DepSpace 34
Dado que estas operac¸˜oes n˜ao ordenadas tˆem de ser executadas em paralelo com as ordenadas, ´e necess´ario um mecanismo de controlo que mantenha a coerˆencia do estado e que garanta que a ordem correcta de todas as operac¸˜oes. No caso de existir uma operac¸˜ao que insere um tuplo R num espac¸o de tuplos, qualquer operac¸˜ao de leitura de R que seja executada ap´os a sua escrita deve conseguir lˆe-lo. Sem um mecanismo de controlo de acesso aos espac¸os de tuplos, uma operac¸˜ao de leitura de R feita concorrentemente com a sua escrita poderia n˜ao conseguir ler o tuplo, j´a que as operac¸˜oes de leitura n˜ao s˜ao ordenadas com as de escrita.
Foram ent˜ao implementados dois tipos de mecanismos de controlo (moderate e ex- treme locking), que oferecem diferentes tipos de garantias de controlo no DDS.
Moderate locking. Este mecanismo de controlo ´e implementado ao n´ıvel do espac¸o de tuplos. Cada ´ındice do espac¸o de tuplos (ver secc¸˜ao 3.4.2) possui um lock que pode ser adquirido para leitura, podendo ser partilhado por v´arios clientes do DDS, ou escrita, em que apenas um cliente adquire este lock para actualizar o espac¸o de tuplos.
Numa primeira fase de pesquisa, os locks s˜ao adquiridos para leitura, sendo apenas adquiridos para escrita quando existe uma escrita ou remoc¸˜ao de tuplos ou de elementos de um ´ındice.
O problema do moderate locking ´e que um tuplo pode ser lido por um cliente antes de ser escrito para disco. No entanto, na ocorrˆencia de uma falha total no sistema antes de o tuplo ser escrito para disco, este n˜ao ´e recuperado quando o sistema reinicia.
Assim, um cliente tente ler um tuplos antes e depois de uma falha total, vai obter dois resultados diferentes, o que torna o sistema inconsistente.
Extreme locking. O extreme locking resolve o problema do moderate locking atrav´es do lockingdo sistema logo na recepc¸˜ao de mensagens. Assim, as operac¸˜oes n˜ao ordenadas s´o executam ap´os as operac¸˜oes ordenadas e vice-versa.
Por´em, este mecanismo faz com que o d´ebito do sistema diminua, pois o n´umero de operac¸˜oes n˜ao ordenadas que s˜ao executadas diminui.