carlosc20 / transactional-middleware-for-nosql Goto Github PK

A operação de scan de momento apenas devolve os valores das chaves. Precisa de devolver o timestamp global da db juntamente com esse conjunto de valores.

Como lídar com falhas ao dar flush para a BD

force GC para clientes lentos. Utilizar timestamp de tempo real global para cada commitTS que terá de ser propagado do líder para as réplicas

Tentar perceber como é que o mongodb executa queries do mesmo cliente, ou seja, se as consegue executar em paralelo ou precisamos de ter vários clientes/conexões.
Se conseguir executar pedidos do mesmo cliente em paralelo então precisamos de garantir que o update do timestamp é incremental. Para isso podemos escrever os tuplos chave/valor à vontade, mas as escritas dos timestamps terão de ser sequenciais, mas assíncronas às escritas dos tuplos. O driver só devolve a resposta quando ambos estão completos.

Ideias iniciais:

Estabelecer um grupo entre os servidores NPVS. Os servidores apercebem-se das falhas uns dos outros. Quando um servidor está a iniciar pergunta aos vizinhos se foi abaixo.

1ª opção:

Se tiver ido abaixo coloca-se num estado de "alerta" e pede ao cluster RAFT o timestamp atual para conseguir saber o timestamp em que está a dar reboot e ficar correto. Quando recebe o timestamp X passa para o estado "reboot on X".
Uma transação quando lê de um NPVS traz consigo o estado em que o servidor está. Se receber o estado "alerta" aborta logo, se receber "reboot on X" compara o X com o seu TS, se X for maior aborta senão continua.

2ª opção:

Ao ir abaixo informa o RAFT, que irá guardar no cluster o Timestamp em que esse servidor foi abaixo. Quando uma transação dá commit envia também os servidores de onde leu se o seu TS for inferior ao guardado para algum dos servidores de onde leu é abortada.
O npvs enquanto não receber confirmação do raft terá de adiar pedidos de leituras (guarda-os), para que uma transação incorreta não chegue antes da informação de que o servidor foi abaixo.

Comparação 1ª com a 2ª

• mais latência na leitura (em todas)

• reduz carga no líder RAFT porque podem dar abort no cliente
• transação aborta mal ocorra a falha. Não faz mais pedidos ao NPVS (menos carga)
• menos aborts
• permite omitir o commit em transações read only

dependerá da frequência de falhas

Como as respostas podem vir desordenadas em relação à ordem em que foram submetidas devemos ordena-las no que toca à consequente operação de update do certifier. Caso haja uma "gap" ela pode também ter ocorrido devido a falhas na escrita, por isso a bd pode estar inconsistente. Neste caso temos de ver talvez até com o prof se é correto dizer que a bd está numa versão mais avançada, mas numa versão anterior houve falhas.