os valores, configurando-os adequadamente no Store: -JSON;-String-Java-Serialization (serializacao Java padrao);-Protobuf (serializacao do Goolge);-Identity (vetor de bytes).Consistencia e Versionamento Executando-se multiplas e simultaneas escritas distribuidas sobre multiplos servidores, a consistencia dos dados se torna um dificil problema. A solucao tradicional para este problema sao as Transacoes Distribuidas, mas que sao muito lentas e frageis pois necessitam de que todos os servidores estejam disponiveis durante o processo da transacao. Uma alternativa e tolerar a possibiliade da inconsistencia dos dados e trata-las durante o momento de sua leitura. Esta e a tecnica utilizada pelo Voldemort. As aplicacoes geralmente executam uma sequencia de acoes de leitura-modificacao-atualizacao ao se modificar dados. O valor de uma chave esta consistente se, na falta de atualizacoes, todas as leituras da chave retornam o mesmo valor. Num mundo de somente-leitura os dados sao criados de uma forma consistente e nao sao alterados. Quando adicionamos escritas e replicacao, encontramos diversos problemas: precisamos alterar multiplos valores em varias maquinas e deixar as coisas em um estado consistente. Com as falhas dos servidores, isto se torna muito dificil; com a presenca de particoes em rede isto se torna quase impossivel. Desta forma, o Voldemort utiliza Versionamento e Reparacao de Leitura, que oferece a melhor garantia de disponibilidade e a maior eficiencia possivel.Versionamento em Um Sistema Distribuido Uma solucao para um sistema simples de versionamento pode ser a utilizacao de somente uma trava otimista (armazenamos um unico valor contador ou relogio para cada dado e somente permitimos alteracoes quando apresentam os valores corretos de relogio). Isto funciona bem em um banco de dados centralizado, mas peca em um sistema distribuido onde os servidores aparecem e desaparecem e a replicacao pode levar um certo tempo. Para isto, um simples valor nao contem informacao suficiente de escrita para permitir-nos jogar fora versoes antigas. Uma resposta para isso e o chamado Vetor de Relogios de Versionamento. Um vetor de relogio de versionamento mantem um contador para cada escrita no servidor, nos permitindo calcular quando duas versoes estao em comflito e quando uma versao precede ou sucede outra. Um vetor de relogio de versionamento e uma lista de pares de servidor:versao, como no exemplo a seguir: [1:45, 2:3, 5:55]A versao indica qual servidor e o mestre para determinado numero de escritas. Um conflito de versoes pode ser visto a seguir: [1:2, 2:1] [1:1, 2:2]Camada de Persistencia O Voldemort suporta uma API simples de persistencia usando o BDB Java Edition como padrao. O MySQL e o amarzenamento em memoria tambem sao suportados. Para adicionar uma nova implementacao de persistencia voce precisa implementar os metodos de Put, Get, Delete e prover um Iterator sobre os valores do Store.Configuracao Existem 3 arquivos de configuracao que controlam as operacoes dos servidores do cluster do Voldemort:-Cluster.xml: Guarda as informacoes de todos os servidores (nos) do cluster. E o mesmo arquivo utilizado em todos os nos do cluster.-Stores.xml: Guarda as informacoes de todos os Stores (tabelas) utilizados no cluster. Contem informacoes sobre o numero requerido de leituras e escritas com sucesso para manter a sua consistencia, alem de como as chaves e valores serao serializados