Gostaria de entender a recomendação de max. Carga de 1 TB por nó que é repetidamente sugerida, principalmente o Datastax.
Não vi em nenhum lugar como esse limite se traduz em qualquer métrica, além de comentários bastante subjetivos, como substituição mais rápida de nós ou backups. Esses tipos de comentários são muito ambíguos (o que é rápido para você pode não ser para um ambiente de produção diferente) ou podem até ser irrelevantes. (Veja isso )
Além disso, 1 TB parece um limite muito baixo atualmente, quando você pode obter um disco sata de 8 TB por pouco mais de US$ 130.
- O limite de 1 TB corresponde a uma limitação real inerente ao design do Cassandra?
- Este limite foi quantificado, por exemplo, mostrando (por exemplo, gráficos) como algumas métricas pioram claramente acima dele?
- Este limite é mais relevante que "<50% da capacidade"? Digamos que a carga esteja em 3 TB, mas a capacidade esteja em 50%, ainda haveria necessidade de aumentar o número de nós?
Esta restrição é tal que provavelmente é sempre mais fácil e barato fixar o limite de capacidade do que o de carga. Isso não me parece razoável e, se for certo, questiona seriamente a adequação de Cassandra para pequenas e médias empresas.
Tentarei fazer o meu melhor para lhe dar as respostas que você procura.
As respostas curtas são: 1. não, 2. sim, 3. depende™
Em mais detalhes…
Cassandra 5.0+ permitirá confortavelmente uma densidade superior a 4 TB por nó. A densidade de nós recomendada é baseada em hardware, modelo de dados e fatores operacionais. Uma recomendação atualizada e precisa para 5.0 está em andamento.
A recomendação para versões mais antigas do Apache Cassandra e todas as suas variantes é de 1 a 4 TB de dados por nó. Isso significa discos de 2 a 8 TB. (E os discos precisam ser capazes de lidar com um mínimo de 10k IOPS sustentados e não fazer JBOD.)
A regra dos 50% é a regra básica para tabelas que usam STCS (SizeTieredCompactionStrategy). O processo de compactação duplica no disco o que (e enquanto) ele está compactando. Mais tabelas significa que nenhuma compactação única cobrirá todos esses 50% (tendo em mente que há compactadores simultâneos). Outras estratégias de compactação alteram este comportamento. LCS (LeveledCompactionStrategy) possui níveis e funciona com compactações menores, portanto, muitas vezes pode funcionar com até 70% de uso do disco. TWCS (TimeWindowedCompactionStrategy) apenas compacta a janela de tempo atual, de modo que 50% se torna 50% x tamanho máximo da janela de tempo.
Há outras coisas que ocupam espaço em disco, como backups e instantâneos, operações de streaming, etc., portanto, a regra dos 50% é uma recomendação segura para ser descartada sem entrar em todos os detalhes. Na prática, normalmente é algo em torno de 60-70%. Mas, como você já apontou, discos nesses tamanhos são baratos.
A limitação de dados por nó tem a ver com facilidade operacional. Certas operações começam a se tornar mais demoradas e desajeitadas acima da densidade de dados do nó de 1 TB. Especialmente todas as atividades relacionadas ao streaming: inicialização, descomissionamento, reparos, etc. Muitos clusters estão funcionando perfeitamente a 4 TB, apesar do peso de algumas tarefas impostas ao operador. Se estiver usando LCS, pode haver muita E/S proveniente de compactações, o que pode prejudicar as latências de leitura. Se estiver usando STCS, a compactação da camada maior pode levar muito tempo, deixando as camadas inferiores pendentes, o que também pode prejudicar as latências de leitura. O TWCS não sofre esses problemas e vimos pessoas usarem até 16 TB por nó, mas isso torna essas operações de streaming dolorosas. Novamente, a recomendação segura para descartar é 1 TB.
Apache Cassandra 5.0 e DataStax 6.8 possuem UCS (Estratégia de Compactação Unificada). Esta estratégia de compactação pode ser ajustada/sintonizada entre as compensações de amplificação de gravação ou leitura, ou seja, uma escala móvel entre comportamento como STCS ou como LCS (analogia do pobre). Com esta estratégia de compactação e uma série de outras melhorias significativas (como índices estáveis baseados em tentativas), a densidade dos nós pode ser muito maior. E as operações de streaming foram aprimoradas para serem mais rápidas e “mais leves”.
Cassandra é uma tecnologia escalável, adote essa mentalidade ao planejar a capacidade desde o primeiro dia. Não se trata apenas de aproveitar as vantagens do hardware comum, mas das principais características de design do Cassandra de durabilidade, disponibilidade e escalabilidade linear.
Seu argumento sobre Cassandra não separar a computação da escalabilidade de armazenamento é válido. Fique ligado para mais ações nessa frente, desde armazenamento em camadas, processos/serviços separados para estágios em segundo plano (SEDA) até TCM (CEP-21), há muitas melhorias por vir. Tendo trabalhado com centenas (talvez milhares) de clusters de produção, como consultor no The Last Pickle e na DataStax, e a maioria deles sendo de pequeno a médio porte conforme você levanta preocupações, não vi esse problema ser o bloqueador que você supõe que seja. Cassandra é o banco de dados distribuído sem líder mais popular que existe por um motivo. Mas sim, sua escolha de hardware é um pouco mais selecionada (lembre-se de expansão horizontal, não de expansão, e SSDs conectados localmente, não uma SAN), mas por outro lado, estamos falando mais aqui sobre otimizações de desempenho/custo, que todos nós amamos , mas não são bloqueadores.
Eu recomendo que você dê uma olhada no AstraDB que já tem todas essas vantagens e muito mais.