Sistemas Distribuídos

Transcrição

1 Cassandra - Particionamento de Dados Sistemas Distribuídos Douglas Macedo Hugo Lourenço

2 Sumário Introdução Conceito Anel Multíplos Data center Fatores envolvidos Arquitetura do Sistema Módulo de Particionamento Particionamento em Banco de Dados Distribuídos Experiências Práticas Conclusão

3 Introdução Vem se tornando cada vez mais popular entre as equipes de desenvolvimento que estão migrando para o NoSQL.Une: design completamente distribuído do Dynamo (Amazon) modelo de dados baseado em Column-Family do BigTable (Google) O maior cluster em produção tem cerca de 300 TB em mais de 400 máquinas Slide 3 de 30

4 Introdução NoSQL * Not only SQL (não somente sql) e não NO SQL (não ao sql) *Escalabilidade e Desempenho Cassandra VS MySQL (50GB)* Write: ~0.12 ms vs ~300 ms Read: ~15 ms vs ~350 ms *(tempos médios) Slide 4 de 30

5 Introdução Um particionador que determina qual dos nós irá armazenar os dados; O número de cópias de dados, que são determinados pela "estratégia de replicação"; A topologia do cluster: Número de nós; Distribuição de nós nos racks; Número de data centers. Slide 5 de 30

6 Conceito Cassandra particiona de forma transparente os dados em seus nodes participantes do database no cluster. Cada node fica responsável por uma parte do database global. Slide 6 de 30

7 Conceito Estrutura comum a NOSQL KeySpace Column Family Column key = "row key" (chave de linha) Slide 7 de 30

8 Conceito Cada linha de dados é identificada de forma única pela chave de linha da coluna. A distribuição no cluster se da pelo valor do Token. Slide 8 de 30

9 Anel do Cluster O número total de dados armazenados pelo cluster é representado pelo anel: Dividido em intervalos iguais ao número de nós; Cada nó pode ser responsável por um ou mais intervalos de dados. Um nodo (ex: um PC adicionado) pode-se juntar a um anel,onde lhe é atribuído um token, este determina: Posição do nodo no anel; Faixa de dados. Slide 9 de 30

10 Anel do Cluster Determinando onde o nodo irá ficar no anel: Em sentido horário se localiza o nodo com valor de chave maior do que a chave do nodo a entrar (ou da "row key"). Cada nó é responsável pela região entre si e de seu antecessor. No exemplo, nodo ZERO de 75 a 0. Slide 10 de 30

11 Múltiplos Data Center Clusters NetworkTopologyStrategy: principal estratégia de colocação de réplicas em múltiplos data center, ela especifica quantas réplicas se quer em cada data center Se coloca a primeira réplica para cada linha considerando o valor atribuído em cada nó. As réplicas adicionais são colocadas no mesmo data center, percorrendo em sentido horário até alcançar o próximo data center Slide 11 de 30

12 Múltiplos Data Center Clusters Considerando os nós individualmente a distribuição deve ser uniforme Distribuição de dados não-uniforme Distribuição de dados uniforme Valores dos tokens não devêm entrar em conflito Slide 12 de 30

13 Geração de Token Cassandra inclui uma ferramenta para geração de tokens o a no intervalo máximo possível (0 to 2^127-1)para uso com o RandomPartitioner Cada nó no cluster precisa ser atribuído um token antes de começar pela primeira vez. initial_token = é configurado no arquivo cassandra. yaml Slide 13 de 30

14 Geração de Token Single data center:./tools/bin/token-generator 4 Node #1: 0 Node #2: Node #3: Node #4: Mútiplos data centers usando NetworkTopologyStrategy (por padrão):./tools/bin/token-generator 4 4 DC #1: Node #1: Node #2: Node #3: Node #4: DC #2: Node #1: Node #2: Node #3: Node #4: Slide 14 de 30

15 Geração de Token Evitar colisão de tokens, colocando valores com offsset nos tokens, que permite um intervalo uniforme entre os novos nós Slide 15 de 30

16 Cassandra 1.2 Não é preciso cálculo de tokens se estiver usando virtual nodes (vnodes, novidade na versão) Remoção/Adição de nós sem precisar rebalancemento manual no cluster Reconstroi nós mortos mais rapidamente Melhora o uso de máquinas heterogêneas no cluster Murmur3Partitioner Provém um hash mais rápido e aumenta a performance do que a versão padrão anterior (RandomPartitioner) Usa função MurmurHash (o RandomPartitioner usa hash MD5) Slide 16 de 30

17 Consultas por Similaridade Os SGBDs oferecem recursos eficazes para realizar buscas sobre os dados usando relações de igualdade e de ordem total existentes nos dados armazenados (números e textos curtos) Com dados complexos nas buscas por igualdade ou por ordem não se aplicam. Para esses tipos de dados é mais relevante fazer uso de consultas por similaridade, que consistem em procurar por elementos em um conjunto que, segundo algum critério de similaridade, sejam mais parecidos ou mais distintos com/de um determinado elemento. Slide 17 de 30

18 Consultas por Similaridade Consulta por abrangência (Range query Rq): retorna todos os elementos dissimilares de um elemento de consulta até no máximo um certo limiar; Consulta aos k-vizinhos mais próximos (k-nearest Neighbors query k-nnq): retorna os k elementos mais similares ao elemento de consulta sq, isto é, os k elementos si pertence S com menor valor para S(si;sq). Slide 18 de 30

19 Arquitetura do Sistema Dynamo é uma tecnologia interna desenvolvida pela Amazon para a necessidade de ter escalabilidade e alta disponibilidade no sistema de armazenamento de key-value. A tecnologia possibilita: "trade-off"(custo conflitos); consistência; durabilidade; desempenho; alta disponibilidade. Slide 19 de 30

20 Arquitetura do Sistema Dynamo usa hashing consistentes para o particionamento. Os objetos e caches usam a mesma função hash. Vantagens: As máquinas terão um intervalo da escala de função hash e máquinas vizinhas pode levar mais porções do intervalo de seus nós adjacentes se sair e pode ceder parcelas de sua intervalo se algum nó novo membro se junta e é mapeado para um intervalo de perto. Os clientes podem facilmente determinar os nós para executar operações de leitura ou gravação. Slide 20 de 30

21 Arquitetura do Sistema Cada nó é mapeado para vários pontos no anel em vez de um único ponto. Usando o conceito de virtual tem vantagens: Distribuição da carga de trabalho de um nó para os nós disponíveis quando um nó se torna indisponível; Quando um novo nó é adicionado ou quando um se recupera de acidente, começará com carga 'igual' ao dos outros. Slide 21 de 30

22 NoSQL Data Stores Slide 22 de 30

23 Tabela de Comparação Slide 23 de 30

24 Módulo de Particionamento Importante na implantação do Cassandra: escolha de tokens para cada nó Qual nó armazenará os dados? Uso do OPP requer cautela na escolha de tokens; Na distribuição desequilibrada: mais dados são armazenados em um número menor de nós. O ideal é particionar de forma uniforme. Slide 24 de 30

25 Módulo de Particionamento Cassandra é escalável de forma incremental, as máquinas podem entrar e sair de um cluster; Os dados devem ser particionadas e distribuídas entre os nós de um cluster de uma forma que permite que reparticionamento e redistribuição; As tabelas no Cassandra são divididas e distribuídas em hashing consistentes como no Dynamo. Slide 25 de 30

26 Particionamento em Banco de Dados Distribuídos Hashing Consistente x Ordem de Presevação Uso de hash consistentes fornece um melhor esquema ("brain-dead") de balanceamento de carga a partir do algoritmo de hash espalhando chaves no anel; Não apresentou bons resultados na prática, a solução foi atribuir vários tokens para cada nó no cluster e existem várias abordagens para isso; No Cassandra o projeto original considerava o Hashing Consistente uma preferência de balanceamento de carga real. As chaves são distribuídas para os nós em sua ordem natural; Principal vantagem sobre o Hashing Consistente: Capacidade de fazer consultas de intervalo entre as chaves no sistema; O particionador usa a key para determinar em qual nó o dado está; Cada chave pode ter vários dados associados; [modelo de dados] Flexibilidade em consultas de abrangência por propagar os dados entre várias chaves. Slide 26 de 30

27 Wiki Cassandra: Informações de configurações do particionador Particionador: qualquer IPartitioner pode ser usado, incluindo o seu, desde que ele esteja no classpath. Fora da caixa, Cassandra fornece org. apache.cassandra.dht.randompartitioner, org.apache.cassandra.dht.orderpreservingpartitioner, org.apache.cassandra.dht. ByteOrderedPartitioner, e org.apache.cassandra.dht.collatingorderpreservingpartitioner. (CollatingOPP colates acordo com as regras EN, dos EUA, não ordena byte. Use isso como um exemplo, se você precisa localidade ciente.) A única diferença entre BOP e OPP é que a OPP requer chaves codificadas em UTF-8. Range exigem consultas usando um particionador ordem de preservação. Achtung!A alteração deste parâmetro limpa seus diretórios de dados, já que o particionador modifica o formato!sstable no disco. Se você estiver usando um particionador fim de preservação e você sabe que a sua distribuição de chaves, você pode especificar o símbolo para este nó usar. (As chaves são enviadas para o nó com os "mais próximos" token, para a distribuição de seus tokens igualmente ao longo do espaço de distribuição de chaves que vai se espalhar as chaves uniformemente no cluster.) Essa configuração só é verificada a primeira vez que um nó é iniciado. Isto pode também ser útil com RandomPartitioner forçar espaçamento igual em torno do espaço de hash, em especial para aglomerados com um pequeno número de nós. Cassandra usa hash MD5 internamente para colocar a hash das chves do anel em um RandomPartitioner. Portanto, faz sentido dividir o espaço de hash igualmente pelo número de máquinas disponíveis usando InitialToken ou seja, se existem 10 máquinas, cada um vai lidar com 1/10th de valor máximo hash) e esperar que as máquinas terão uma carga razoavelmente igual. Com OrderPreservingPartitioner as próprias chaves são utilizadas para armazenar no anel. Uma desvantagem do potencial desta abordagem é que, se as linhas são inseridas com chaves sequenciais, toda a carga de gravação irá para o mesmo nó. Padrão: 'org.apache.cassandra.dht.randompartitioner'. Atribuir manualmente os tokens é altamente recomendável para garantir uma distribuição uniforme de carga. Slide 27 de 30

28 Experiências Práticas Dentro do arquivo de configuração conf/cassandra.yaml Partitioner: qualquer IPartitioner pode ser usado, inclusive um próprio, desde que esteja no classpath. Cassandra provém: org.apache.cassandra.dht.randompartitioner (RP) org.apache.cassandra.dht.orderpreservingpartitioner (OPP) org.apache.cassandra.dht.byteorderedpartitioner (BOP) org.apache.cassandra.dht.collatingorderpreservingpartitioner (COPP) CollatingOPP agrupa de acordo com as normas do idioma EN,US, não sobre a ordem de byte nativo. É usado quando se precisa de agrupamento de cliente por localidade. A única diferença entre BOP e OPP é que requer chaves para ser codificado em UTF-8. "Consultas por abrangência" (" Range queries" ) requerem um particionador por ordem. A alteração deste parâmetro requer que você limpe os diretórios de dados, desde que o particionador pode modificar o formato de disco e!sstable. Utilizando o particionador por ordem " order-preserving partitioner" e sabendo a distribuição de chaves, pode-se especificar o token que seu nó usa (as chaves são enviadas para os nós com os tokens mais próximos, então a distribuição de tokens vai se espalhar uniformemente através do cluster). Essa configuração só é verificada na primeira vez que um nó e iniciado. Útil também com RandomPartitioner para forçar espaçamento uniforme de tokens em torno do espaço de hash, em especial de aglomerados com um pequeno número do nodos. Cassandra usa hash MD5 internamente para fazer hash das chaves para colocar o anel em um RandomPartitioner. Faz sentido dividir o espaço de hash uniformemente pelo número de maquinas usando um tokeninicial (initiantoken). Por exemplo: se tiver 10 máquinas, cada uma vai lidar com 1/10 de valor máximo do hash e esperar que as máquinas terão uma carga razoavelmente uniforme. Com OrderPreservingPartitioner as chaves delas próprias são colocadas sobre o anel. Uma potencial desvantagem desta abordagem é que estas linhas são inseridas com chaves sequências, toda a carga de gravação irá para o mesmo nó. O padrão é : 'org.apache.cassandra.dht.randompartitioner'. Tokens atribuídos de forma manual são recomendáveis para garantir uma distribuição uniforme de carga.. Slide 28 de 30

29 Conclusão O particionamento no Cassandra se dá através da técnica de hash consistente. Garante: melhor distribuição dos dados entre os nós existentes melhor balanceamento de carga nós servirão a múltiplas requisições ao mesmo tempo. Somada ao protocolo Gossip permite que um nó possa prever aonde está a linha referente à chave pesquisada, de maneira muito eficiente. Entretanto, a existência de um nó coordenador para um determinado conjunto de chaves ainda representa um ponto único de falha, ao menos para esse conjunto de dados. Por isso, o Cassandra replica de forma assíncrona os dados gravados em cada nó coordenador PARTICIONAMENTO + PROTOCOLO GOSSIP + REPLICAÇÃO = sem pontos de falha Slide 29 de 30

30 Referências Referências: arquitetura.pdf Slide 30 de 30

31 FIM