Apache Cassandra e Azure Cosmos DB para níveis de consistência Apache Cassandra
APLICA-SE A: 
Cassandra
Ao contrário do Azure Cosmos DB, o Apache Cassandra não fornece nativamente garantias de consistência definidas com precisão. Em vez disso, o Apache Cassandra fornece um nível de consistência de gravação e um nível de consistência de leitura, para permitir as compensações de alta disponibilidade, consistência e latência. Ao usar o Azure Cosmos DB para Cassandra:
- O nível de consistência de gravação do Apache Cassandra é mapeado para o nível de consistência padrão configurado em sua conta do Azure Cosmos DB. A consistência de uma operação de gravação (CL) não pode ser alterada por solicitação.
- O Azure Cosmos DB mapeará dinamicamente o nível de consistência de leitura especificado pelo driver do cliente Cassandra. O nível de consistência será mapeado para um dos níveis de consistência do Azure Cosmos DB configurados dinamicamente em uma solicitação de leitura.
Gravações em várias regiões versus gravações em uma única região
O banco de dados Apache Cassandra é um sistema multimestre por padrão e não fornece uma opção pronta para gravações de região única com replicação de várias regiões para leituras. No entanto, o Azure Cosmos DB fornece a capacidade turnkey de ter configurações de gravação de região única ou de várias regiões . Uma das vantagens de poder escolher uma única configuração de gravação de região em várias regiões é evitar cenários de conflito entre regiões e a opção de manter uma forte consistência em várias regiões.
Com gravações de região única, você pode manter uma forte consistência e, ao mesmo tempo, manter um nível de alta disponibilidade entre regiões com failover gerenciado por serviços. Nessa configuração, você ainda pode explorar a localidade de dados para reduzir a latência de leitura fazendo downgrade para consistência eventual por solicitação. Além desses recursos, a plataforma Azure Cosmos DB também oferece a opção de redundância de zona ao selecionar uma região. Assim, ao contrário do Apache Cassandra nativo, o Azure Cosmos DB permite que você navegue pelo espectro de compensação do Teorema CAP com mais granularidade.
Mapear os níveis de consistência
A plataforma Azure Cosmos DB fornece um conjunto de cinco configurações de consistência bem definidas, orientadas a casos de uso de negócios em relação à replicação. As compensações para essas configurações de consistência são definidas pelos teoremas CAP e PACLC. Como essa abordagem difere significativamente do Apache Cassandra, recomendamos que você dedique algum tempo para analisar e entender a consistência do Azure Cosmos DB. Como alternativa, você pode revisar este pequeno guia de vídeo para entender as configurações de consistência na plataforma Azure Cosmos DB. A tabela a seguir ilustra os possíveis mapeamentos entre os níveis de consistência do Apache Cassandra e do Azure Cosmos DB ao usar a API para Cassandra. Esta tabela mostra configurações para leituras de região única, leituras de várias regiões com gravações de região única e gravações de várias regiões.
Mapeamentos
Nota
Estes não são mapeamentos exatos. Em vez disso, fornecemos os análogos mais próximos de Apache Cassandra, e desambiguamos quaisquer diferenças qualitativas na coluna mais à direita. Como mencionado acima, recomendamos revisar as configurações de consistência do Azure Cosmos DB.
ALL, EACH_QUOROM, QUOROM, LOCAL_QUORUM, ou THREE consistência de escrita no Apache Cassandra
| Consistência de leitura do Apache | Lendo de | Nível de consistência do Azure Cosmos DB mais próximo das configurações de leitura/gravação do Apache Cassandra |
|---|---|---|
ALL |
Região local | Strong |
EACH_QUOROM |
Região local | Strong |
QUOROM |
Região local | Strong |
LOCAL_QUORUM |
Região local | Strong |
LOCAL_ONE |
Região local | Eventual |
ONE |
Região local | Eventual |
TWO |
Região local | Strong |
THREE |
Região local | Strong |
Ao contrário do Apache e do DSE Cassandra, o Azure Cosmos DB confirma de forma duradoura uma gravação de quórum por padrão. Pelo menos três dos quatro (3/4) nós confirmam a gravação no disco e NÃO apenas um log de confirmação na memória.
ONE, LOCAL_ONEou ANY escreva consistência no Apache Cassandra
| Consistência de leitura do Apache | Lendo de | Nível de consistência do Azure Cosmos DB mais próximo das configurações de leitura/gravação do Apache Cassandra |
|---|---|---|
ALL |
Região local | Strong |
EACH_QUOROM |
Região local | Eventual |
QUOROM |
Região local | Eventual |
LOCAL_QUORUM |
Região local | Eventual |
LOCAL_ONE |
Região local | Eventual |
ONE |
Região local | Eventual |
TWO |
Região local | Eventual |
THREE |
Região local | Eventual |
A API do Azure Cosmos DB para Cassandra sempre confirma de forma durável uma gravação de quórum por padrão, portanto, todas as consistências de leitura podem ser usadas.
TWO consistência de escrita no Apache Cassandra
| Consistência de leitura do Apache | Lendo de | Nível de consistência do Azure Cosmos DB mais próximo das configurações de leitura/gravação do Apache Cassandra |
|---|---|---|
ALL |
Região local | Strong |
EACH_QUOROM |
Região local | Strong |
QUOROM |
Região local | Strong |
LOCAL_QUORUM |
Região local | Strong |
LOCAL_ONE |
Região local | Eventual |
ONE |
Região local | Eventual |
TWO |
Região local | Eventual |
THREE |
Região local | Strong |
O Azure Cosmos DB não tem noção de consistência de gravação para apenas dois nós, portanto, tratamos essa consistência de forma semelhante ao quórum para a maioria dos casos. Para consistência TWOde leitura, essa consistência é equivalente a escrever com QUOROM e ler a partir de ONE.
Serial, ou Local_Serial escreva consistência no Apache Cassandra
| Consistência de leitura do Apache | Lendo de | Nível de consistência do Azure Cosmos DB mais próximo das configurações de leitura/gravação do Apache Cassandra |
|---|---|---|
ALL |
Região local | Strong |
EACH_QUOROM |
Região local | Strong |
QUOROM |
Região local | Strong |
LOCAL_QUORUM |
Região local | Strong |
LOCAL_ONE |
Região local | Eventual |
ONE |
Região local | Eventual |
TWO |
Região local | Strong |
THREE |
Região local | Strong |
A série só se aplica a transações leves. O Azure Cosmos DB segue um algoritmo comprometido de forma durável por padrão e, portanto Serial , a consistência é semelhante ao quórum.
Outras regiões para gravação de região única
O Azure Cosmos DB facilita cinco configurações de consistência, incluindo forte, em várias regiões onde as gravações de uma única região são configuradas. Essa facilitação ocorre desde que as regiões estejam a menos de 2.000 milhas umas das outras.
O Azure Cosmos DB não tem um mapeamento aplicável ao Apache Cassandra, pois todos os nós/regiões são gravados e uma garantia de consistência forte não é possível em todas as regiões.
Outras regiões para gravação em várias regiões
O Azure Cosmos DB facilita apenas quatro configurações de consistência; eventual, consistent prefix, sessione bounded staleness em várias regiões onde a gravação em várias regiões está configurada.
O Apache Cassandra só forneceria consistência eventual para leituras em outras regiões, independentemente das configurações.
Substituições dinâmicas suportadas
| Configuração da conta do Azure Cosmos DB | Substituir valor na solicitação do cliente | Efeito de substituição |
|---|---|---|
Strong |
All |
Sem efeito (permanecer como strong) |
Strong |
Quorum |
Sem efeito (permanecer como strong) |
Strong |
LocalQuorum |
Sem efeito (permanecer como strong) |
Strong |
Two |
Sem efeito (permanecer como strong) |
Strong |
Three |
Sem efeito (permanecer como strong) |
Strong |
Serial |
Sem efeito (permanecer como strong) |
Strong |
LocalSerial |
Sem efeito (permanecer como strong) |
Strong |
One |
Alterações de consistência para Eventual |
Strong |
LocalOne |
Alterações de consistência para Eventual |
Strong |
Any |
Não permitido (erro) |
Strong |
EachQuorum |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
All |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
Quorum |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
LocalQuorum |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
Two |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
Three |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
Serial |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
LocalSerial |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
One |
Alterações de consistência para Eventual |
Bounded staleness, session ou consistent prefix |
LocalOne |
Alterações de consistência para Eventual |
Bounded staleness, session ou consistent prefix |
Any |
Não permitido (erro) |
Bounded staleness, session ou consistent prefix |
EachQuorum |
Não permitido (erro) |
Métricas
Se sua conta do Azure Cosmos DB estiver configurada com um nível de consistência diferente da consistência forte, revise a métrica PBS (Probabilistically Bounded Staleness). A métrica captura a probabilidade de que seus clientes obtenham leituras fortes e consistentes para suas cargas de trabalho. Essa métrica é exposta no portal do Azure. Para encontrar mais informações sobre a métrica PBS, consulte Monitorar métrica PBS (Probabilistically Bounded Staleness).
A obsolescência probabilisticamente limitada mostra quão eventual é a sua eventual consistência. Essa métrica fornece uma visão sobre com que frequência você pode obter uma consistência mais forte do que o nível de consistência que você configurou atualmente em sua conta do Azure Cosmos DB. Em outras palavras, você pode ver a probabilidade (medida em milissegundos) de obter leituras consistentes para uma combinação de regiões de escrita e leitura.
Forte consistência global para solicitações de gravação no Apache Cassandra
Apache Cassandra, a configuração de EACH_QUORUM ou QUORUM dá uma forte consistência. Quando uma solicitação de gravação é enviada para uma região, EACH_QUORUM persiste os dados em um número de quórum de nós em cada data center. Essa persistência exige que todos os data centers estejam disponíveis para que a operação de gravação seja bem-sucedida. QUORUM é um pouco menos restritivo, com vários QUORUM nós em todos os data centers necessários para persistir os dados antes de reconhecer que a gravação foi bem-sucedida.
O gráfico a seguir ilustra uma configuração de consistência global forte no Apache Cassandra entre duas regiões 1 e 2. Depois que os dados são gravados na região 1, a gravação precisa ser persistida em um número de quórum de nós na região 1 e na região 2 antes que uma confirmação seja recebida pelo aplicativo.
Forte consistência global para solicitações de gravação no Azure Cosmos DB para Apache Cassandra
No Azure Cosmos DB, a consistência é definida no nível da conta. Com Strong consistência no Azure Cosmos DB para Cassandra, os dados são replicados de forma síncrona para as regiões de leitura da conta. Quanto mais distantes estiverem as regiões da conta do Azure Cosmos DB, maior será a latência das operações de gravação consistentes.
Como o número de regiões afeta sua solicitação de leitura ou gravação:
- Duas regiões: Com forte coerência, quórum
(N/2 + 1) = 2. Portanto, se a região de leitura ficar inativa, a conta não poderá mais aceitar gravações com forte consistência, uma vez que um número de quórum de regiões não está disponível para a gravação ser replicada. - Três ou mais regiões: para
N = 3,quorum = 2. Se uma das regiões de leitura estiver inativa, a região de gravação ainda poderá replicar as gravações para um total de duas regiões que atendam ao requisito de quórum. Do mesmo modo, com quatro regiões,quorum = 4/2 + 1 = 3. Mesmo com uma região de leitura em baixa, o quórum pode ser atingido.
Nota
Se uma consistência globalmente forte for necessária para todas as operações de gravação, a consistência para a conta do Azure Cosmos DB para Cassandra deverá ser definida como Forte. O nível de consistência para operações de gravação não pode ser substituído por um nível de consistência inferior por solicitação no Azure Cosmos DB.
Consistência mais fraca para solicitações de gravação no Apache Cassandra
Um nível de consistência de , , , THREETWO, Serial LOCAL_QUORUM, ou Local_Serial? ONEANY Considere uma solicitação de gravação com LOCAL_QUORUM um RF de em um datacenter de 4 seis nós. Quorum = 4/2 + 1 = 3.
Consistência mais fraca para solicitações de gravação no Azure Cosmos DB para Apache Cassandra
Quando uma solicitação de gravação é enviada com qualquer um dos níveis de consistência inferiores Strongao , uma resposta bem-sucedida é retornada assim que a região local persiste a gravação em pelo menos três das quatro réplicas.
Forte consistência global para solicitações de leitura no Apache Cassandra
Com uma consistência de EACH_QUORUM, uma leitura consistente pode ser alcançada no Apache Cassandra. Em uma configuração de várias regiões para EACH_QUORUM se o número de quórum de nós não for atendido em cada região, a leitura não será bem-sucedida.
Forte consistência global para solicitações de leitura no Azure Cosmos DB para Apache Cassandra
A solicitação de leitura é atendida a partir de duas réplicas na região especificada. Como a gravação já cuidava de persistir em um número de quórum de regiões (e todas as regiões, se todas as regiões estivessem disponíveis), a simples leitura de duas réplicas na região especificada fornece consistência forte. Essa consistência forte requer EACH_QUORUM ser especificada no driver ao emitir a leitura em relação a uma região para a conta do Cosmos DB, juntamente com a Consistência forte como o nível de consistência padrão para a conta.
Forte consistência local no Apache Cassandra
Um pedido de leitura com um nível de consistência de TWO, THREEou LOCAL_QUORUM nos dará uma leitura forte de consistência da região local. Com um nível de consistência de LOCAL_QUORUM, você precisa de uma resposta de dois nós no datacenter especificado para uma leitura bem-sucedida.
Forte consistência local no Azure Cosmos DB para Apache Cassandra
No Azure Cosmos DB para Cassandra, ter um nível de consistência de , THREE ou LOCAL_QUORUM dará uma consistência forte local para uma solicitação de TWOleitura. Como o caminho de gravação garante a replicação para um mínimo de três de quatro réplicas, uma leitura de duas réplicas na região especificada garantirá uma leitura de quórum dos dados nessa região.
Eventual consistência no Apache Cassandra
Um nível de consistência de LOCAL_ONE, One e ANY with LOCAL_ONE resultará em consistência eventual. Essa consistência é usada nos casos em que o foco está na latência.
Eventual consistência no Azure Cosmos DB para Apache Cassandra?
Um nível de consistência de LOCAL_ONE, ONE ou Any lhe dará consistência eventual. Com eventual consistência, uma leitura é servida a partir de apenas uma das réplicas na região especificada.
Substituir o nível de consistência para operações de leitura no Azure Cosmos DB para Cassandra
Anteriormente, o nível de consistência para solicitações de leitura só podia ser substituído por uma consistência menor do que o padrão definido na conta. Por exemplo, com a consistência padrão de Strong, as solicitações de leitura podem ser emitidas com Strong por padrão e substituídas por solicitação (se necessário) para um nível de consistência mais fraco do que Strong. No entanto, as solicitações de leitura não podiam ser emitidas com um nível de consistência substituído maior do que o padrão da conta. Uma conta com consistência Eventual não poderia receber solicitações de leitura com um nível de consistência maior do que Eventual (que nos drivers Apache Cassandra traduzem para TWO, THREELOCAL_QUORUM ou QUORUM).
O Azure Cosmos DB para Cassandra agora facilita a substituição da consistência em solicitações de leitura por um valor maior do que a consistência padrão da conta. Por exemplo, com a consistência padrão na conta do Cosmos DB definida como Eventual (equivalente ao Apache Cassandra de ou ANY), as solicitações de leitura podem ser substituídas One por solicitação para LOCAL_QUORUM. Essa substituição garante que um número de quórum de réplicas dentro da região especificada seja consultado antes de retornar o conjunto de resultados, conforme exigido pelo LOCAL_QUORUM.
Essa opção também evita a necessidade de definir uma consistência padrão maior do Eventualque , quando é necessária apenas para solicitações de leitura.