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.
Assinar:
Postagens (Atom)