Apresentação - Facebook (NOSQL)

Prévia do material em texto

Cloud Computing
Chave/valor
Avinash Laskman
Criado em 2008
Prashant Malik
Prover um sistema de armazenamento distribuído
Altamente escalável
Eventualmente consistente
foram unidas características de dois sistemas NoSQL
No Cassandra, os dados são indexados por uma chave do tipo String. Essa chave referência uma linha, onde os dados se encontram, sendo que em cada linha os dados são divididos em colunas e famílias de colunas. Essas divisões dos dados serão explicadas nessa seção.
O Facebook utilizou o Cassandra para agilizar seu novo sistema de busca de mensagens lançado em 2008. O cluster utilizado tinha cerca de 600 núcleos, armazenando cerca de 150 terabytes de dados. Na época do uso, o sistema conseguia aguentar bem o uso da busca pelos 250 milhões de usuários da rede social. Em novembro de 2010, uma nova versão do sistema de mensagens do Facebook foi lançado. Durante o desenvolvimento dessa nova versão, foram testados três sistemas de armazenamento de dados diferentes: o bastante conhecido e relacional MySQL, o Cassandra e o HBase, que também utiliza a abordagem NoSQL. Depois dos vários testes realizados, a equipe do Facebook optou por utilizar o HBase como seu novo sistema de banco de dados, por ser bastante escalável, ter um bom balanceamento de carga, ter boa performance, entre outros fatores.
Modelo de dados e Arquitetura
Banco de Dados
Latência consistente em milissegundos: lide com milhões de solicitações por segundo;
conjuntos de dados esparsos armazenados em tabelas largas para grandes cargas de trabalho analíticas e operacionais.
Orientado por colunas e armazena seus dados no Datalake HDFS
Desenvolvido com um mecanismo de armazenamento para aplicativos de machine learning
Escala linearmente quando lida com grandes conjuntos de dados; combina facilmente fontes de dados que utilizam uma grande variedade de estruturas e esquemas diferentes;
Ideal para casos de uso como tecnologia de anúncios, fintech, mídias digitais e IoT;
CURIOSIDADE:
Além disso, algumas empresas usam o HBase internamente, como Twitter, Yahoo e Adobe etc.
Arquitetura do Hbase:
 
O HBase HMaster é um processo que executa operações DDL (criar e excluir tabelas) e atribui regiões aos Region Servers. Ele coordena e administra o Region Server (semelhante ao NameNode gerencia o DataNode no HDFS).
O HMaster atribui regiões aos Region Server na inicialização e reatribui regiões a Region Server durante a recuperação e o balanceamento de carga. Além disso, ele monitora todas as instâncias do Region Server no cluster (com a ajuda do Zookeeper) e executa atividades de recuperação sempre que qualquer Servidor de Região estiver desativado. Ele fornece uma interface para criar, excluir e atualizar tabelas. O HBase possui um ambiente distribuído e enorme onde o HMaster sozinho não é suficiente para gerenciar tudo. O ZooKeeper ajuda o HMaster a gerenciar o ecossistema
Arquitetura do Hbase:
 
Uma tabela pode ser dividida em várias regiões. Uma Região é um intervalo ordenado de linhas armazenando dados entre uma tecla de início e uma chave final, tem um tamanho padrão que pode ser configurado de acordo com a necessidade. Um grupo de regiões é servido aos clientes por um servidor de região. Uma região contém todas as linhas entre a tecla de início e a chave final atribuída a essa região. 
As tabelas HBase podem ser divididas em várias regiões de tal forma que todas as colunas de uma família de colunas são armazenadas em uma região. Cada região contém as linhas em uma ordem ordenada. Muitas regiões são atribuídas a um Region Server, que é responsável por manipular, gerenciar, executar operações nesse conjunto de regiões
Arquitetura do Hbase:
 
Zookeeper atua como um coordenador dentro do ambiente distribuído HBase. Ajudando a manter o estado do servidor dentro do cluster, comunicando-se através de sessões. Todo o Servidor da região, juntamente com o Servidor HMaster, envia heartbeat contínuos em intervalos regulares para o Zookeeper e verifica qual servidor está ativo e disponível como mencionado na imagem acima, ele também fornece notificações de falha de servidor para que, as medidas de recuperação possam ser executadas, de acordo com a imagem acima, podemos ver que existe um servidor inativo, que atua como um backup para o servidor ativo, se o servidor ativo falhar, ele fará o resgate. 
O HMaster ativo envia batimentos cardíacos para o Zookeeper enquanto o HMaster inativo escuta a notificação enviada pelo HMaster ativo. Se o HMaster ativo não enviar um batimento cardíaco, a sessão será excluída e o HMaster inativo se tornará ativo. Embora, se um servidor de região não enviar um batimento cardíaco, a sessão expirou e todos os ouvintes são notificados sobre isso. Em seguida, o HMaster realiza ações de recuperação, o Zookeeper também mantém o caminho do servidor META, ajudando o usuário na busca de qualquer região. O usuário primeiro deve verificar com o servidor META no qual Region Server pertence uma região, e ele obtém o caminho do Region Server.
Grupo
Ana Melo	 21130463
Larissa Gleyce Feitoza	 21342299	
Diferença entre NoSQL e Relacional
2021
Gravador de Voz
Slide 2
2021
Gravador de Voz
Slide 3
2021
Gravador de Voz
Slide 4
2021
Gravador de Voz
Slide 5
2021
Gravador de Voz
Slide 6
2021
Gravador de Voz
Slide 7
2021
Gravador de Voz
Slide 8
2021
Gravador de Voz
Slide 9
2021
Gravador de Voz
Slide 10
2021
Gravador de Voz
Slide 11