Na postagem de hoje, vamos discutir sobre a arquitetura do HBase. Vamos revisar nossos fundamentos do HBase antes de nos aprofundarmos na arquitetura do HBase.
HBase - O básico:
HBase é um armazenamento de código aberto, NoSQL, distribuído, não relacional, com versão, multidimensional e orientado a colunas, que foi modelado após o Google BigTable que é executado no HDFS. '' NoSQL ”é um termo amplo que significa que o banco de dados não é um RDBMS que suporta SQL como seu idioma de acesso principal. Mas existem muitos tipos de bancos de dados NoSQL e o Berkeley DB é um bom exemplo de banco de dados NoSQL local, enquanto o HBase é muito mais um banco de dados distribuído.
HBase fornece todos os recursos do Google BigTable. Tudo começou como um projeto da Powerset para processar grandes quantidades de dados para pesquisa em linguagem natural. Ele foi desenvolvido como parte do projeto Hadoop da Apache e é executado no HDFS (Hadoop Distributed File System). Ele fornece maneiras tolerantes a falhas de armazenamento de grandes quantidades de dados esparsos. O HBase é realmente mais um “armazenamento de dados” do que um “banco de dados” porque carece de muitos dos recursos disponíveis no RDBMS, como colunas digitadas, índices secundários, gatilhos e linguagens de consulta avançadas, etc.
Nos bancos de dados orientados a colunas, a tabela de dados é armazenada como seções de colunas de dados, em vez de linhas de dados. O modelo de dados do banco de dados orientado a colunas consiste no nome da tabela, chave de linha, família de colunas, colunas e registro de data e hora. Ao criar tabelas no HBase, as linhas serão identificadas exclusivamente com a ajuda de chaves de linha e registro de data e hora. Neste modelo de dados, a família de colunas é estática, enquanto as colunas são dinâmicas. Agora vamos dar uma olhada na arquitetura do HBase.
programa java para conectar ao banco de dados mysql
Quando escolher o HBase?
O HBase é uma boa opção apenas quando há centenas de milhões ou bilhões de linhas. O HBase também pode ser usado em locais ao considerar a mudança de um RDBMS para o HBase como um redesenho completo em oposição a uma porta. Em outras palavras, o HBase não é otimizado para aplicativos transacionais clássicos ou mesmo analítica relacional. Também não é um substituto completo para HDFS ao fazer MapReduce de lote grande. Então, por que você deveria escolher o HBase ?? Se seu aplicativo possui um esquema de variável em que cada linha é ligeiramente diferente, você deve olhar para o HBase.
Arquitetura HBase:
A figura a seguir explica claramente a arquitetura do HBase.
No HBase, existem três componentes principais: Mestre, servidor de região e zelador . Os outros componentes são Memstore, HFile e WAL.
Como o HBase é executado no HDFS, ele utiliza a arquitetura Master-Slave na qual o HMaster será o nó mestre e os Servidores de região são os nós escravos. Quando o cliente envia uma solicitação de gravação, o HMaster recebe essa solicitação e a encaminha para o respectivo servidor de região.
falha rápido vs falha seguro
Servidor de região:
É um sistema que atua de forma semelhante a um nó de dados. Quando o Region Server (RS) recebe a solicitação de gravação, ele direciona a solicitação para uma região específica. Cada região armazena um conjunto de linhas. Os dados das linhas podem ser separados em várias famílias de colunas (CFs). Os dados de um CF específico são armazenados em HStore, que consiste em Memstore e um conjunto de HFiles.
O que o Memstore faz?
Memstore mantém registro de todos os logs para as operações de leitura e gravação que foram executadas naquele servidor de região específico. A partir disso, podemos dizer que está agindo de forma semelhante a um nó de nome no Hadoop. Memstore é um armazenamento na memória, portanto, o Memstore utiliza o armazenamento na memória de cada nó de dados para armazenar os logs. Quando certos limites são atingidos, os dados do Memstore são liberados para o HFile.
O principal objetivo do uso do Memstore é a necessidade de armazenar dados no DFS ordenados por chave de linha. Como o HDFS é projetado para leituras / gravações sequenciais, sem modificações de arquivo permitidas, o HBase não pode gravar dados de maneira eficiente no disco conforme estão sendo recebidos: os dados gravados não serão classificados (quando a entrada não é classificada), o que significa que não são otimizados para o futuro recuperação. Para resolver esse problema, o HBase armazena em buffer os dados recebidos pela última vez na memória (no Memstore), “os classifica” antes de descarregar e, em seguida, grava no HDFS usando gravações sequenciais rápidas. Portanto, HFile contém uma lista de linhas classificadas.
Cada vez que ocorre a liberação do Memstore, um HFile criado para cada CF e as liberações frequentes podem criar toneladas de HFiles. Visto que durante a leitura, o HBase terá que olhar muitos HFiles, a velocidade de leitura pode ser prejudicada. Para evitar a abertura de muitos HFiles e evitar a deterioração do desempenho de leitura, o processo de compactação de HFiles é usado. O HBase irá periodicamente (quando certos limites configuráveis forem atingidos) compactar vários HFiles menores em um grande. Obviamente, quanto mais arquivos criados pelo Memstore, mais trabalho (carga extra) para o sistema. Além disso, embora o processo de compactação geralmente seja executado em paralelo com o atendimento de outras solicitações e quando o HBase não puder acompanhar a compactação de HFiles (sim, há limites configurados para isso também), ele bloqueará as gravações no RS novamente. Como discutimos acima, isso é altamente indesejável.
Não podemos ter certeza de que os dados serão persistentes em todo o Memstore. Suponha que um datanode específico esteja inativo. Então, os dados que residem na memória desse nó de dados serão perdidos.
Para superar esse problema, quando a solicitação vem do mestre, ela também é gravada no WAL. WAL nada mais é Registros de gravação antecipada que reside no HDFS, um armazenamento permanente. Agora podemos ter certeza de que mesmo quando o nó de dados estiver inativo, os dados não serão perdidos, ou seja, temos a cópia de todas as ações que você deve realizar no WAL. Quando o nó de dados estiver ativo, ele executará todas as atividades novamente. Depois que a operação é concluída, tudo é eliminado do Memstore e do WAL e escrito em HFile para garantir que não estamos ficando sem memória.
Vamos dar um exemplo simples em que desejo adicionar a linha 10, em seguida, a solicitação de gravação chega, diz que fornece todos os metadados para o Memstore e WAL. Depois que essa linha específica é gravada no HFile, tudo no Memstore e no WAL é eliminado.
Funcionário do zoológico:
O HBase vem integrado com o Zoo Keeper. Quando eu inicio o HBase, a instância do Zoo Keeper também é iniciada. O motivo é que o Zoo Keeper nos ajuda a manter um controle de todos os servidores da região que existem para o HBase. O Zoo Keeper mantém registro de quantos servidores de região existem, quais servidores de região estão mantendo, de qual nó de dados para qual nó de dados. Ele mantém o controle de conjuntos de dados menores onde o Hadoop está perdendo. Ele diminui a sobrecarga no Hadoop, que mantém o controle da maioria dos seus metadados. Portanto, o HMaster obtém os detalhes dos servidores da região ao entrar em contato com o zelador do zoológico.
Tem alguma questão para nós? Mencione-os na seção de comentários e entraremos em contato com você.
php criar array a partir de string
Postagens relacionadas: