Durabilidade é o "D" nas propriedades "ACID" (A - Atomicidade, C - Consistência, I - Isolamento), popularizado pelos sistemas tradicionais de gerenciamento de banco de dados relacional (RDBMS). Durabilidade é a garantia de que os dados gravados foram salvos e sobreviverão permanentemente. Bancos de dados NoSQL, como o MongoDB, oferecem aos desenvolvedores controle refinado sobre a durabilidade de suas chamadas de gravação. Isso permite que os desenvolvedores escolham diferentes modelos de durabilidade, segurança e desempenho para diferentes classes de dados. No entanto, isso também sobrecarrega o desenvolvedor para discernir e entender as nuances das diferentes opções de segurança de gravação. Neste post, veremos as diferentes opções de segurança de gravação fornecidas no driver Java.
Na linguagem do MongoDB, isso é chamado de “Write Concern”. As preocupações com a escrita variam de "fracas" a "fortes". Preocupações com gravações fracas podem levar a uma taxa de transferência mais alta, mas fornecem menos segurança de dados e as preocupações com gravações fortes são vice-versa.
O driver Java permite que você especifique suas opções de segurança de gravação usando vários construtores telescópicos. Aqui está o construtor com todas as opções:
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Como você pode ver, esse construtor tem muitas opções. Para tornar mais fácil para os desenvolvedores, “Tags” são fornecidas para valores comuns de preocupação de gravação – Não reconhecido, Reconhecido, Registrado em diário, Fsynced e Replica reconhecido. Cada tag mapeia para uma certa invocação do construtor acima.
Modo MongoDB não reconhecido
Este é o modo “dispare e esqueça”. O driver MongoDB não tenta confirmar o recebimento de operações de gravação. Por exemplo, se seu serviço MongoDB estiver inativo e você estiver usando esse modo, todos os erros serão ignorados silenciosamente e seus dados serão perdidos. Obviamente, você só deve usar esse modo para dados de baixo valor, onde a taxa de transferência de gravação é mais importante do que a perda de uma certa quantidade de dados. Este modo pode ser especificado da seguinte forma:
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Modo MongoDB reconhecido
Este é o modo de gravação padrão do MongoDB. Nesse modo, o driver MongoDB tenta confirmar o recebimento das operações de gravação no servidor, permitindo que o driver capture quaisquer erros de rede, erros de chaves duplicadas, etc. No entanto, isso não garante que os dados sejam salvos no disco. Se o servidor MongoDB travar após reconhecer a gravação, mas antes de confirmá-la no disco, os dados serão perdidos. Este modo pode ser especificado da seguinte forma:
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
Modo MongoDB registrado em diário
Neste modo, o servidor MongoDB reconhece a gravação somente após confirmar os dados no diário. Ao usar este modo, mesmo se o servidor travar na reinicialização do servidor, os dados são reaplicados do diário. Obviamente, o journaling precisa ser ativado para que isso funcione. Todos os sistemas de produção devem ter o journaling ativado, e você pode saber mais sobre isso em nossa postagem Você deve habilitar o journaling do MongoDB?
Em um cenário de conjunto de réplicas, as preocupações de gravação no diário se aplicam apenas ao primário. Por padrão, o diário é confirmado no disco a cada 100 ms. Quando você especifica uma gravação com a opção com diário, o diário é confirmado no disco em 30 ms. Portanto, se você especificar j:true para cada gravação, sua taxa de transferência será no máximo 1000/30 =33,3 gravações/s. Se você quiser uma taxa de transferência melhor, precisará agrupar suas atualizações e definir j:true para a última atualização do lote. Este modo pode ser especificado da seguinte forma:
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Modo MongoDB Fsynced
Neste modo, o servidor MongoDB reconhece a gravação somente após a gravação ser gravada no disco. Este modo pode ser especificado da seguinte forma:
new WriteConcern(true) / WriteConcern.FSYNCED
Modo MongoDB Reconhecido de Réplica
Os modos de segurança de gravação anteriores se aplicam apenas a um único servidor. Ao executar conjuntos de réplicas, você tem a opção de controlar quantas réplicas sua gravação precisa ser gravada antes de ser considerada bem-sucedida. Por exemplo, com uma preocupação de gravação de “w:2″, a gravação precisa ser gravada em um primário e pelo menos um secundário antes de ser considerada bem-sucedida. Isso reduz o rendimento, mas oferece melhor segurança. Se você não estiver ciente do número de réplicas de antemão, poderá usar a tag WriteConcern.MAJORITY para garantir que os dados sejam salvos na maioria das réplicas. Esta é a opção mais segura no MongoDB. Se você for usar essa opção, certifique-se também de definir o valor “wtimeout” para indicar quanto tempo o comando deve esperar antes de retornar a falha:
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
As seguintes tags foram obsoletas (ou planejam ser) – ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Por favor, use as opções mais recentes em vez dessas opções. Como sempre, se você tiver algum comentário ou dúvida, entre em contato conosco em [email protected].
