Conseguindo escalabilidade e ACID com uma solução de streaming RDBMS to NoSQL

5

Meu entendimento é que o principal recurso que o Cassandra tem a oferecer é o desempenho linear em qualquer escala ; o que significa que se eu souber que 1 nó C * pode manipular 500 consultas ou comandos por segundo do meu aplicativo, então também posso ter certeza de que 100 nós C * incluídos no mesmo cluster poderão manipular 500 * 100 = 50K consultas ou comandos por segundo.

Meu entendimento da principal troca entre RDBMS e NoSQL é que os sistemas NoSQL tendem a favorecer a escalabilidade, mas isso exige que eles (mecanicamente, devido à implementação) precisem relaxar sua transacionalidade. Por isso, sistemas NoSQL como o C * normalmente escalam muito bem, mas não podem oferecer as transações clássicas do ACID que sistemas RDBMS como o MySQL podem.

Meu entendimento é que, como escalabilidade e transacionalidade são mutuamente exclusivas umas das outras, não existem bancos de dados mágicos NoSQL que ofereçam escalabilidade semelhante à C * (novamente: desempenho linear em qualquer escala) e que oferecem aos clientes Java com JTA implementados (recursos de consolidação + reversão) neles.

Estas são minhas suposições direcionadas para essa questão: se eu estiver errado ou errado com qualquer uma delas, por favor, comece corrigindo-me!

Supondo que eu esteja mais ou menos correto em todas essas suposições, então o que se faz quando você realmente precisa de escalabilidade e transações ACID? Minha única ideia aqui seria implementar o seguinte:

  1. Configure o aplicativo para gravar em um RDBMS (como o MySQL) usando um driver compatível com JDBC / JTA (por exemplo, usando transações)
  2. De alguma forma , configure o RDBMS para replicar (em tempo real ou com latência muito baixa) para um banco de dados altamente escalável (como o Cassandra). Essa pode ser uma opção de configuração que o RDBMS em si oferece, ou, muito provavelmente, será o código necessário para se escrever continuamente em ETL de um sistema e em outro. A ideia aqui é que o aplicativo então leia da tabela NoSQL, e ainda tenha leituras muito eficientes em relação a uma enorme quantidade de dados.
  3. De alguma forma configure as tabelas do RDBMS com TTLs para que as tabelas não fiquem muito grandes e comecem a exigir sharding e outros truques que possam reduzir a velocidade das transações. Novamente, essa pode ser uma opção de configuração oferecida pelo próprio RDBMS ou, provavelmente, um código que você precisa escrever por conta própria.

Existe alguma solução melhor conhecida aqui? Quaisquer armadilhas / advertências para esta abordagem?

    
por hotmeatballsoup 06.07.2018 / 18:00
fonte

1 resposta

1

Suas suposições não são tão erradas quanto incompletas. O compromisso entre escalabilidade (tolerar partições de rede ou P no CAP) e transacionalidade (consistência ou C no CAP) não se coloca no nível de um sistema, mas no nível de uma operação ou transação individual. Ou seja, uma transação pode ser consistente ou pode aproveitar a escala horizontal, mas não as duas. No entanto, os bancos de dados estão livres para fornecer os dois mecanismos. Por exemplo, o cassandra oferece suporte a transações leves e leituras / gravações majoritárias, que fornecem mecanismos para garantir a consistência.

A imagem se torna ainda mais complicada porque são propriedades técnicas, mas não se comportam exatamente como você esperaria intuitivamente. Por exemplo, a chave inglesa na nuvem do Google oferece escalabilidade e consistência strong na perspectiva do usuário do banco de dados , embora internamente seja eventualmente consistente. A fragmentação é uma maneira de enganar , com o sistema como um todo, aproveitando a escala horizontal, mas todos os dados dentro de um fragmento são strongmente consistentes.

Agora, à sua pergunta sobre como alcançar a escalabilidade e consistência, algumas estratégias:

  • O problema realmente se coloca apenas nos casos em que você deve ler antes de escrever. Você pode tentar isolar as partes que se enquadram nessa categoria e usar um mecanismo ou banco de dados diferente para atendê-las. A aplicação de sharding pode ajudar a subdividir ainda mais o conjunto de dados consistentes para caber em um servidor.
  • Você pode aproveitar o fato de que provavelmente nem todas as leituras devem ter uma exibição consistente e usar caches ou consultas não-ACID (por exemplo, cassandra lê consistência ONE).
  • Nos casos em que você deseja substituir um gráfico complexo de dados por um novo gráfico complexo de dados que deve ser totalmente consistente, é possível usar uma estratégia de versão onde você grava a nova versão do gráfico usando gravações não atômicas e depois mude para essa versão com uma gravação atômica.
por 09.07.2018 / 09:53
fonte