O ApsaraDB for SelectDB oferece suporte a múltiplos clusters de computação em uma única instância. Cada cluster possui recursos de computação fisicamente isolados, mas todos leem e gravam nos mesmos dados subjacentes. Assim, diferentes sistemas de negócios executam cargas de trabalho de forma independente, sem impacto mútuo no desempenho.
Como funciona
O ApsaraDB for SelectDB utiliza uma arquitetura nativa da nuvem com separação entre computação e armazenamento. Os recursos de computação da camada superior são desacoplados do armazenamento, o que permite que vários clusters de computação compartilhem os mesmos dados sem duplicá-los. Cada cluster opera como um grupo de recursos dedicado: coordena uma ou mais unidades de computação para concluir tarefas e mantém seus recursos fisicamente isolados dos demais clusters.
Casos de uso
Múltiplos clusters de computação são ideais para isolar cargas de trabalho entre sistemas de negócios distintos:
Isolamento de leitura e escrita: Separe as cargas de ingestão intensivas em escrita das consultas focadas em leitura para evitar que grandes inserções degradem o tempo de resposta das queries.
Isolamento online/offline: Execute consultas de atendimento em tempo real e jobs de análise em lote em clusters separados para garantir latência previsível ao tráfego de produção.
Exemplo: isolamento de dois sistemas de negócios
Este exemplo demonstra como configurar dois clusters — cluster_01 para o Sistema de Negócios A e cluster_02 para o Sistema de Negócios B — e confirme que ambos compartilham os mesmos dados subjacentes.
Pré-requisitos
Antes de começar, verifique se você tem:
Uma instância do ApsaraDB for SelectDB com pelo menos dois clusters de computação (
cluster_01ecluster_02)Acesso à instância com uma conta de administrador
Etapa 1: Crie contas de usuário e conceder acesso aos clusters
Conecte-se à instância com a conta de administrador e crie duas contas de usuário.
-- Create user accounts
CREATE USER test_01 IDENTIFIED BY 'testPassword';
CREATE USER test_02 IDENTIFIED BY 'testPassword';
-- Grant full data access to both accounts
GRANT ALL ON *.* TO test_01;
GRANT ALL ON *.* TO test_02;
-- Assign each account to its cluster
GRANT USAGE_PRIV ON CLUSTER cluster_01 TO test_01;
GRANT USAGE_PRIV ON CLUSTER cluster_02 TO test_02;Etapa 2: Verifique as atribuições de cluster
Ainda com a conta de administrador, execute SHOW clusters para confirmar a configuração.
SHOW clusters;Saída esperada:
+------------+------------+-------+
| cluster | is_current | users |
+------------+------------+-------+
| cluster_01 | FALSE | |
| cluster_02 | TRUE | |
+------------+------------+-------+A conta de administrador tem acesso a ambos os clusters e usa cluster_02 por padrão.
Agora, conecte-se como test_01 e execute o mesmo comando.
SHOW clusters;Saída esperada:
+------------+------------+-------+
| cluster | is_current | users |
+------------+------------+-------+
| cluster_01 | TRUE | |
+------------+------------+-------+O usuário test_01 acessa apenas o cluster_01, o que confirma o funcionamento correto da atribuição de cluster.
Em seguida, conecte-se como test_02 e execute o mesmo comando.
SHOW clusters;Saída esperada:
+------------+------------+-------+
| cluster | is_current | users |
+------------+------------+-------+
| cluster_02 | TRUE | |
+------------+------------+-------+O usuário test_02 acessa apenas o cluster_02, confirmando novamente que a atribuição de cluster opera conforme o esperado.
Etapa 3: Gravar dados no cluster_01
Conecte-se como test_01 e insira registros de teste em uma nova tabela.
CREATE TABLE golds_log
(
user_id bigint,
accounts string,
change_type string,
golds bigint,
log_time int
) DISTRIBUTED BY HASH(`user_id`) BUCKETS 3;
INSERT INTO golds_log VALUES
(3645356, 'wds7654321(4171752)', 'swim', 1700, 152607152),
(2016869, 'dqyx123456789(2376699)', 'noise', 1140, 152607152),
(3630468, 'dke3776611(4156064)', 'white', 1200, 152602752);Etapa 4: Ler os mesmos dados no cluster_02
Conecte-se como test_02 e consulte a tabela na qual test_01 acabou de gravar dados.
SELECT * FROM golds_log;Saída esperada:
+---------+------------------------+-------------+-------+-----------+
| user_id | accounts | change_type | golds | log_time |
+---------+------------------------+-------------+-------+-----------+
| 3630468 | dke3776611(4156064) | noise | 1200 | 152602752 |
| 2016869 | dqyx123456789(2376699) | whitewo | 1140 | 152607152 |
| 3645356 | wds7654321(4171752) | swim | 1700 | 152607152 |
+---------+------------------------+-------------+-------+-----------+Como test_02 consegue ler os dados gravados por test_01, confirma-se que todos os clusters compartilham o mesmo armazenamento subjacente.
Comportamento quando o usuário não tem acesso a nenhum cluster
Conecte-se à instância com a conta de administrador e crie um terceiro usuário sem conceder acesso a qualquer cluster.
CREATE USER test_03 IDENTIFIED BY 'testPassword';
GRANT ALL ON *.* TO test_03;Conecte-se como test_03 e execute uma consulta:
SELECT * FROM golds_log;A consulta falha com o seguinte erro:
ERROR 1105 (HY000): errCode = 2, detailMessage = 90363 have no queryable replicas. err: 90364's backend -1 does not exist or not alive, or you may not have permission to access the current cluster, clusterName=nullEsse erro indica que a conta não tem acesso a nenhum cluster na instância. Para resolver, conceda USAGE_PRIV em pelo menos um cluster.