A chave para o sucesso das iniciativas de Big Data é poder gerenciar a velocidade, a escala e a estrutura em uma velocidade inferior a um milissegundo.
Big Data é um termo grande. Ele engloba conceitos sobre tipos de dados, dezenas de tecnologias diferentes para gerenciar esses tipos de dados e o ecossistema em torno de todas essas tecnologias. E tudo nele se move rapidamente!
O Big Data está evoluindo rapidamente. Um clássico solução de big dataA arquitetura de tecnologia de Big Data mais comum em uso atualmente depende da importação e exportação de dados (normalmente para o Hadoop) por meio de processos em lote. Embora isso tenha gerado enormes resultados comerciais na forma de melhor percepção do cliente e análise preditiva, não é uma solução em tempo real. Ela é lenta.
À medida que a tecnologia avança em um ritmo cada vez maior, o mesmo acontece com as práticas recomendadas para soluções de Big Data: uma solução moderna de Big Data depende do processamento de dados em tempo real por meio do processamento de fluxo. Uma solução moderna de big data aproveita a integração com Elasticsearch, Storm e outros. Ela permite a análise e a pesquisa em tempo real e, ao mesmo tempo, atende aos requisitos operacionais. Para permitir a análise e a busca em tempo real, uma solução moderna de big data requer um sistema de alto desempenho Banco de dados NoSQL que seja dimensionável. O banco de dados NoSQL deve atender aos requisitos operacionais e, ao mesmo tempo, aos requisitos de desempenho necessários para permitir a análise e a pesquisa em tempo real.
Uma solução moderna de Big Data é tão rápida quanto seu componente mais lento. Isso nos leva a um anúncio recente da Mongo e da Cloudera. Embora aplaudamos todos os esforços para ajudar os clientes a entenderem as práticas recomendadas para a arquitetura de Big Data, também precisamos abordar qual solução NoSQL é a peça certa para viabilizar uma arquitetura de Big Data realmente rápida. Um banco de dados NoSQL escalável e de alto desempenho garante que o banco de dados operacional não será o componente mais lento. Um banco de dados NoSQL que seja difícil de dimensionar e que imponha bloqueios pesados em seu tráfego de leitura e gravação não conseguirá aproveitar o potencial de uma solução moderna de Big Data. Essa é a diferença entre o MongoDB e o Couchbase Server. Claro, o MongoDB pode fazer parte de soluções clássicas de Big Data: elas não foram projetadas para análise em tempo real e não precisam da velocidade que uma solução moderna de Big Data exige. O Couchbase Server pode fazer parte tanto de soluções clássicas de Big Data quanto de soluções modernas de Big Data.
Uma solução clássica de Big Data, que mencionamos anteriormente, está em uso em muitas organizações atualmente. Normalmente, ela depende da integração com o Hadoop. O Couchbase Server se integra ao Hadoop por meio de um conector Sqoop certificado pela Cloudera (link).
Matt Asay citou um caso clássico de uso de big data em que o Hadoop analisa a multidão e um banco de dados NoSQL interage com os indivíduos. As interações individuais são enviadas para o Hadoop e a análise da multidão é enviada para o banco de dados NoSQL. Para o Couchbase, esse não é apenas um caso de uso. É uma referência para o cliente. A AOL utiliza o Hadoop e o Couchbase Server em uma solução clássica de big data para permitir a publicidade inteligente (link).
O LivePerson utiliza o Hadoop, o Storm e o Couchbase Server em sua moderna solução de Big Data. A arquitetura do LivePerson aproveita tanto o processamento orientado por lote quanto o processamento em tempo real. A LivePerson considerou os bancos de dados NoSQL do Couchbase, MongoDB e DataStax. No entanto, apenas o Couchbase Server foi capaz de atender aos seus requisitos de alta taxa de transferência.
Mais informações
O Big Data Central é um local para a comunidade de big data explorar casos de uso, tecnologias e arquiteturas. Descubra como os clientes do Couchbase, como LivePerson, AOL e PayPal, estão aproveitando o NoSQL e o Hadoop em soluções de Big Data, clássicas e modernas.
Li esta postagem esperando ver algum tipo de análise inteligente. Em vez disso, o que vejo é propaganda de marketing e insinuações.
Talvez você deva falar sobre os índices que estão sendo criados por trabalhos de redução de mapas que retornam dados obsoletos após as atualizações até que o trabalho em lote seja executado. Ou que tal um mecanismo de armazenamento somente de acréscimo? É mesmo? Atualizações de alto volume em documentos grandes esmagam o Couchbase.
Se você quiser ver um colapso do servidor, basta começar a martelar um servidor Couchbase com atualizações. Então, você poderá aproveitar o fato de que todas as suas leituras agora são inconsistentes com a realidade e o armazenamento do servidor fica quente o suficiente para fritar ovos.
Oi Rick,
Obrigado por reservar um tempo para comentar. Tentarei abordar suas preocupações.
Débito técnico:
Essa é uma peça de alto nível, mas ressalta a importância da escalabilidade e do desempenho. É por isso que demonstramos nossa capacidade de dimensionamento e desempenho com benchmarks. A propósito, sei que o MongoDB estabeleceu a base para futuras melhorias de desempenho com sua última versão. Tenho grandes expectativas para a próxima versão.
Índices secundários (visualizações) e consistência:
Por padrão, as exibições são incrementais e, portanto, eventualmente consistentes. No entanto, os clientes podem usar o sinalizador stale (stale=false) para garantir que sejam consistentes. Acredito que o MongoDB imponha a consistência dos dados de maneira semelhante por meio de preocupações de gravação. Ele é eventualmente consistente por padrão (reconhecido), mas \"majority\" é uma alternativa.
Arquivos somente de anexo:
Sim, usamos arquivos append-only. Acho que é seguro dizer que os bancos de dados modernos estão se afastando da atualização no local. Isso inclui bancos de dados somente leitura, bancos de dados colunares e Google Dremel / Cloudera Impala + Parquet. Estes são alguns dos motivos.
Desempenho consistente. Ele é previsível, enquanto o update-in-place não é.
Resiliência à corrupção. A capacidade de restaurar para uma versão anterior.
Unidades de estado sólido. Elas são \"read-modify-write\". Não são atualizados no local.
Baixa fragmentação. Não é um problema quando o tamanho da atualização é maior que o tamanho original.
Atualizações:
Não sei por que você acha que as atualizações são um problema. Com um arquivo somente de anexo, uma gravação é uma gravação. Eu o incentivaria a dar uma olhada nos benchmarks. Se você tiver conhecimento de algum benchmark endossado pelo MongoBD, seria ótimo se pudesse compartilhá-lo. Eu gostaria muito de dar uma olhada.
Referências
http://www.couchbase.com/sites…
MongoDB e preocupações com gravação
http://aphyr.com/posts/284-cal…
Atualização no local versus somente anexação
http://blogs.justonedatabase.c…
Todas as plataformas NoSQL têm um longo caminho a percorrer. Algumas estão mais avançadas do que outras e um banco de dados é mais do que o desempenho bruto. As plataformas relacionais tradicionais são preferidas para a maioria dos aplicativos de negócios devido à profundidade da funcionalidade que oferecem, tanto quanto ao desempenho.
É na área de profundidade funcional que estamos começando a ver a separação no mercado entre as plataformas NoSQL, à medida que a maioria dos participantes iniciais começa a fazer suas apostas.
Tenho certeza de que o Couchbase evoluirá como plataforma, assim como o MongoDB. Meu comentário inicial tinha a intenção de apontar que o link para a postagem do blog sugeria, no mínimo, um artigo de opinião muito bem informado, mas o conteúdo ficou muito aquém do esperado. Seu comentário posterior provavelmente estava mais alinhado com o que eu esperava ler em primeiro lugar, mas links para postagens de blog antigas que provavelmente não são tão relevantes quanto eram quando foram escritas é uma substituição bastante interessante.