Esta não é a primeira vez que falo sobre FUD (link). No entanto, é a primeira vez que abordo o FUD direcionado ao Couchbase e isso é ótimo. Afinal de contas, eu sei o que acontecerá em seguida.
Primeiro eles o ignoram, depois riem de você, depois brigam com você, e então você vence. - Gandhi
Acredito que a melhor maneira de lidar com o FUD é abordá-lo. Hoje, estou abordando uma postagem no blog da DataStax (link).
Gravações assíncronas
Como o MongoDB por volta de 2013, o Couchbase realiza gravações assíncronas por padrão.
Isso não é verdade. Sim, o MongoDB executava gravações assíncronas por padrão. Ele não respondia às solicitações de gravação (link). No entanto, esse não é mais o caso com o MongoDB 2.6 (link). O Couchbase Server não realiza gravações assíncronas. Ele responde a solicitações de gravação.
Persistência e desempenho
O Couchbase pode ser forçado a manter as gravações no disco, mas isso prejudica o desempenho; como não há commitlog ou registro em diário, cada gravação deve atualizar o btree e o fsync do Couchbase.
Isso é enganoso. Sim, o Couchbase Server grava primeiro na memória. Em seguida, ele sincroniza os dados na memória com o dispositivo de armazenamento. No entanto, o mesmo acontece com o DataStax Enterprise (Apache Cassandra). Por padrão, ele não faz fsync depois de gravar no registro de confirmação. Portanto, ele grava primeiro na memória. Ele grava no cache de página por meio do sistema operacional. Se o DataStax Enterprise estiver configurado para fazer fsync depois de gravar no registro de confirmação, ele mata o desempenho.
Baldes e documentos
O mecanismo de armazenamento do Couchbase tem problemas para lidar com mais de cinco compartimentos (análogos às tabelas relacionais).
Isso não é verdade. Um bucket é análogo a um banco de dados. Não há esquema. Não há tabelas. Essa é uma das vantagens de um banco de dados de documentos.
Consistência e disponibilidade
O Couchbase não consegue ser totalmente consistente nem totalmente disponível: ele não pode servir leituras durante failover ou partições de rede, mas ainda pode servir dados obsoletos para leituras.
Isso não é verdade e não faz sentido. Ele não pode servir leituras, mas ainda pode servir dados para leituras?
O Couchbase Server mantém uma forte consistência. Por padrão, o failover automático está desativado. Se um nó não estiver disponível ou não responder, seus dados não estarão disponíveis. O Couchbase Server é CP. No entanto, o Couchbase Server pode ser configurado para AP.
A DataStax é uma empresa totalmente consistente? Você pode encontrar a resposta aqui.
FUD dissipado.
Recomendações
A DataStax publicou uma postagem no blog sobre como não fazer benchmark do Apache Cassandra (link). É um ótimo começo.
Não execute benchmarks de bancos de dados distribuídos com máquinas virtuais, armazenamento compartilhado, unidades mal configuradas, carga inadequada e com pequenos conjuntos de dados.
Eu concordo. No entanto, a lista está incompleta.
1. Não execute benchmarks de bancos de dados distribuídos com um único nó.
Um banco de dados distribuído precisa fazer concessões entre consistência e disponibilidade (link), e essas compensações afetam o desempenho. Se um benchmark é realizado com um único nó, ele ignora essas compensações e oculta o impacto no desempenho. Os resultados de desempenho não são realistas e, portanto, são inúteis.
2. Não execute benchmarks de bancos de dados distribuídos com configurações diferentes.
Por exemplo, não configure o Couchbase Server para fazer fsync a cada gravação enquanto configura o DataStax Enterprise para fazer fsync a cada dez (10) segundos (link e link). Os resultados de desempenho são tendenciosos e, portanto, inválidos. Parece que o DataStax definiu commitlog_sync como batch. Isso é justo. No entanto, a DataStax não mapeou a latência. Se o commitlog_sync estiver definido como batch, o Apache Cassandra aguardará 50 ms antes de concluir uma operação de gravação.
Bem, por hoje é só.
