Você deve ter ouvido falar que o MongoDB tem problemas de dimensionamento fora. Você deve ter ouvido falar que o Viber está substituindo o MongoDB pelo Couchbase Server. Você já ouviu falar sobre como escalar com o MongoHQ?
Concordo com o MongoHQ em um aspecto. É mais fácil escalonar para cima. Enquanto o escalonamento para cima pode ser a única solução para o MongoDB, mas não é a solução certa. O que acontece quando não há mais espaço para escalonar? para cima? Acho que o MongoHQ preferiria escalonar, mas eles perceberam que o MongoDB não foi projetado para isso.
Isso resulta em uma perda de funcionalidade...
No MongoDB, por exemplo, escalas horizontais significam perder índices secundários exclusivos (uma das poucas restrições de esquema que o MongoDB suporta atualmente) para uma determinada coleção.
Isso requer decisões difíceis...
No MongoDB, essa escolha é a "decisão de chave de fragmento", sobre a qual você ouvirá usuários experientes do MongoDB falarem com tons de pavor.
É complexo de configurar e manter...
Porém, depois de colocar seu banco de dados fragmentado em produção, há a realidade subjacente de que seu sistema tem mais "partes móveis" do que seria ideal, pois mais partes móveis significam mais coisas que podem dar errado.
Isso resulta em uma perda de desempenho...
Em uma configuração fragmentada, a conectividade de rede entre o roteador Mongo, os servidores de configuração e cada fragmento influencia o desempenho geral.
O Couchbase Server, por outro lado, foi projetado para ser ampliado. Isso não resulta em perda de funcionalidade. Não exige decisões difíceis. Não é complexo de configurar e manter. Não resulta em perda de desempenho.
- O Couchbase Server não requer configuração manual de sharding. Ela é automática.
- O Couchbase Server não tem muitas partes móveis. Há um tipo de nó.
- Quando o Couchbase Server é dimensionado, o desempenho aumenta.
Acho que a seção sobre o preenchimento de logs foi bastante problemática. Acho que ela destaca o fato de que o MongoDB não foi projetado para ser ampliado. Acontece que os administradores e desenvolvedores dependem de um arquivo de registro para obter informações e integração. O problema com o escalonamento do MongoDB é que ele exige que os desenvolvedores adaptem vários arquivos de registro. Há um arquivo de log por nó.
O Couchbase Server, por outro lado, não exige que os administradores e desenvolvedores sigam um arquivo de registro para obter informações e integração. Os administradores podem monitorar o Couchbase Server de qualquer nó. Os desenvolvedores podem se integrar ao Elasticsearch ou ao Apache Hadoop sem precisar interagir com nós individuais do Couchbase Server. A topologia é transparente. Esse é o benefício de um sistema distribuído com uma arquitetura de nada compartilhada.
Vale a pena ressaltar que o Couchbase Server oferece suporte à replicação entre centros de dados. Ele permite que os dados em um cluster sejam replicados em um cluster diferente. De fato, é assim que nos integramos ao Elasticsearch. É como um cluster diferente que o Couchbase Server pode replicar os dados. O fato de ser um cluster do Elasticsearch é irrelevante. Ele é simplesmente um cluster diferente para o qual replicar dados.
Participe da conversa no reddit (link).
Participe da conversa no Hacker News (link).
Leitura adicional
Por que começamos a escalonar verticalmente (Google Web Cache)
Observação: O MongoHQ removeu a postagem original e agora está redirecionando para uma nova postagem.
Topologia: A arquitetura dos sistemas distribuídos
Observação: Isso inclui uma visão geral do partes móveis em uma implantação do MongoDB que é dimensionada para fora.
Integração do Couchbase Server com o Elasticsearch (página | doc)
Integração do Couchbase Server com o Apache Hadoop (página | doc)
Então o couchbase é melhor?
Eu não diria que um é melhor ou pior. Isso realmente depende de sua necessidade. Se você pesquisar bastante, verá que todos os fornecedores de NoSQL terão uma história de várias migrações de um armazenamento de dados em potencial para outro (incluindo o Riak). Apenas dois centavos...
(funcionário da Basho totalmente revelado)
No entanto, esse é um ótimo tópico, que deve ser ampliado. Algumas reflexões:
No entanto, à medida que o Couchbase adiciona nós, como os desempenhos de várias cargas de trabalho são dimensionados (ou seja, a taxa de gravação/leitura), uma vez que as réplicas do vBuckets não são participantes iguais, há duas estratégias de replicação: 1:n mestre/escravo e 1..n encadeado.
Em \"grande escala\", as falhas ocorrem mais (ou seja, interrupções de tempo do nó, cérebro dividido, falhas parciais), como o sistema lida com as falhas e qual é a quantidade de intervenção humana necessária?
Este comentário não tem a intenção de provocar e colocar o Riak em uma posição favorável, pois ele faz essas coisas \"melhor\" ......., mas de pedir a quem estiver lendo que pense e faça perguntas ao ler qualquer material. O Riak tem seu próprio conjunto de limitações, como consultas de campo JSON, etc., e o Couchbase é fantástico para quem usa a API Memcache.
No final das contas, a tecnologia é apenas uma ferramenta e deve ser avaliada de acordo com o uso/caso. Espero que isso ajude a raluca. Abraços :)
Olá, Frank,
Nunca tive nada de ruim a dizer sobre o Riak, e ainda não tenho. Dito isso, não tenho certeza se entendi seu comentário. À medida que os nós são adicionados, os vBuckets são distribuídos uniformemente pelo cluster. A adição de nós aumenta o desempenho, pois cada nó lida com leituras e gravações de menos vBuckets. Há apenas uma estratégia de replicação. Ela grava em todas as réplicas (um para muitos). Ela não encadeia as gravações nas réplicas.
Sim, mas você não precisa acreditar em minha palavra. Acho que os problemas de desempenho do MongoDB são bem conhecidos.
Não é preciso ir muito longe para encontrar pessoas na comunidade do MongoDB dizendo que você não precisa de sharding. Quando alguém lhe diz que você não precisa de algo, é porque não consegue fazer isso. O primeiro exemplo que me vem à mente é o iPhone com copiar e colar ;)
Bem, parece um anúncio publicitário...
É difícil comparar o Couchbase com o MongoDB.
Enquanto o MongoDB é um NoSQL de uso geral, o Couchbase foi projetado para armazenamento em cache: a maior parte do conjunto de dados precisa estar na memória, sem consultas complexas, etc.
Além disso, o hashing do Couchbase significa menor disponibilidade, pois a queda de um nó significa que todo o conjunto de dados é afetado.
1. O Couchbase Server não foi projetado para armazenamento em cache. Ele pode ser implantado como um cache, como um armazenamento de chave/valor, como um banco de dados de documentos ou como todos os três. Esse é o benefício de uma arquitetura excelente, e é algo que você precisa acertar no início. É por isso que o MongoDB tem os problemas que tem.
2. O hashing não tem nada a ver com disponibilidade. Não, um nó com falha não afeta todo o conjunto de dados. Você pode configurar réplicas. Se um nó falhar, uma das réplicas pode ser \'promovida\'. Não há perda de disponibilidade. Mesmo que não haja réplicas, um nó com falha resulta apenas na perda dos dados desse nó.
1. Quando a maior parte do conjunto de dados precisa estar na memória para que o Couchbase funcione, ele é otimizado para armazenamento em cache.
2. Não tenho como controlar onde os dados residem devido ao hashing consistente no Couchbase (ao contrário do MongoDB, onde posso usar o particionamento de intervalo). Portanto, um nó inoperante pode causar a falha de muitas solicitações (até que o failover seja concluído após um período de 30 segundos), pois os documentos serão distribuídos entre os nós. A inclusão de algo de hashing adicional permitirá resolver esse problema.
1. Por que você continua dizendo que a maior parte dos dados precisa estar na memória? O MongoDB não usa arquivos mapeados na memória? Um \"cache\" implica que os dados são transitórios ou são persistidos em um banco de dados separado. Quando o Couchbase Server é usado como um armazenamento de chave/valor ou como um banco de dados de documentos, isso não é verdade.
2. O problema com o particionamento de intervalo é que ele limita o desempenho até que o banco de dados esteja cheio. É por isso que a maioria dos bancos de dados (NoSQL) depende de hashing consistente.
3. O Couchbase Server é um sistema distribuído de CP. Ele mantém a consistência. Sim, ele aguardará 30 segundos antes de dar falha em um nó. Isso é para garantir que o nó em questão esteja inativo, e não lento. Se ele estiver lento, os dados que ele possui poderão ou não estar disponíveis. Você não quer fazer o failover de todos os nós sempre que eles demorarem muito para responder a uma solicitação. Isso seria instável. Embora os dados pertencentes a um nó questionável possam ou não estar disponíveis por 30 segundos, os dados pertencentes aos outros nós estão disponíveis.