Vídeo: Clustering con SQL Server 2016 con algoritmo EM 2024
Os bancos de dados NoSQL são adequados para conjuntos de dados muito grandes. Clones Bigtable como HBase não são uma exceção. Você provavelmente quer usar vários servidores de baixo custo em um único cluster em vez de uma máquina muito poderosa. Isso ocorre porque você pode obter um melhor desempenho global por dólar, usando muitos servidores de commodities, em vez de um servidor poderoso e único, muito mais caro.
Além de poder escalar rapidamente, os servidores de commodities baratos também podem tornar o seu serviço de banco de dados mais resiliente e, assim, ajudar a evitar falhas de hardware. Isso ocorre porque você tem outros servidores para assumir o serviço se a placa-mãe de um único servidor falhar. Este não é o caso com um único servidor grande.
A figura mostra uma configuração HBase altamente disponível com um exemplo de divisão de dados entre servidores.
O diagrama mostra dois nós (HRegionServers) em uma configuração altamente disponível, cada um agindo como um backup para o outro.
Em muitas configurações de produção, você pode querer pelo menos três nós para alta disponibilidade para garantir que duas falhas de servidor fechadas no tempo possam ser tratadas. Isso não é tão raro quanto você pensaria! O conselho varia de acordo com Bigtable; por exemplo, a HBase recomenda cinco nós como mínimo para um cluster:
-
Cada servidor de região gerencia seu próprio conjunto de chaves.
Projetar uma estratégia de alocação de chave de linha é importante porque determina como a carga está espalhada pelo cluster.
-
| Cada região mantém seu próprio registro de gravação e armazenamento na memória.
No HBase, todos os dados são gravados em uma memória na memória e, posteriormente, esta loja está descarregada no disco. No disco, essas lojas são chamadas de arquivos de armazenamento .
A HBase interpreta os arquivos da loja como arquivos únicos, mas, na realidade, eles são distribuídos em pedaços em um sistema de arquivos distribuídos Hadoop (HDFS). Isso proporciona alta velocidade de ingesta e recuperação, porque todas as operações de E / S grandes estão espalhadas por muitas máquinas.
Para maximizar a disponibilidade de dados, por padrão, o Hadoop mantém três cópias de cada arquivo de dados. As grandes instalações têm
-
Uma cópia primária
-
Uma réplica no mesmo rack
-
Outra réplica em um rack diferente
Antes do Hadoop 2. 0, o Namenodes não pôde ser altamente disponível. Estes mantiveram uma lista de todos os servidores ativos no cluster. Eles eram, portanto, um único ponto de falha. Desde Hadoop 2. 0, esse limite já não existe.
