Disponível aqui: https://www.dropbox.com/s/vvy1nsjzhmzwn62/Trabalho%20NoSQL.pdf?dl=0
6 de fevereiro de 2015
Apresentação do Seminário
Segue link para download de arquivo PDF contendo a apresentação de slides apresentados em sala de aula. Clique na figura ou copie o link descrito abaixo para ter acesso ao arquivo.
Disponível aqui: https://www.dropbox.com/s/vvy1nsjzhmzwn62/Trabalho%20NoSQL.pdf?dl=0
Disponível aqui: https://www.dropbox.com/s/vvy1nsjzhmzwn62/Trabalho%20NoSQL.pdf?dl=0
Caso de Uso: Amara Health Analytics
Agora iremos expor uma entrevista do Planet Cassandra com Steve Nathan e Dwight Hare, respetivamente CEO e chefe de Arquitetura de Software da Amara Health Analytics.
"Como o Amara Health Analytics ajuda seus clientes?
Steve Nathan: 'Nós fornecemos apoio à decisão em tempo real para os médicos, ajudando na identificação precoce de pacientes do hospital com graves riscos e doenças de rápida progressão, como sepse. São pacientes que potencialmente vão piorar nas próximas horas ou dias, portanto uma intervenção é extremamente urgente. Obviamente, isso significa que analisamos muitos fluxos de dados em tempo real na natureza.'
Como os clientes utilizam seu software?
Steve Nathan: 'Para os médicos, que são os usuários finais, é muito simples. Eles recebem um alerta de mensagem de texto, a partir de nosso sistema em seu smartphone ou tablet que chama sua atenção para um paciente em situação de risco. A mensagem inclui variáveis clínicas fundamentais para fornecer o contexto para o alerta.
Em termos de TI, nosso software conecta múltiplas fontes de dados do hospital. Em termos gerais, existem três formas de analise de dados: estruturado - tais como códigos de médicos e outros valores numéricos; desestruturado narrativo clínico - como anotações do médico, relatórios operacionais e resumos de descarga; e em tempo real com sinais fisiológicos de dispositivos de monitoramento do paciente. Muitos desses dados nos vem em formato Health Level 7 (HL 7), mas podemos lidar com qualquer outro formato que o hospital possa ter.'
Qual técnica ou desafio de negócio que o levou a uma solução NoSQL contra um banco de dados relacional tradicional?
Dwight Hare: 'Um desafio significativo envolve o fato de termos uma grande quantidade de dados estruturados e não estruturados - mas isso é muito dinâmico, em que podemos passar a receber um feed de dados que nós não sabíamos quando construímos o sistema. O código que nós desenvolvemos é escrito em Java - a do lado do servidor normal, back-end das aplicações Java. Na verdade, é um interprete, porque queremos que o sistema seja muito dinâmico e seja capaz de ingerir novas fontes de dados que nós não sabíamos quando projetamos o sistema.
Precisávamos de algo que fosse muito dinâmico, no sentido de que o esquema pudesse mudar em tempo de execução, em tempo real. Nós também usamos grandes quantidades de textos narrativos longos, anotações de enfermagem, coisas desse tipo. Precisávamos fazer um monte de procura em texto, portanto, queria um tipo Solr de capacidade de consulta, em comparação com o que você recebe em SQL. SQL simplesmente não satisfaz todas as nossas necessidades, porque ele é muito hard-wired. Você tem que definir o esquema com antecedência, e isso não satisfaz muito bem aos dados não estruturados em termos de busca e manipulação. Decidimos, rapidamente, por um banco de dados NoSQL.
Olhamos em volta e o Cassandra e o DataStax Enterprise eram os líderes. Nós inserimos todos esses dados em uma variedade de Column Families, na nossa chamada principal, que é uma timeline do paciente, uma série temporal da natureza. Nós colocamos todos os dados que estavam em streaming dos pacientes nas timelines em ordem cronológica para cada paciente. Temos uma imagem de tudo o que aconteceu a esse paciente a partir do momento em que ele entrou no hospital até o que ele saiu, e mesmo depois de sair, os laboratórios podem obter os resultados mais tarde. Então, nós geramos outras column families a partir daí.
Nós também geramos uma column family para relatório, e é a partir daí que nós realizamos as análises. Nós temos uma combinação de processamento de linguagem natural, aprendizado de máquina e análise baseada em regras de modo que construímos um grande conjunto de regras bastante complexas que deduzem o estado dos pacientes com base nos dados que estamos recebendo, e em seguida, identificamos os riscos para a sua saúde.
Estamos a procura de um acúmulo de evidências que indicam uma deterioração no estado do paciente, e por isso temos regras complexas. As saídas das regras são derivadas dos dados.
Os dados brutos do histórico do paciente e os fatos derivados estão no relatório. Construímos este conjunto muito grande de dados e, em seguida, podemos usar consultas para executar mais relatórios. Uma das coisas importantes sobre o nosso produto é que, a fim de realmente demonstrar o seu valor, temos de mostrar que os alertas enviados tem um impacto significativo sobre o atendimento dos pacientes. Por isso, queremos mostrar ao longo de um período de tempo que os pacientes que receberam alertas e, portanto, receberam tratamento mais cedo, têm melhores resultados.
A grande coisa sobre o Cassandra, DataStax e Solr é que podemos separar os dados e gerar relatórios variados. Podemos mostrar que os efeitos são devidos aos nossos alertas contra os outros fatores.'
Você disse que nunca olhou para bancos de dados relacionais para esta aplicação - mas você avaliou outros bancos de dados NoSQL?
Dwight Hare: 'Sim, nós olhamos muitos deles. Nós escolhemos o Cassandra e o DataStax porque gostamos de software open-source e se você tem a comunidade você não fica preso. Além disso, o hook-up para o Solr foi muito importante para nós. A capacidade de pesquisa e a correta estabilidade da empresa resultou no nosso desenvolvimento, de modo muito mais rápido.'"
Fonte: Planeta Cassandra, Disponível em <http://planetcassandra.org/blog/amara-health-analytics-uses-cassandra-to-proactively-protect-patients-health/>, acessado 04 de fevereiro de 2015.
 |
| Fonte: http://planetcassandra.org/blogs/Upload/Poste6cf1d48-1f06-4b32-9876-9e0009fd05df/amara.png |
"Como o Amara Health Analytics ajuda seus clientes?
Steve Nathan: 'Nós fornecemos apoio à decisão em tempo real para os médicos, ajudando na identificação precoce de pacientes do hospital com graves riscos e doenças de rápida progressão, como sepse. São pacientes que potencialmente vão piorar nas próximas horas ou dias, portanto uma intervenção é extremamente urgente. Obviamente, isso significa que analisamos muitos fluxos de dados em tempo real na natureza.'
Como os clientes utilizam seu software?
Steve Nathan: 'Para os médicos, que são os usuários finais, é muito simples. Eles recebem um alerta de mensagem de texto, a partir de nosso sistema em seu smartphone ou tablet que chama sua atenção para um paciente em situação de risco. A mensagem inclui variáveis clínicas fundamentais para fornecer o contexto para o alerta.
Em termos de TI, nosso software conecta múltiplas fontes de dados do hospital. Em termos gerais, existem três formas de analise de dados: estruturado - tais como códigos de médicos e outros valores numéricos; desestruturado narrativo clínico - como anotações do médico, relatórios operacionais e resumos de descarga; e em tempo real com sinais fisiológicos de dispositivos de monitoramento do paciente. Muitos desses dados nos vem em formato Health Level 7 (HL 7), mas podemos lidar com qualquer outro formato que o hospital possa ter.'
Qual técnica ou desafio de negócio que o levou a uma solução NoSQL contra um banco de dados relacional tradicional?
Dwight Hare: 'Um desafio significativo envolve o fato de termos uma grande quantidade de dados estruturados e não estruturados - mas isso é muito dinâmico, em que podemos passar a receber um feed de dados que nós não sabíamos quando construímos o sistema. O código que nós desenvolvemos é escrito em Java - a do lado do servidor normal, back-end das aplicações Java. Na verdade, é um interprete, porque queremos que o sistema seja muito dinâmico e seja capaz de ingerir novas fontes de dados que nós não sabíamos quando projetamos o sistema.
Precisávamos de algo que fosse muito dinâmico, no sentido de que o esquema pudesse mudar em tempo de execução, em tempo real. Nós também usamos grandes quantidades de textos narrativos longos, anotações de enfermagem, coisas desse tipo. Precisávamos fazer um monte de procura em texto, portanto, queria um tipo Solr de capacidade de consulta, em comparação com o que você recebe em SQL. SQL simplesmente não satisfaz todas as nossas necessidades, porque ele é muito hard-wired. Você tem que definir o esquema com antecedência, e isso não satisfaz muito bem aos dados não estruturados em termos de busca e manipulação. Decidimos, rapidamente, por um banco de dados NoSQL.
Olhamos em volta e o Cassandra e o DataStax Enterprise eram os líderes. Nós inserimos todos esses dados em uma variedade de Column Families, na nossa chamada principal, que é uma timeline do paciente, uma série temporal da natureza. Nós colocamos todos os dados que estavam em streaming dos pacientes nas timelines em ordem cronológica para cada paciente. Temos uma imagem de tudo o que aconteceu a esse paciente a partir do momento em que ele entrou no hospital até o que ele saiu, e mesmo depois de sair, os laboratórios podem obter os resultados mais tarde. Então, nós geramos outras column families a partir daí.
Nós também geramos uma column family para relatório, e é a partir daí que nós realizamos as análises. Nós temos uma combinação de processamento de linguagem natural, aprendizado de máquina e análise baseada em regras de modo que construímos um grande conjunto de regras bastante complexas que deduzem o estado dos pacientes com base nos dados que estamos recebendo, e em seguida, identificamos os riscos para a sua saúde.
Estamos a procura de um acúmulo de evidências que indicam uma deterioração no estado do paciente, e por isso temos regras complexas. As saídas das regras são derivadas dos dados.
Os dados brutos do histórico do paciente e os fatos derivados estão no relatório. Construímos este conjunto muito grande de dados e, em seguida, podemos usar consultas para executar mais relatórios. Uma das coisas importantes sobre o nosso produto é que, a fim de realmente demonstrar o seu valor, temos de mostrar que os alertas enviados tem um impacto significativo sobre o atendimento dos pacientes. Por isso, queremos mostrar ao longo de um período de tempo que os pacientes que receberam alertas e, portanto, receberam tratamento mais cedo, têm melhores resultados.
A grande coisa sobre o Cassandra, DataStax e Solr é que podemos separar os dados e gerar relatórios variados. Podemos mostrar que os efeitos são devidos aos nossos alertas contra os outros fatores.'
Você disse que nunca olhou para bancos de dados relacionais para esta aplicação - mas você avaliou outros bancos de dados NoSQL?
Dwight Hare: 'Sim, nós olhamos muitos deles. Nós escolhemos o Cassandra e o DataStax porque gostamos de software open-source e se você tem a comunidade você não fica preso. Além disso, o hook-up para o Solr foi muito importante para nós. A capacidade de pesquisa e a correta estabilidade da empresa resultou no nosso desenvolvimento, de modo muito mais rápido.'"
Fonte: Planeta Cassandra, Disponível em <http://planetcassandra.org/blog/amara-health-analytics-uses-cassandra-to-proactively-protect-patients-health/>, acessado 04 de fevereiro de 2015.
Caso de Uso: Globo.com
Nesse post é relatado o depoimento do engenheiro de software sênior da Globo, Juarez Bochi, sobre a necessidade de implantação e sua experiência implantando a base de dados Cassandra.
"Globo.com é o braço da Internet do Grupo Globo, o maior conglomerado de mídia da América Latina. Recentemente transmitimos a Copa do Mundo da FIFA 2014 para mais de 450 mil usuários simultâneos.
Nosso novo player, chamado Clappr, suporta HLS, um protocolo que também da suporte as duas principais plataformas móveis: Android e iOS. Isto é uma enorme vantagem, porque podemos transmitir para web e para clientes móveis com um único protocolo, mantendo nossa arquitetura muito simples e eficiente. Basicamente, usamos um codificador (principalmente o Elemental) para codificar um sinal de vídeo em H.264 e ingerir o fluxo de vídeo em nosso segmentador (EvoStream) usando o protocolo RTMP. O Evostrean cria os pedaços de vídeo HLS e as listas de reprodução de vídeo em disco, isso porque HLS é baseada em HTTP, podemos usar um par de servidores distribuídos geograficamente de camada Nginx para fornecer e armazenar em cache os arquivos de vídeo.
Retrocedendo o Redis
Um dos novos recursos da nossa plataforma de streaming de vídeo ao vivo, desenvolvido para o Copa do Mundo foi o DVR, ou Digital Video Recording. Nós mantivermos o último par de horas do fluxo de vídeo gravado, para que o usuário pudesse pausar ou buscar de novo para assistir o gol que ele perdeu. Para a Copa do Mundo, que só tinha duas partidas simultâneas, portanto poderíamos facilmente manter os fluxos na memória. Para adicionar este recurso criamos um aplicativo Python que move os segmentos de vídeo HLS para o Redis que depois roteiriza o Nginx com Lua para obter os segmentos do Redis e gerar a lista de reprodução do HLS dinamicamente.
O principal problema com esta solução é que ela não tem alta disponibilidade. Se um servidor Redis falhar (o que é raro, mas acontece) gostaríamos de mudar para outra instância Redis para não perder todo o vídeo gravado. Felizmente isso não aconteceu durante qualquer partida da Copa do Mundo (embora não me importaria de excluir esses 7 gols da Alemanha). A outra questão é que esta solução não escala bem para mais fluxos. Uma vez que cada fluxo requer cerca de 10GB por hora registrado, não foi possível gravar muito mais do que dois ou três fluxos com uma única instância do Redis.
O Brasil teve recentemente eleições para presidente e governador e queríamos transmitir todos os 27 debates de governo que ocorreriam simultaneamente com a funcionalidade DVR. Mas como nossa solução com Redis não é escalável decidimos dar uma oportunidade ao Cassandra.
Acabou por ser relativamente simples modificar o nosso software Python para enviar os arquivos para o Cassandra, em vez do Redis, usando o driver DataStax Python. O problema mais difícil foi lidar a grande relação de arquivo de eventos que a aplicação tinha. Nos acabamos criando vários processos Phyton e usando execuções assíncrona. Outra questão é que nós não sabíamos como iríamos extrair os blods do Cassandra e entregá-los usando Nginx, uma vez que não foi possível encontrar um driver Cassandra disponível para Lua ou Nginx. Nós pensamos sobre o desenvolvimento de um aplicativo Python, mas somos grandes fãs de Lua e Ngnix, por isso, decidimos ir em frente e desenvolver o nosso próprio driver para Lua: lua-Resty-Cassandra; sim, é open source! Quando ficou pronto tornou-se muito fácil de portar nossos scripts Lua do Redis para o Cassandra.
Anti-padrões e Compactação no Cassandra
Nossa solução funcionou, mas o tempo de resposta com o Cassandra aumentou muito depois de algumas horas. Depois de um certo ponto, os clientes passariam do tempo limite (timeout) e a reprodução de vídeo iria parar. Levou umas semanas para nós percebermos que tínhamos implementado um conhecido anti-padrão do Cassandra: Queues e queue-like datasets.
Felizmente nós poderíamos resolver o problema com algumas mudanças simples.
Nós desnormalizamos nossos dados, usando diferentes tabelas em pedaços (uma vez que cada pedaço de vídeo pode ter até 2MB) e pedaço do index (que são armazenados como linhas e podem conter alguns milhares de colunas).
Mudamos a estratégia de compactação para LeveledCompactionStrategy, que funciona melhor quando você tem que fazer compactações frequentes. Ajustamos durable_writes para False já que a maioria dos nossos dados são efêmeros.
Por último e mais importante, pois sabíamos o tamanho máximo que uma lista poderia ter, podemos especificar a coluna de partida (filtering with id > minTimeuuid(now – playlist_duration)), como sugerido no blog do DataStax. Isso realmente atenua o efeito tombstones para leituras.
Após estas alterações, fomos capazes de alcançar uma latência na ordem de 10ms para o nosso percentual de 99%. Os debates foram realizados e fomos capazes de transmitir todos os 27 fluxos com 2 horas de gravação, sem grandes problemas. Estamos muito felizes com o Cassandra agora.
Detalhes da implantação
Estamos usando apenas 4 nós no momento. Cada nó tem 24 núcleos, 64GB de RAM, 6 discos e estamos executando o Cassandra 2.1.0 no RHEL 6.5. Temos cerca de 60GB de dados armazenados em cada nó (o RF é 2). A taxa de fluxo de rede é de cerca de 65 Mbits/s. A carga média da CPU é menor que 1. A latência de leitura de 99% é de 10ms e a latência de escrita de 99% é de 30ms."
Fonte: Planet Cassandra, Disponível em <http://planetcassandra.org/blog/interview/globo-rewinds-redis-for-their-dvr-system-fast-forwards-to-apache-cassandra-for-increased-availability/>, Acessado 04 de fevereiro de 2015.
 |
| Fonte: http://planetcassandra.org/wp-content/uploads/2014/10/logo_globo-e1338484540158.jpg |
"Globo.com é o braço da Internet do Grupo Globo, o maior conglomerado de mídia da América Latina. Recentemente transmitimos a Copa do Mundo da FIFA 2014 para mais de 450 mil usuários simultâneos.
Nosso novo player, chamado Clappr, suporta HLS, um protocolo que também da suporte as duas principais plataformas móveis: Android e iOS. Isto é uma enorme vantagem, porque podemos transmitir para web e para clientes móveis com um único protocolo, mantendo nossa arquitetura muito simples e eficiente. Basicamente, usamos um codificador (principalmente o Elemental) para codificar um sinal de vídeo em H.264 e ingerir o fluxo de vídeo em nosso segmentador (EvoStream) usando o protocolo RTMP. O Evostrean cria os pedaços de vídeo HLS e as listas de reprodução de vídeo em disco, isso porque HLS é baseada em HTTP, podemos usar um par de servidores distribuídos geograficamente de camada Nginx para fornecer e armazenar em cache os arquivos de vídeo.
Retrocedendo o Redis
Um dos novos recursos da nossa plataforma de streaming de vídeo ao vivo, desenvolvido para o Copa do Mundo foi o DVR, ou Digital Video Recording. Nós mantivermos o último par de horas do fluxo de vídeo gravado, para que o usuário pudesse pausar ou buscar de novo para assistir o gol que ele perdeu. Para a Copa do Mundo, que só tinha duas partidas simultâneas, portanto poderíamos facilmente manter os fluxos na memória. Para adicionar este recurso criamos um aplicativo Python que move os segmentos de vídeo HLS para o Redis que depois roteiriza o Nginx com Lua para obter os segmentos do Redis e gerar a lista de reprodução do HLS dinamicamente.
O principal problema com esta solução é que ela não tem alta disponibilidade. Se um servidor Redis falhar (o que é raro, mas acontece) gostaríamos de mudar para outra instância Redis para não perder todo o vídeo gravado. Felizmente isso não aconteceu durante qualquer partida da Copa do Mundo (embora não me importaria de excluir esses 7 gols da Alemanha). A outra questão é que esta solução não escala bem para mais fluxos. Uma vez que cada fluxo requer cerca de 10GB por hora registrado, não foi possível gravar muito mais do que dois ou três fluxos com uma única instância do Redis.
O Brasil teve recentemente eleições para presidente e governador e queríamos transmitir todos os 27 debates de governo que ocorreriam simultaneamente com a funcionalidade DVR. Mas como nossa solução com Redis não é escalável decidimos dar uma oportunidade ao Cassandra.
Acabou por ser relativamente simples modificar o nosso software Python para enviar os arquivos para o Cassandra, em vez do Redis, usando o driver DataStax Python. O problema mais difícil foi lidar a grande relação de arquivo de eventos que a aplicação tinha. Nos acabamos criando vários processos Phyton e usando execuções assíncrona. Outra questão é que nós não sabíamos como iríamos extrair os blods do Cassandra e entregá-los usando Nginx, uma vez que não foi possível encontrar um driver Cassandra disponível para Lua ou Nginx. Nós pensamos sobre o desenvolvimento de um aplicativo Python, mas somos grandes fãs de Lua e Ngnix, por isso, decidimos ir em frente e desenvolver o nosso próprio driver para Lua: lua-Resty-Cassandra; sim, é open source! Quando ficou pronto tornou-se muito fácil de portar nossos scripts Lua do Redis para o Cassandra.
Anti-padrões e Compactação no Cassandra
Nossa solução funcionou, mas o tempo de resposta com o Cassandra aumentou muito depois de algumas horas. Depois de um certo ponto, os clientes passariam do tempo limite (timeout) e a reprodução de vídeo iria parar. Levou umas semanas para nós percebermos que tínhamos implementado um conhecido anti-padrão do Cassandra: Queues e queue-like datasets.
Felizmente nós poderíamos resolver o problema com algumas mudanças simples.
Nós desnormalizamos nossos dados, usando diferentes tabelas em pedaços (uma vez que cada pedaço de vídeo pode ter até 2MB) e pedaço do index (que são armazenados como linhas e podem conter alguns milhares de colunas).
Mudamos a estratégia de compactação para LeveledCompactionStrategy, que funciona melhor quando você tem que fazer compactações frequentes. Ajustamos durable_writes para False já que a maioria dos nossos dados são efêmeros.
Por último e mais importante, pois sabíamos o tamanho máximo que uma lista poderia ter, podemos especificar a coluna de partida (filtering with id > minTimeuuid(now – playlist_duration)), como sugerido no blog do DataStax. Isso realmente atenua o efeito tombstones para leituras.
Após estas alterações, fomos capazes de alcançar uma latência na ordem de 10ms para o nosso percentual de 99%. Os debates foram realizados e fomos capazes de transmitir todos os 27 fluxos com 2 horas de gravação, sem grandes problemas. Estamos muito felizes com o Cassandra agora.
Detalhes da implantação
Estamos usando apenas 4 nós no momento. Cada nó tem 24 núcleos, 64GB de RAM, 6 discos e estamos executando o Cassandra 2.1.0 no RHEL 6.5. Temos cerca de 60GB de dados armazenados em cada nó (o RF é 2). A taxa de fluxo de rede é de cerca de 65 Mbits/s. A carga média da CPU é menor que 1. A latência de leitura de 99% é de 10ms e a latência de escrita de 99% é de 30ms."
Fonte: Planet Cassandra, Disponível em <http://planetcassandra.org/blog/interview/globo-rewinds-redis-for-their-dvr-system-fast-forwards-to-apache-cassandra-for-increased-availability/>, Acessado 04 de fevereiro de 2015.
Caso de Uso: eBuddy
Nessas três últimas publicações da matéria de Sistemas de Informação, o blog trará trechos de uma entrevista cedida pelos responsáveis das implantações do Cassandra nas empresas em que trabalham. Começaremos com o caso do eBuddy.
Confira parte da entrevista do Planeta Cassandra com Eric Zoerner, desenvolvedor de software sênior no eBuddy.
"Hoje temos aqui Eric Zoerner, desenvolvedor de software sênior no eBuddy. Eric, muito obrigado por se juntar a nós. Estou realmente ansioso para saber como você está utilizando o Cassandra. Para começar você poderia nos contar um pouco sobre o que é o eBuddy e o que ele faz?
Sim, o eBuddy tem uma plataforma de mensagens, que é compatível com aplicativos moveis e uma interface web para envio através da Internet como um substituto do SMS, apresenta também mensagens de mídia, descobre a localização de outros contatos e vários outros recursos. Nós agora estamos nos concentrando em apoiar conversas em grupo com controle de compartilhamento de mídias e locais. É uma aplicação social híbrida baseada no envio de mensagens.
Excelente. Isso é como multi-plataforma?
Sim. nós atualmente damos suporte a iPhone, Android e web.
Como o Cassandra é incorporado a essa mistura no eBuddy?
Usamos o Cassandra como o principal banco de dados para vários serviços diferentes. Mas também usamos o MySQL e Hadoop para armazenamento de dados. Para o Cassandra nos usamos para os dados de usuários e para encontrar novos contatos, com o serviço de descoberta. Utilizamos também para armazenamento de sessões persistentes. Além disso usamos para o histórico de mensagem e para um banco de dados Geo Hashing para descoberta de localização, onde você pode encontrar pessoas que estão nas proximidades que estão utilizando o XMS, que é o nome do nosso aplicativo de mensagens.
Muito interessante. Então em seguida ele armazena a localização real no Cassandra?
Sim, usando o Geo Hashing armazenamos o hash das redes baseadas em latitude e longitue.
Muito legal. Houve uma outra tecnologia que você avaliou ou comparou com o Cassandra antes de adota-lá?
Sim, nós também tivemos um olhar mais atento ao HBase como uma possibilidade e, finalmente, decidimos, pelo Cassandr por uma série de razões, por ser escrito em Java, open source e facilidade de adicionar e remover nós. A fácil configuração foi uma das grandes coisas, na medida em que é simples levantar e executar em comparação as outras soluções. Nós também usamos Hadoop em nossa empresa, mas nós usamos isso para para o nosso armazenamos de dados, um propósito bastante diferente.
Você poderia compartilhar com a gente um pouco com o que se parece sua implementação?
Nós temos basicamente três diferentes classes de máquinas que usamos em três grupos diferentes. Um deles é o nosso serviço de dados do usuário onde usamos quatro hosts e temos um fator de replicação de três. Isso com oito núcleos Hyperthreading RAID 10 discos e 48GB de RAM. Isso faz parte do mesmo cluster com nossas máquinas de armazenamento de dados, o que é, na verdade, apenas uma máquina, mas em um Data Center separado. Usamos isso para cálculo de sugestão de segundo grau. Nós também usamos Neo4J isso em conjunto para os cálculos gráficos. Essa máquina tem drives SSD de 2,1 terabytes e 48GB de RAM. Então nós temos nosso cluster de armazenamento de sessão persistente, o que é de quatro máquinas, 64 gigas, 12 núcleos com tecnologia hyperthreading e também SSDs, dois SSDs de 256 gigas.
Você está utilizando replicação em múltiplos datas centers?
Apenas para o nosso data warehouse. Temos o nosso cluster de dados do usuário, que também é utilizado para o histórico das mensagens e que está ligado à nossa máquina data warehouse no mesmo cluster em um data center separado, onde apenas enviamos uma réplica para a máquina data warehouse para que ele possa usar isso informações para o cálculo de segundo grau das sugestões. Então nós usamos os dados com os três réplicas como nosso banco de dados primário de produção."
Fonte: Planet Cassandra, Disponível em <http://planetcassandra.org/blog/ebuddy-uses-cassandra-as-geo-hashing-database-for-location-discovery/>, Acesso em 04 de fevereiro de 2015.
Confira parte da entrevista do Planeta Cassandra com Eric Zoerner, desenvolvedor de software sênior no eBuddy.
 |
| Fonte: http://planetcassandra.org/blogs/Upload/Post1f5ac37a-75b1-42c0-8354-d786483328c8/ebuddy_01.png |
"Hoje temos aqui Eric Zoerner, desenvolvedor de software sênior no eBuddy. Eric, muito obrigado por se juntar a nós. Estou realmente ansioso para saber como você está utilizando o Cassandra. Para começar você poderia nos contar um pouco sobre o que é o eBuddy e o que ele faz?
Sim, o eBuddy tem uma plataforma de mensagens, que é compatível com aplicativos moveis e uma interface web para envio através da Internet como um substituto do SMS, apresenta também mensagens de mídia, descobre a localização de outros contatos e vários outros recursos. Nós agora estamos nos concentrando em apoiar conversas em grupo com controle de compartilhamento de mídias e locais. É uma aplicação social híbrida baseada no envio de mensagens.
Excelente. Isso é como multi-plataforma?
Sim. nós atualmente damos suporte a iPhone, Android e web.
Como o Cassandra é incorporado a essa mistura no eBuddy?
Usamos o Cassandra como o principal banco de dados para vários serviços diferentes. Mas também usamos o MySQL e Hadoop para armazenamento de dados. Para o Cassandra nos usamos para os dados de usuários e para encontrar novos contatos, com o serviço de descoberta. Utilizamos também para armazenamento de sessões persistentes. Além disso usamos para o histórico de mensagem e para um banco de dados Geo Hashing para descoberta de localização, onde você pode encontrar pessoas que estão nas proximidades que estão utilizando o XMS, que é o nome do nosso aplicativo de mensagens.
Muito interessante. Então em seguida ele armazena a localização real no Cassandra?
Sim, usando o Geo Hashing armazenamos o hash das redes baseadas em latitude e longitue.
Muito legal. Houve uma outra tecnologia que você avaliou ou comparou com o Cassandra antes de adota-lá?
Sim, nós também tivemos um olhar mais atento ao HBase como uma possibilidade e, finalmente, decidimos, pelo Cassandr por uma série de razões, por ser escrito em Java, open source e facilidade de adicionar e remover nós. A fácil configuração foi uma das grandes coisas, na medida em que é simples levantar e executar em comparação as outras soluções. Nós também usamos Hadoop em nossa empresa, mas nós usamos isso para para o nosso armazenamos de dados, um propósito bastante diferente.
Você poderia compartilhar com a gente um pouco com o que se parece sua implementação?
Nós temos basicamente três diferentes classes de máquinas que usamos em três grupos diferentes. Um deles é o nosso serviço de dados do usuário onde usamos quatro hosts e temos um fator de replicação de três. Isso com oito núcleos Hyperthreading RAID 10 discos e 48GB de RAM. Isso faz parte do mesmo cluster com nossas máquinas de armazenamento de dados, o que é, na verdade, apenas uma máquina, mas em um Data Center separado. Usamos isso para cálculo de sugestão de segundo grau. Nós também usamos Neo4J isso em conjunto para os cálculos gráficos. Essa máquina tem drives SSD de 2,1 terabytes e 48GB de RAM. Então nós temos nosso cluster de armazenamento de sessão persistente, o que é de quatro máquinas, 64 gigas, 12 núcleos com tecnologia hyperthreading e também SSDs, dois SSDs de 256 gigas.
Você está utilizando replicação em múltiplos datas centers?
Apenas para o nosso data warehouse. Temos o nosso cluster de dados do usuário, que também é utilizado para o histórico das mensagens e que está ligado à nossa máquina data warehouse no mesmo cluster em um data center separado, onde apenas enviamos uma réplica para a máquina data warehouse para que ele possa usar isso informações para o cálculo de segundo grau das sugestões. Então nós usamos os dados com os três réplicas como nosso banco de dados primário de produção."
Fonte: Planet Cassandra, Disponível em <http://planetcassandra.org/blog/ebuddy-uses-cassandra-as-geo-hashing-database-for-location-discovery/>, Acesso em 04 de fevereiro de 2015.
27 de janeiro de 2015
NoSQL Matters
O post dessa semana será diferente, em vez de dar exemplos de uso, casos de sucesso ou até mesmo de discutir sobre implementações, vamos chamar a atenção para uma conferência anual chamada NoSQl Matters que, como pode ser inferido do próprio nome, trata de assuntos referentes ao NoSQL, principalmente quanto ao seu uso, importância e apostas e previsões para o futuro.
 |
| Fonte: http://2015.nosql-matters.org/par/wp-content/uploads/2014/10/nosqlmatters-gro%C3%9F.png |
A edição de 2015 será em Paris, na França, nos dias 26 e 27 de Fevereiro, existem 3 opções de ingressos para o evento, precificados conforme disposição de conteúdo para cada, os preços e disponibilidades de ingresso podem ser consultados aqui.
O evento é direcionado para profissionais da área e estudantes que queiram obter mais conhecimento acerca do NoSQL, diversas palestras serão ministradas, a agenda pode ser conferida aqui. Esta será a quarta edição do encontro, abaixo segue link para edições anteriores, onde estão disponíveis palestras e arquivos de mídia apresentados e discutidos nos eventos:
- NoSQL Matters 2012 - Barcelona, Espanha;
- NoSQL Matters 2013 - Cologne, Alemanha;
- NoSQL Matters 2014 (Setembro) - Dublin, Irlanda;
- NoSQL Matters 2014 (Novembro) - Barcelona, Espanha;
 |
| Fonte: https://s3.amazonaws.com/lanyrd-image-uploads/cropped-profile-photos/e3a312ba79baec59faa9e4b354d7a7823dfd640c.jpeg |
O evento próximo contará com a presença de diversos palestrantes
de empresas bastante conhecidas como : Google, Amazon, Red Hat,
Microsoft entre outras.A ideia central desse post é mostrar que o NoSQL está ativo e possui muitos interessados em seu crescimento e constante melhoria, parece ser algo que realmente veio para ficar, dadas suas diversas contribuições a diversos serviços e empresas, como fora ilustrado previamente neste blog.
Site oficial do evento NoSql Matters 2015. Disponível em <http://2015.nosql-matters.org>. Acesso em 27/01/2015.
20 de janeiro de 2015
Java + Redis
Neste tópico será apresentado um pequeno código Java para um cliente Redis. Para que o mesmo funcione é necessário baixar a biblioteca JRedis, disponível aqui. O JRedis é uma biblioteca leve que mapeia comandos nativos do Redis com métodos Java simples.
 |
| Fonte: http://app42paas.shephertz.com/wp-content/themes/twentytwelve/images/devcenter/integrate_icons/redis/redis_java.png |
O código abaixo estabelece uma conexão usando Java e a biblioteca JRedis com um servidor Redis em execução na própria máquina, Localhost. Não faz nada em especial, apenas um teste para mostrar a integração do banco em questão com a linguagem Java.
 |
| Fonte: Base de dados do MVJ-UFS |
 | |
| Fonte: Base de dados do MVJ-UFS |
Assim como usando Java, é possível estabelecer conexões com um banco Redis com diversas outras linguagens, há clientes para Ruby, Phyton, PHP e diversos outros. A existência de tamanha variedade de clientes ratifica ainda mais a importância atual do Redis no mundo NoSQL.
Referências:
Java Redis Client For Begineers. Disponível em <http://neopatel.blogspot.ca/2010/07/java-redis-client-for-begineers.html>. Acesso em 20/01/2015.
Redis - Java. Disponível em <http://www.tutorialspoint.com/redis/redis_java.htm>. Acesso em 20/01/2015.
Demo Redis NOSQL Server with Java application for very fast insert write and read. Disponível em <https://www.youtube.com/watch?v=RqbMoMjblVo#t=129>. Acesso em 20/01/2015.
19 de janeiro de 2015
Estudo de caso: Redis e Pinterest
O Pinterest é uma famosa rede social de compartilhamento de fotos, afiliado ao Twitter e Facebook, cresceu muito nos últimos anos, possui aplicativos para ios e também para Android. Apenas no ano de 2012 a empresa cresceu mais do que 1047% no número de usuários e postagens que acessaram o serviço via browser em seus computadores pessoais, já no meio mobile o crescimento foi ainda maior, cerca de 1698%.
 |
| Crescimento do Pinterest entre 2006 a 2012. Fonte: http://dstevenwhite.com/wp-content/uploads/2013/02/Pinterest-2006-to-2012.jpg |
O crescimento do sistema trouxe também o aumento da complexidade de sua manutenção, já que praticamente todas as telas da interface realizam ao menos uma consulta para checar se um quadro (onde um usuário reúne publicações no Pinterest) ou um usuário já é seguido. É aí que entra o Redis.
 |
| Fonte: http://blog.pivotal.io/wp-content/uploads/2013/07/header-graphic-redis-at-pinterest-150x150.jpg |
Sempre que um usuário "A" entra no Pinterest, o Redis mantém em background vários tipos de listas que guardam informações necessárias para a melhor experiência do usuário:
- Uma lista de usuários que "A" segue;
- Uma lista de quadros (em conjunto com os usuários relacionados) que "A" segue;
- Uma lista dos seguidores de "A";
- Uma lista de pessoas que seguem os quadros de "A";
- Uma lista de quadros que "A" segue;
- Uma lista de quadros que "A" deixou de seguir, depois de seguir um novo usuário;
- Os seguidores e não seguidores de cada quadro.
Cada id de usuário é dividida em 8192 "shards" virtuais, sendo que cada shard roda um banco Redis. Como o Redis é do modo "single trheaded", múltiplos bancos Redis rodam em uma só instância e múltiplas instâncias rodam numa máquina, de modo a aproveitar melhor o uso da CPU. Todas as listas rodam na memória, o Redis usa o serviço Amazon EBS (Elastic Block Store) para salvar o log de todas operações em disco.
Referências:
Sobre o Pinterest. Disponível em <https://about.pinterest.com/pt-br>. Acesso em 19/01/2015.
Using Redis at Pinterest for Billions of Relationships. Disponível em <http://blog.pivotal.io/pivotal/case-studies-2/using-redis-at-pinterest-for-billions-of-relationships>. Acesso em 19/01/2015.
Building a Follower Model From Scratch. Disponível em <http://engineering.pinterest.com/post/55272557617/building-a-follower-model-from-scratch>. Acesso em 19/01/2015.
9 de janeiro de 2015
Inserindo e consultando registros em um cluster Cassandra
Já foi visto como se criar um conexão a um cluster Cassandra em Java, também vimos como criar um keyspace e columns families, agora daremos continuidade ao projeto, aprendendo como inserir um registro e como buscá-lo na base de dados.
Começaremos incluindo o método inserirUsuario na classe BlogDB, ele terá a função de iniciar uma conexão com o cluster, depois, já com a conexão ativa iremos utilizar a sessão (session) para executarmos o comando CQL de inserção (insert) e, por, fim encerramos a conexão (close), como ilustrado na imagem abaixo.
 |
| Método inserirUsuario da classe BlogDB |
Para consultar esse registro será necessário criar um novo método, chamaremos de buscarUsuario, seu código é parecido com o do método anterior inserirUsuario. O resultado do execute será armazenado em uma variável do tipo ResultSet, após isso serão necessárias iterações para acessar os dados.
 |
| Método buscarUsuario da classe BlogDB |
Alteraremos então o código da classe Principal, de modo a chamar inserirUsuario e buscarUsuario, como ilustrado na imagem abaixo.
 |
| Método main da classe Principal |
Referência:
Datastax, disponível em <http://www.datastax.com/documentation/developer/java-driver/1.0/java-driver/quick_start/qsSimpleClientAddSession_t.html>, Acessado em 09 de janeiro de 2015;
Planeta Cassandra, disponível em <https://cassandra.apache.org/doc/cql/CQL.html>, Acesso em 09 de janeiro de 2015.
Porque o Twitter migrou para o Cassandra?
Em 2010 o Twitter resolveu migrar sua base de dados do MySQL para uma outra, para tentar solucionar os mais variados tipos de problemas. O maior desses problemas era o crescente volume de dados diário, o número de acessos pulou de 2 para 50 milhões, no período de janeiro de 2009 até janeiro de 2010. Mas porque o Cassandra?
 |
| Fonte: http://upload.wikimedia.org/wikipedia/commons/thumb/5/5e/Cassandra_logo.svg/2000px-Cassandra_logo.svg.png |
Outras bases de dados foram estudadas para substituir o banco relacional utilizado pelo Twitter, entre elas, as 'concorrentes' do Cassandra como: HBase, Voldemort, MongoDB, MemCacheDB, Redis e HyperTable. Entretanto, para os engenheiros envolvidos no processo, o Cassandra era o mais adequado por apresentar maior escalabilidade, confiabilidade e ser fácil de gerenciar do que as alternativas.
 |
| Fonte: http://www.site-seeker.com/wp-content/uploads/twitter-logo.png |
O processo de migração começou pela tabela de status, considerada a parte mais dolorosa, por se tratar da tabela que contém todos os tweets e retweets. Mas a princípio, para minimizar o tempo de inatividade, o Twitter busca implementar novos recursos para utilizar o Cassandra com o MySQL, de maneira a evitar imprevistos. Somente depois de testes o MySQL será definitivamente aposentado do Twitter.
"Nosso processo para efetuar mudanças importantes na infraestrutura pode ser resumido como 'integre primeiro, depois promova a iteração'" (Ryan King, engenheiro do Twitter).
Fonte: Computer World, Disponível <http://computerworld.com.br/tecnologia/2010/02/23/crescimento-faz-twitter-trocar-o-mysql-pelo-cassandra/>, Acessado em 9 de janeiro de 2015.
Redis - Quem está usando? (Parte 2)
De forma a dar continuidade ao post anterior (Redis - Quem está usando? (Parte 1)), segue mais uma pquena lista de empresas que também fazem uso do Redis.
1 - Flickr
 |
| Fonte: http://cdn.firespring.com/images/3cd32354-cddd-48f1-9d6c-3c72f274a74b.jpg |
O Flickr é um conhecido serviço de armazenamento e compartilhamento de imagens. Nessa página um engenheiro que trabalha no Flickr fala sobre determinadas características do serviço, até que toca no nome do Redis, dizendo que o Flickr faz uso de Lists do Redis, por questões de desempenho no manejo de filas.
2 - Stack Overflow
 |
| Fonte: http://www.logoeps.net/wp-content/uploads/2013/06/stackoverflow_logo.jpg |
Não há como acreditar que haja algum estudante de Sistemas de Informação que não tenha ao menos ouvido falar desse site. Basta uma simples dúvida acerca de programação em determinada linguagem que algum(s) dos resultado(s) encontrado(s) pelo site de buscas certamente será(ão) do stack overflow.
Quando um usuário levantou o questionamento nesse site acerca do uso de caching por parte do stack overflow, um membro da equipe do stack ficou bastante empolgado em dizer que usam sim caching, e que o fazem com o Redis como uma camada de caching para toda a rede. Disse ainda que o site trabalha com uma média de 1.300.000 (hum milhão e trezentas mil) chaves em cache no Redis, muitas das quais expiram dentro de alguns minutos de acordo com os acessos do serviço, disse também que o número de chaves em cache cresce à medida em que eles ganham mais confiança no Redis.
3 - Digg
 |
| Fonte: http://registroen.com/wp-content/uploads/2014/08/Digg.png |
Agregador de notícias criado em 2004 com o intuito de prover conteúdos diversos, mas que sejam mais específicos para o público de internet, tais como: assuntos relacionados a ciência e tecnologia e também questões políticas. O Redis está presente no Digg nos contadores de eventos de página cumulativos, como pode ser visto aqui e, assim como no stack overflow, é usado no Digg para caching.
A respeito dos contadores no Digg, são single-threaded, o que torna possível a atualização sequencial dos valores, de acordo com o seguinte site, sem que haja nenhum problema de perda de informações causada por problemas de comunicação oriundos de processos concorrentes.
Referências:
Who's using Redis? Disponível em <http://redis.io/topics/whos-using-redis>. Acesso em 09/01/2014.
Criando um keyspace dinamicamente em um cluster Cassandra
Nesse post iremos falar como se cria um keyspace dinamicamente em uma base de dados Cassandra através de uma aplicação Java, o exemplo utilizado será o mesmo do post anterior.
Utilizaremos como recurso para essas atividades em um cluster cassandra, o Cassandra Query Language (CQL), que faz analogia ao SQL das bases de dados relacionais.
O CQL fornece uma API simples para o Cassandra, que tem como função disponibilizar uma camada de abstração para ocultar os detalhes de implementação da estrutura de armazenamento interno, fornecendo sintaxes nativas e outras coleções para codificações comuns, a exemplo de criar keyspaces, criar columns, inserir, consultar, atualizar e imprimir registros. (Clique aqui para saber mais)
Dando continuidade ao projeto de conexão iremos incluir um atributo session na classe conexão. Esse atributo será responsável por executar as rotinas CQL.
Ao final do método connect insira a atribuição do closter connection a session, como na figura abaixo.
Após isso, é a vez de criar a classe que gerenciará o keypace Nessa classe será criado um atributo final chamado node, ele representará o nó onde está localizado o cluster, um atributo do tipo conexão e dois métodos um costrutor, que irá instanciar o atributo conexão, e um método chamado criar keyspace que como o nome já diz, irá criar o keyspace e a column family, como segue abaixo.
Para testarmos o código utilizaremos a classe principal e alteraremos o código da classe main. Seu código e sua saída esta exibida abaixo.
Utilizaremos como recurso para essas atividades em um cluster cassandra, o Cassandra Query Language (CQL), que faz analogia ao SQL das bases de dados relacionais.
O CQL fornece uma API simples para o Cassandra, que tem como função disponibilizar uma camada de abstração para ocultar os detalhes de implementação da estrutura de armazenamento interno, fornecendo sintaxes nativas e outras coleções para codificações comuns, a exemplo de criar keyspaces, criar columns, inserir, consultar, atualizar e imprimir registros. (Clique aqui para saber mais)
Dando continuidade ao projeto de conexão iremos incluir um atributo session na classe conexão. Esse atributo será responsável por executar as rotinas CQL.
Ao final do método connect insira a atribuição do closter connection a session, como na figura abaixo.
 |
| Classe conexão |
Após isso, é a vez de criar a classe que gerenciará o keypace Nessa classe será criado um atributo final chamado node, ele representará o nó onde está localizado o cluster, um atributo do tipo conexão e dois métodos um costrutor, que irá instanciar o atributo conexão, e um método chamado criar keyspace que como o nome já diz, irá criar o keyspace e a column family, como segue abaixo.
 |
| Classe BlogDB |
Para testarmos o código utilizaremos a classe principal e alteraremos o código da classe main. Seu código e sua saída esta exibida abaixo.
 |
| Código da classe principal pós alteração |
 |
| Resultado da execução |
O projeto apresentado pode ser encontrado aqui.
Referência:
Datastax, disponível em <http://www.datastax.com/documentation/developer/java-driver/1.0/java-driver/quick_start/qsSimpleClientAddSession_t.html>, Acessado em 09 de janeiro de 2015;
Planeta Cassandra, disponível em <https://cassandra.apache.org/doc/cql/CQL.html>, Acesso em 09 de janeiro de 2015.
Redis - Quem está usando? (Parte 1)
Em diversos posts anteriores foram apresentados o banco de dados NoSQL Redis e também algumas de suas características e curiosidades.
Este post traz agora como curiosidade uma pequena lista de empresas bastante conhecidas por estudantes, profissionais, entusiastas e também por usuários finais de computadores que usam, direta o indiretamente, uma base de dados provida pelo Redis.
1 - Twitter
 |
| Fonte: Captura de tela de http://www.infoq.com/presentations/Real-Time-Delivery-Twitter |
O site ilustrado na figura acima tem uma apresentação sobre a arquitetura de entrega de mensagens em tempo real do Twitter, numa parte específica do vídeo, como pode ser visualizado na figura acima, o palestrante explica como o Twitter trabalha com o redis.
2 - GitHub
 |
| Fonte: http://www.fastly.com/img/customers/casestudy/github_logo.png |
Na seguinte página intitulada "Como nós fizemos o GitHub rápido", o autor mostra, dentre outras diversas especificidades, que usa o redis como um banco persistente chave/valor para tratar de diversos tipos de dados, especifica claramente que o usa para informações de roteamento também.
3 - Snapchat (Aplicativo de chat baseado em fotos e vídeos, os "snaps")
Mais informações acerca do Snapchat podem ser conferidas no site oficial. A figura abaixo mostra um usuário do Snapchat exaltando o uso do Redis para armazenamento.
Referências:
Who's using Redis? Disponível em <http://redis.io/topics/whos-using-redis>. Acesso em 09/01/2014.
Mais informações acerca do Snapchat podem ser conferidas no site oficial. A figura abaixo mostra um usuário do Snapchat exaltando o uso do Redis para armazenamento.
 |
| Fonte: https://twitter.com/robustcloud/status/448503100056535040 |
Who's using Redis? Disponível em <http://redis.io/topics/whos-using-redis>. Acesso em 09/01/2014.
Configurando um mini-clone do Twitter com o Redis
Tradicionalmente a comunidade de programação considera que bases de dados do tipo chave/valor seriam para propósitos específicos e que não poderiam substituir uma base de dados relacional para o desenvolvimento de aplicações WEB.
Esse post ilustra como é possível criar e manter um mini-clone do Twitter, uma aplicação WEB, usando Redis e PHP, o Retwis.
 | |||
| Fonte: Base de testes MVJ-UFS |
O código-fonte do Retwis está disponível para
livre download e distribuição em:
https://code.google.com/p/redis/downloads/list.
Os pré-requisitos para se instalar o aplicativo
numa máquina são:
- Servidor WEB, como o Apache;
- Servidor Redis;
- Código-fonte do Retwis, que contém também uma biblioteca PHP chamada Predis.
 |
| Fonte: Base de testes do MVJ-UFS - Servidor Redis em execução |
O seguinte tutorial foi usado para se instalar a aplicação e rodá-la
localmente, basta apenas instalar e configurar propriamente o Apache,
o servidor redis e então chamar o http://localhost/index.php
(sendo este arquivo o inicial do clone do Twitter).
Para aqueles que não desejam se aventurar em
configurações locais, há uma versão online e operante do Retwis
aqui.
Referências:
Design a Implementation of a Simple Twitter Clone. Disponível em <http://redis.io/topics/twitter-clone>. Acesso em 09/01/2014.
Assinar:
Postagens (Atom)