Este artigo apareceu pela primeira vez em InfoWorld . É reimpresso com permissão. © IDG Communications, Inc., 2020. Todos os direitos reservados Como o MariaDB alcança escala global com o Xpand. O Xpand agora está disponível no MariaDB SkySQL adicionando SQL distribuído para escalabilidade e elasticidade na nuvem.
À medida que as necessidades de informações e processamento aumentaram, pontos problemáticos como desempenho e resiliência exigiram novas soluções. Os bancos de dados precisam manter a conformidade e a consistência do ACID, fornecer alta disponibilidade e alto desempenho e lidar com cargas de trabalho massivas sem esgotar os recursos. O sharding ofereceu uma solução, mas para muitas empresas o sharding atingiu seus limites, devido à sua complexidade e requisitos de recursos. Uma solução melhor é o SQL distribuído.
Em uma implementação de SQL distribuído, o banco de dados é distribuído em vários sistemas físicos, entregando transações em um nível globalmente escalável. A Plataforma MariaDB X5, uma versão importante que inclui atualizações para todos os aspectos da Plataforma MariaDB, fornece SQL distribuído e escalabilidade massiva por meio da adição de um novo mecanismo de armazenamento inteligente chamado Xpand. Com uma arquitetura nada compartilhada, transações ACID totalmente distribuídas e consistência forte, o Xpand permite escalar para milhões de transações por segundo.
Motores inteligentes conectáveis otimizados
O MariaDB Enterprise Server foi projetado para usar mecanismos de armazenamento conectáveis (como Xpand) para otimizar cargas de trabalho específicas de uma única plataforma. Não há necessidade de bancos de dados especializados para lidar com cargas de trabalho específicas. MariaDB Xpand, nosso mecanismo inteligente para SQL distribuído, é a adição mais recente à nossa programação. O Xpand adiciona recursos transacionais distribuídos massivamente escaláveis às opções fornecidas por nossos outros mecanismos. Nossos outros mecanismos conectáveis fornecem otimização para cargas de trabalho analíticas (colunares), de leitura intensa e de gravação. Você pode misturar e combinar tabelas replicadas, distribuídas e colunares para otimizar cada banco de dados para seus requisitos específicos.
A adição do MariaDB Xpand permite que os clientes corporativos obtenham todos os benefícios do SQL distribuído – velocidade, disponibilidade e escalabilidade – enquanto mantêm os benefícios do MariaDB aos quais estão acostumados.
Vamos dar uma olhada em como o MariaDB Xpand fornece SQL distribuído.
SQL distribuído até os índices
O Xpand fornece SQL distribuído fatiando, replicando e distribuindo dados entre nós. O que isto significa? Usaremos um exemplo muito simples com uma tabela e três nós para demonstrar os conceitos. Não é mostrado neste exemplo que todas as fatias são replicadas.
Na Figura 1 acima, temos uma tabela com dois índices. A tabela tem algumas datas e temos um índice na Coluna Dois e outro nas Colunas Três e Um. Os índices são, em certo sentido, tabelas em si. Eles são subconjuntos da tabela. A chave primária é id , o primeiro índice na tabela. Isso é o que será usado para fazer o hash e espalhar os dados da tabela pelo banco de dados.
Agora adicionamos a noção de fatias . Fatias são essencialmente partições horizontais da mesa. Temos cinco linhas em nossa tabela. Na Figura 2, a mesa foi fatiada e distribuída. O nó #1 tem duas linhas. O nó #2 tem duas linhas e o nó #3 tem uma linha. O objetivo é ter os dados distribuídos o mais uniformemente possível entre os nós.
Os índices também foram fatiados e distribuídos. Esta é uma diferença chave entre o Xpand e outras soluções distribuídas. Normalmente, os bancos de dados distribuídos possuem índices locais, portanto, cada nó possui um índice de seus próprios dados. No Xpand, os índices são distribuídos e armazenados independentemente da tabela. Isso elimina a necessidade de enviar uma consulta para todos os nós (scatter/gather). No exemplo acima, o Nó 1 contém as linhas 2 e 4 da tabela e também contém índices para as linhas 32 e 35 e as linhas abril e março. A tabela e os índices são divididos, distribuídos e replicados independentemente nos nós.
O mecanismo de consulta usa os índices distribuídos para determinar onde encontrar os dados. Ele procura apenas as partições de índice necessárias e, em seguida, envia consultas apenas para os locais onde residem os dados necessários. As consultas são todas distribuídas. Eles são feitos simultaneamente e em paralelo. Para onde eles vão depende inteiramente dos dados e do que é necessário para resolver a consulta.
Todas as fatias são replicadas pelo menos duas vezes. Para cada fatia, existem réplicas que residem em outros nós. Por padrão, haverá três cópias desses dados – a fatia e duas réplicas. Cada cópia estará em um nó diferente e, se você estivesse executando em várias zonas de disponibilidade, essas cópias também estariam em diferentes zonas de disponibilidade.
Manuseio de leitura e gravação
Tomemos outro exemplo. Na Figura 3, temos cinco instâncias do MariaDB Enterprise Server com Xpand (nós). Há uma tabela para armazenar perfis de clientes. A fatia com o perfil de Shane está no Nó #1 com cópias no Nó #3 e Nó #5. As consultas podem entrar em qualquer nó e serão processadas de maneira diferente, dependendo de serem leituras ou gravações.
As gravações são feitas em todas as cópias de forma síncrona dentro de uma transação distribuída. Sempre que atualizo meu perfil “Shane” porque mudei meu e-mail ou meu endereço, essas gravações vão para todas as cópias ao mesmo tempo em uma transação. Isso é o que fornece uma consistência forte.
Na Figura 3, a instrução UPDATE foi para o Nó 2. Não há nada no Nó 2 em relação ao meu perfil, mas o Nó 2 sabe onde está meu perfil e envia atualizações para o Nó 1, Nó 3 e Nó 5, depois confirma essa transação e retorna ao aplicativo.
As leituras são tratadas de forma diferente. No diagrama, a fatia com meu perfil está no Nó #1 com cópias no Nó #3 e Nó #5. Isso torna o Nó 1 a réplica de classificação. Cada fatia tem uma réplica de classificação, que pode ser considerada o nó que “possui” os dados. Por padrão, não importa em qual nó uma leitura chegue, ela sempre vai para a réplica de classificação, então cada SELECT que resolve para mim irá para o Nó #1.
Fornecendo elasticidade
Bancos de dados distribuídos como o Xpand estão continuamente mudando e evoluindo dependendo dos dados no aplicativo. O processo de rebalanceamento é responsável por adaptar a distribuição de dados às necessidades atuais e manter a distribuição ideal de fatias entre os nós. Existem três cenários gerais que exigem redistribuição:adição de nós, remoção de nós e prevenção de cargas de trabalho irregulares ou “pontos de acesso”.
Por exemplo, digamos que estamos executando com três nós, mas descobrimos que o tráfego está aumentando e precisamos dimensionar – adicionamos um quarto nó para lidar com o tráfego. O nó #4 está vazio quando o adicionamos conforme mostrado na Figura 4. O rebalanceador move automaticamente slices e réplicas para fazer uso do Nó #4, conforme mostrado na Figura 5.
Se o nó #4 falhar, o rebalanceador automaticamente voltará a funcionar; desta vez recriando fatias de suas réplicas. Nenhum dado é perdido. As réplicas também são recriadas para substituir aquelas que residiam no Nó 4, para que todas as fatias tenham novamente réplicas em outros nós para garantir alta disponibilidade.
Figura 6. Se um nó falhar, o rebalanceador Xpand recria as fatias e as réplicas que residiam no nó com falha a partir dos dados de réplica nos outros nós.
em>Equilibrando a carga de trabalho
Além da expansão horizontal e alta disponibilidade, o rebalanceador reduz a distribuição desigual da carga de trabalho – pontos de acesso ou subutilização. Mesmo quando os dados são distribuídos aleatoriamente com um algoritmo de hash perfeito, podem ocorrer pontos quentes. Por exemplo, pode acontecer apenas por acaso que os 10 produtos à venda este mês estejam no Node #1. Os dados são distribuídos uniformemente, mas a carga de trabalho não (Figura 7). Nesse tipo de cenário, o rebalanceador redistribuirá fatias para equilibrar a utilização de recursos (Figura 8).
Figura 7. O Xpand distribuiu os dados uniformemente, mas a carga de trabalho é desigual. O nó 1 tem uma carga de trabalho significativamente maior do que os outros três nós.
Figura 8. O rebalanceador Xpand redistribui as fatias de dados para equilibrar a carga de trabalho entre os nós.
Escalabilidade, velocidade, disponibilidade, equilíbrio
As necessidades de informação e processamento continuarão a crescer. Isso é um dado. O MariaDB Xpand fornece uma solução de dimensionamento consistente e compatível com ACID para empresas com requisitos que não podem ser atendidos com outras alternativas, como replicação e fragmentação.
O SQL distribuído fornece escalabilidade e o MariaDB Xpand oferece a flexibilidade de escolher quanta escalabilidade você precisa. Distribua uma ou várias tabelas ou até mesmo todo o seu banco de dados, a escolha é sua. Operacionalmente, a capacidade é facilmente ajustada para atender às demandas de carga de trabalho em constante mudança. Você nunca precisa ser superprovisionado.
O Xpand também protege de forma transparente contra a utilização desigual de recursos, redistribuindo dinamicamente os dados para equilibrar a carga de trabalho entre os nós e evitar pontos de acesso. Para desenvolvedores, não há necessidade de se preocupar com escalabilidade e desempenho. Xpand é elástico. O Xpand também oferece redundância e alta disponibilidade. Com dados fatiados, replicados e distribuídos entre nós, os dados são protegidos e a redundância é mantida em caso de falha de hardware.
E, com a arquitetura do MariaDB, suas tabelas distribuídas funcionarão bem – incluindo JOINs entre mecanismos – com suas outras tabelas MariaDB. Crie a solução de banco de dados que você precisa misturando e combinando tabelas replicadas, distribuídas ou colunares em um único banco de dados na Plataforma MariaDB.
