Databases for Cassandra

O Apache Cassandra, um sistema de gestão de bases de dados (SGBD) NoSQL open-source, armazena os dados sob a forma de chave-valor. Além disso, armazena e manipula os dados para os reestruturar. O Cassandra possui a sua própria linguagem para efetuar pedidos, a Cassandra Query Language (CQL), que funciona em todos os sistemas operativos, tornando-o uma solução flexível.

Este serviço é um DBaaS (Database-as-a-Service). É repartido por várias das nossas instâncias Public Cloud e é fornecido como um serviço chave-na-mão. Facilita-lhe o trabalho, pois somos nós a tratar da gestão e da administração (configuração, manutenção, backup, segurança e escalabilidade). Em resumo, é um serviço de bases de dados cloud que lhe permite poupar tempo.

É possível fazê-lo depois de descarregar e implementar a última versão do JDK Java. No entanto, terá de realizar todas as tarefas de gestão e administração das suas bases de dados. Desta forma, não poderá usufruir das funcionalidades que fornecemos no nosso serviço chave-na-mão.

Inicialmente desenvolvido por um nome importante no setor das IT e desde 2008 promovido pela fundação Apache, o Cassandra é atualmente o segundo motor mais utilizado no mundo, de acordo com os últimos dados. Este fenómeno explica-se pela ênfase colocada no desempenho e na alta disponibilidade, com um modo distribuído que permite minimizar, senão mesmo eliminar, os Single Points of Failure (SPOF).

O Cassandra é uma base de dados NoSQL. Foi concebido para gerir grandes quantidades de dados repartidos por vários servidores sem SPOF.

O Cassandra é utilizado para aplicações que requerem uma grande escalabilidade e alta disponibilidade sem comprometer o desempenho em leitura e escrita. Esta solução é ideal para aplicações de telemetria, sistemas de gestão de dados de redes sociais, serviços de mensagens e cenários em que são críticas a velocidade e a fiabilidade das operações de dados.

Estes dois motores de bases de dados oferecem vantagens diferentes, embora ambos façam parte das bases de dados NoSQL. Uma das diferenças reside na linguagem utilizada para os pedidos. O MongoDB usa uma sintaxe próxima do JavaScript, enquanto o Cassandra é mais singular, com a utilização da CQL, que lhe é exclusiva.

Também existe uma diferença na gestão da redundância de um cluster: o MongoDB tem sempre um servidor-mestre e servidores secundários prontos a assumir o controlo, ao passo que o Cassandra utiliza um modelo diferente que se baseia em vários nós-mestres no mesmo cluster.

Cada um representa um pack Cassandra específico no Public Cloud e inclui funcionalidades variáveis que respondem a aplicações diferentes. Estas podem dizer respeito ao tamanho do cluster, ao número de nós no cluster, à rede, à escalabilidade ou ainda à alta disponibilidade.

Não. O seu serviço dispõe de uma ou várias instâncias Public Cloud que o executam e que são dotadas de um espaço de armazenamento dedicado individual. Desta forma, os seus dados são controlados por si.

É possível. De facto, se verificar que as suas necessidades em termos de RAM ou de espaço de armazenamento estão a aumentar, poderá escolher nós com maior capacidade. No entanto, tenha em conta que não é possível passar para um nó de capacidade inferior.

Sim. Fornecemos um backup automático em cada oferta. Contudo, as políticas de conservação predefinidas diferem consoante a fórmula escolhida. Aconselhamos que avalie todas as nossas ofertas antes de fazer a sua escolha.

Tratamos de todas as atividades de gestão e administração da base de dados por si. Assim, não precisa de se preocupar com a implementação, a manutenção, a segurança, o backup ou a escalabilidade. É este serviço gerido que faturamos, a fim de o poupar a tais tarefas.

Sim. Pode ligar a sua base de dados ao seu servidor através de uma rede pública ou privada. No entanto, deverá fazê-lo de forma autónoma, tal como deverá gerir e administrar a sua base de dados pelos seus próprios meios.

Descubra a resiliência das implementações no nosso manual dedicado.

As regiões 1-AZ usam uma única Availability Zone com um ou vários datacenters. Embora ofereçam proteção contra falhas de servidor e controlador, elas podem ser vulneráveis a falhas de datacenter. Isto pode afetar o acesso em caso de falha do datacenter de alojamento.

Em contrapartida, as regiões 3-AZ são compostas por 3 Availability Zones independentes, cada uma delas isolada em termos de alimentação, arrefecimento e rede, oferecendo assim um verdadeiro isolamento contra falhas. Esta arquitetura permite a disponibilidade do serviço mesmo em caso de falha de toda uma zona.

Ganhe paz de espírito graças a compromissos de nível de serviço (SLA) de 99,99%.

Sim! É perfeitamente possível migrar de uma região 1-AZ para uma 3-AZ.

Pode ligar regiões 1-AZ a regiões 3-AZ através de uma ligação privada, de modo a otimizar a complexidade e o custo das suas implementações de infraestrutura.