CouchDB e versionamento de documentos

12

Atualmente, estou trabalhando em um aplicativo wiki-esque usando o CouchDB e estou tentando implementar um esquema de versão de documentos. Na minha opinião, existem duas maneiras de fazer isso:

Armazene cada versão como um documento separado
Armazene versões mais antigas como anexos em um único documento.

No momento, tenho uma forma de # 1 funcionando. Quando um usuário edita um documento e o salva, o back-end primeiro copia a revisão anterior para um novo documento e, em seguida, salva a nova versão. Cada documento possui uma matriz de 'histórico' que contém dados em cada versão (o documento _id da versão antiga, um carimbo de data e hora, o editor etc.).

Como essa matriz de histórico pode ficar bastante longa para um documento atualizado com freqüência, eu tenho uma visão que busca um documento sem história durante uma leitura normal (e outra visão para buscar a história).

Minha pergunta é a seguinte: sinto-me desconfortável com a minha abordagem atual e tenho pensado em mudar para o método 'anexo'. Mas eu não tenho certeza. Espero que alguém que conheça o CouchDB melhor do que eu (eu estive nisso há algumas semanas - e este é o meu primeiro projeto usando o CouchDB ... e o NoSQL) possa me dizer quais são os prós e os contras de cada um. abordagem. Ou talvez haja algum outro esquema de versão que estou ignorando?

database-design couchdb

— James Adam
fonte

2

Embora eu não possa falar sobre o impacto no desempenho, o sistema que você está usando está "espiritualmente" alinhado ao CouchDB. O armazenamento de versões anteriores como uma hierarquia de resposta é idiomático, como é o "ancestral espiritual" do CouchDB, o banco de dados de documentos do Lotus Notes (NSF) (Damien Katz trabalhou profundamente em uma antes de desenvolver a outra, mantendo e melhorando o melhor dela). enquanto lançando os requisitos de compatibilidade cruft e para trás / bugward, muitas das questões estruturais mais básicos terão respostas em Notes).

2

Armazenar apenas alterações será uma boa idéia, porque armazenar documentos antigos como documentos separados ou anexos à revisão final do banco de dados criará uma sobrecarga no servidor de banco de dados.

Sempre que você alterar um valor de chave no seu documento, adicione uma nova chave com o nome _h_i_s_<key_name>. No recém-criado (ou criado durante a última atualização), acrescente objetos como abaixo após cada edição / atualização: -

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

ou

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

Essa abordagem economizará muito espaço em disco e largura de banda de replicação a longo prazo.

— Ravinder Payal
fonte

0

Sem nenhum conhecimento do CouchDB. Armazenar todas as versões, embora possa diferir apenas marginalmente do seu antecessor, é um desperdício de armazenamento. Eu recomendo armazenar apenas alterações.

Você pode dar uma olhada aqui ou procurar versões de dados.

— xuma202
fonte

Esta resposta não diz qual opção 1 (documentos separados) ou 2 (como parte do documento) é melhor.

— binki

0

anos depois ;-)

você não precisa armazenar as alterações porque o CouchDB fará isso por você. Se um documento for alterado, uma nova revisão será criada. Esteja ciente de que este é fisicamente outro documento com o mesmo, _idmas um novo _rev(revisão) e consumirá espaço no seu disco.

Com certeza, você teria que manter todas as revisões, o que significaria, que você precisa de um disco muito grande.

— awenkhh
fonte