benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability Ao escolher um banco de dados NoSQL, as opções podem ser esmagadoras. Uma das escolhas mais populares é o MongoDB, conhecido por sua facilidade de uso. Mas o ScyllaDB altamente orientado para o desempenho é um dos desafiadores crescentes. O relatório dá uma olhada técnica mais de perto em ambas as bases de dados – comparando suas arquiteturas de um ângulo técnico independente. Benção Tanto o MongoDB quanto o ScyllaDB prometem uma arquitetura altamente disponível, de alto desempenho e escalável. Mas a forma como alcançam esses objetivos é muito mais diferente do que você poderia pensar à primeira vista. Por exemplo, um relatório de experiência demonstra como o ScyllaDB pode ser facilmente operado em instâncias spot do AWS EC2 graças à sua arquitetura distribuída, enquanto a arquitetura distribuída do MongoDB tornaria isso uma tarefa muito desafiadora. Para destacar essas diferenças, fornecemos uma discussão aprofundada da arquitetura de armazenamento interno e das arquiteturas distribuídas que permitem alta disponibilidade e escalabilidade horizontal. Nós também acabamos de lançar um benchmark quantificando o impacto dessas diferenças. Note: Leia o DynamoDB vs MongoDB Benchmark Resumo Baixe este relatório de comparação Read the DynamoDB vs MongoDB Benchmark Summary Leia o DynamoDB vs MongoDB Benchmark Resumo Download this Comparison Report Baixe este relatório de comparação Um ponto de vista de desempenho sobre a arquitetura de armazenamento do MongoDB versus ScyllaDB Ambas as bases de dados são implementadas em C++ e recomendam o uso do sistema de arquivos XFS. , Commit Log na terminologia ScyllaDB e Oplog na terminologia MongoDB. Com write-ahead-logging, todas as operações são escritas em uma tabela de log antes que a operação seja executada. O write-ahead-log serve como uma fonte para replicar os dados para outros nós, e é usado para restaurar dados em caso de falhas porque é possível 'replay' as operações para restaurar os dados. Conceito de escrita antecipada O MongoDB usa como mecanismo de armazenamento padrão um índice B+-Tree (Wired Tiger) para armazenamento e recuperação de dados. Os índices B+-Tree são estruturas de dados de árvore equilibrada que armazenam dados em ordem ordenada, facilitando a realização de consultas baseadas em faixas. O MongoDB suporta múltiplos índices em uma coleção, incluindo índices compostos, índices de texto e índices geoespaciais. Também é possível indexar elementos de matriz e campos aninhados, permitindo consultas eficientes sobre estruturas de dados complexas. O ScyllaDB divide os dados em fragmentos ao atribuir um fragmento dos dados totais em um nó a uma CPU específica, juntamente com a sua memória associada (RAM) e armazenamento persistente (como o NVMe SSD). O motor de armazenamento interno do ScyllaDB segue o conceito de registro de antecedência de escrita, aplicando um log de comissão persistente de disco juntamente com memes baseados em memória que são lavados no disco ao longo do tempo. O ScyllaDB suporta índices primários, secundários e compostos, tanto locais por nó como globais por cluster. O índice primário consiste em um anel de hash onde a chave hash e a partição correspondente são armazenadas. E dentro da partição, o ScyllaDB encontra a linha em uma estrutura de dados classificada (SSTable Essas diferentes arquiteturas de armazenamento resultam em um uso diferente do hardware disponível para lidar com a carga de trabalho.O MongoDB não aponta fios internos para os núcleos de CPU disponíveis, mas aplica uma abordagem desconectada para os fios distribuídos para os núcleos. Arquiteturas de CPU, isso pode causar uma degradação de desempenho, especialmente para grandes servidores porque os fios podem ser dinamicamente atribuídos a núcleos em diferentes sockets com diferentes nós de memória. Isso permite que ele aponte os fios responsáveis para núcleos específicos e evite alternar entre diferentes núcleos e espaços de memória. Consequentemente, a chave de fenda precisa ser cuidadosamente selecionada para garantir uma distribuição igual de dados entre as fendas e para evitar fendas quentes. que fornece classes de prioridade embutidas para consultas sensíveis à latência e insensíveis, bem como o agendamento I/O coordenado entre os fragmentos em um nó para maximizar o desempenho do disco. Finalmente, os scripts de instalação do ScyllaDB vêm com um passo de ajuste automático de desempenho, aplicando a configuração de banco de dados ideal com base nos recursos disponíveis. Numa base Shard por abordagem central Calendário I/O O ScyllaDB permite que o usuário controle se os dados devem residir no cache do DB ou contorná-lo para partições raramente acessadas. O ScyllaDB permite que o cliente aceda ao nodo e ao núcleo de CPU (shard) que possuem os dados. Isso fornece uma latência mais baixa, desempenho consistente e equilíbrio de carga perfeito. O ScyllaDB também fornece “priorização de carga de trabalho” que fornece ao usuário diferentes SLAs para diferentes cargas de trabalho para garantir uma latência mais baixa para certas cargas de trabalho cruciais. A arquitetura distribuída do MongoDB – dois modos de operação para alta disponibilidade e escalabilidade A arquitetura de banco de dados MongoDB oferece dois modos de aglomerado que são descritos nas seções seguintes: um aglomerado de conjuntos de réplicas visa alta disponibilidade, enquanto um aglomerado fragmentado visa escalabilidade horizontal e alta disponibilidade. Replica Set Cluster: Alta disponibilidade com escalabilidade limitada A arquitetura MongoDB permite a alta disponibilidade pelo conceito de conjuntos de réplica. Os conjuntos de réplica MongoDB seguem o conceito de nós primários-secundários, onde apenas o principal lida com as operações WRITE. Os secundários mantêm uma cópia dos dados e podem ser habilitados para lidar apenas com as operações READ. Uma implantação comum de conjuntos de réplica consiste em dois secundários, mas podem ser adicionados secundários adicionais para aumentar a disponibilidade ou escalar cargas de trabalho pesadas de leitura. O MongoDB suporta até 50 secundários dentro de um conjunto de réplica. Os secundários serão escolhidos como primários em caso de falha no anterior primário. No que diz respeito à geo-distribuição, o MongoDB suporta implantações geo-distribuídas para conjuntos de réplicas para garantir alta disponibilidade em caso de falha de data center. Neste contexto, as instâncias secundárias podem ser distribuídas em múltiplos data centers, como mostrado na figura a seguir. Cluster Sharded: Escalabilidade horizontal e alta disponibilidade com complexidade operacional O MongoDB suporta a escalação horizontal através do sharding de dados em várias instâncias primárias para lidar com cargas de trabalho intensivas de escrita e tamanhos de dados crescentes. Em um aglomerado fragmentado, cada conjunto de réplica composto por um primário e múltiplos secundários representa um shard. Para habilitar o sharding, são necessários tipos de nó MongoDB adicionais: Uma instância de mongos atua como um roteador de consulta, fornecendo uma interface entre os aplicativos do cliente e o cluster fragmentado. Consequentemente, os clientes nunca se comunicam diretamente com os fragmentos, mas sempre através do roteador de consulta. Os roteadores de consulta são componentes sem estado e leves que podem ser operados em recursos dedicados ou juntamente com os aplicativos do cliente. roteadores de consulta (mongos) Recomenda-se implantar múltiplos roteadores de consulta para garantir a acessibilidade do cluster, porque os roteadores de consulta são a interface direta para os drivers do cliente. Não há limite ao número de roteadores de consulta, mas como eles se comunicam frequentemente com os servidores de configuração, deve-se notar que muitos roteadores de consulta podem sobrecarregar os servidores de configuração. Os servidores de configuração armazenam os metadados de um cluster fragmentado, incluindo o estado e a organização de todos os dados e componentes. Os metadados incluem a lista de pedaços em cada pedaço e as faixas que definem os pedaços. O sharding de dados no MongoDB é feito no nível da coleção, e uma coleção pode ser shardada com base em uma chave de shard. O MongoDB usa uma chave de shard para determinar quais documentos pertencem a qual shard. Escolhas comuns de chave de shard incluem o campo _id e um campo com uma alta cardinalidade, como um timestamp ou ID do usuário. O MongoDB suporta três estratégias de sharding: baseado em faixa, baseado em hash e baseado em zona. As partições de divisão classificadas distribuem documentos entre as partições de acordo com o valor da chave de divisão. Isso mantém documentos com valores de chave de divisão próximos uns dos outros e funciona bem para consultas baseadas em faixa, por exemplo, em dados de série de tempo. A divisão hash garante uma distribuição uniforme de escritos entre as partições, o que favorece as cargas de trabalho de escrita. A divisão de zona permite que os desenvolvedores definam regras de divisão personalizadas, por exemplo, para garantir que os dados mais relevantes residam em partições que estão geograficamente mais próximas dos servidores de aplicativos. Além disso, aglomerados fragmentados podem ser implantados em uma configuração geo-distribuída para superar falhas de data center, como descrito na figura a seguir. A arquitetura ScyllaDB – Multi-Primary para alta disponibilidade e escalabilidade horizontal Ao contrário do MongoDB, o ScyllaDB não segue as arquiteturas RDBMS clássicas com um nó primário e vários nós secundários, mas usa uma estrutura descentralizada, onde todos os dados são sistematicamente distribuídos e replicados em vários nós formando um cluster. Um cluster é uma coleção de nós interconectados organizados em uma arquitetura de anel virtual, através da qual os dados são distribuídos. O anel é dividido em vNodes, que representam uma gama de tokens atribuídos a um nó físico, e são replicados entre nós físicos de acordo com o fator de replicação definido para o espaço chave. Todos os nós são considerados iguais, em um sentido multi-primário. Sem um líder definido, o cluster não tem um único ponto de falha. Os nós podem ser servidores individuais on-premises, ou servidores virtuais (instâncias de nuvem pública) compostos por um subconjunto de hardware em um servidor físico maior. Em cada nó, os dados são ainda mais divididos em partições. As partições operam como unidades de operação mais independentes, conhecidas como um Todos os nódulos se comunicam uns com os outros através do Este protocolo decide em qual partição quais dados são escritos e procura os registros de dados na partição direita usando os índices. Protocolo de Goiás Quando se trata de escalar, a arquitetura do ScyllaDB é projetada para facilitar o sharding horizontal em vários servidores e regiões. O sharding no ScyllaDB é feito no nível da tabela, e uma tabela pode ser shardada com base em uma chave de partição. A chave de partição pode ser uma única coluna ou um composto de várias colunas. O ScyllaDB também suporta o sharding baseado em faixa, onde as linhas são distribuídas em faixas com base na faixa de valor da chave de partição, bem como o sharding baseado em hash para distribuir dados de forma uniforme e evitar pontos quentes. Além disso, o ScyllaDB permite que os dados sejam replicados em vários data centers para maior disponibilidade e latências mais baixas.Nesta configuração multi-data center ou multi-região, os dados entre data centers são replicados de forma assíncrona. Do lado do cliente, os aplicativos podem ou não estar cientes da implantação de múltiplos datacenters, e cabe ao desenvolvedor de aplicativos decidir sobre a conscientização de fallback data-center(s). Isto pode ser configurado através das opções de consistência de leitura e escrita que definem se as consultas são executadas contra um único data center ou em todos os datacenters. Um ponto de vista comparativo de escalabilidade sobre as arquiteturas distribuídas de MongoDB e ScyllaDB Quando se trata de escalabilidade, as abordagens de distribuição significativamente diferentes de ScyllaDB e MongoDB precisam ser consideradas, especialmente para aglomerados auto-geridos em execução on-premises ou em IaaS. A arquitetura do MongoDB permite facilmente escalar cargas de trabalho pesadas de leitura, aumentando o número de secundários em um conjunto de réplica. No entanto, para escalar cargas de trabalho com uma proporção de escrita notável, os conjuntos de réplica precisam ser transformados em um conjunto de réplica fragmentada e isso vem com vários desafios. Primeiro, são necessários dois serviços MongoDB adicionais: n roteadores de consulta (mongos) e um conjunto de réplica de servidores de configuração para garantir alta disponibilidade. Consequentemente, são necessários recursos consideravelmente maiores para permitir o sharding em primeiro lugar. Além disso, a complexidade operacional aumenta claramente. Por exemplo, um cluster fragmentado com três shards requer um conjunto de réplica de três instâncias de mongos, um conjunto de réplica de três servidores de configuração e três shards – cada shard consistindo de um primário e pelo menos dois secundários. O segundo desafio é a repartição de dados no aglomerado fragmentado. Aqui, o MongoDB aplica uma tarefa de fundo em execução constante que desencadeia automaticamente a redistribuição de dados entre os aglomerados. A repartição não ocorre assim que um novo aglomerado é adicionado ao aglomerado, mas quando certos limiares internos são atingidos. Consequentemente, aumentar o número de aglomerados irá imediatamente escalar o aglomerado, mas pode ter um efeito de escalagem retardado. Até a versão 5.0 do MongoDB, os próprios engenheiros do MongoDB recomendam não escalar, mas escalar verticalmente com máquinas maiores, se possível. Escalar um cluster ScyllaDB é comparativamente fácil e transparente para o usuário graças à arquitetura multi-primária do ScyllaDB. Aqui, cada nó é igual e não são necessários serviços adicionais para escalar o cluster para centenas de nós. Além disso, a repartição de dados é desencadeada assim que um novo nó é adicionado ao cluster. Neste contexto, o ScyllaDB oferece vantagens claras sobre o MongoDB. Em primeiro lugar, graças à abordagem de hashing consistente, os dados não precisam ser repartidos em todo o cluster, apenas em um subconjunto de nós. Em segundo lugar, a partição começa com a adição do novo nó, o que facilita o timing da ação de escala. Isto é importante, uma vez que a repartição coloca alguma carga adicional no cluster e deve As principais diferenças de escalabilidade são resumidas na seguinte tabela: Conclusão e Outlook Quando se comparam duas distribuições em bases de dados, você sempre descobre alguns paralelos, mas também inúmeras diferenças consideráveis. . Ambos os bancos de dados abordam casos de uso semelhantes e têm uma estratégia de produto e comunidade semelhante. Mas quando se trata do lado técnico, você pode ver as diferentes abordagens e foco. Ambos os bancos de dados são construídos para permitir alta disponibilidade através de uma arquitetura distribuída. Mas quando se trata de cargas de trabalho alvo, o MongoDB permite começar facilmente com implementações de nódulo único ou conjunto de réplica que se encaixam bem para cargas de trabalho pequenas e médias, enquanto abordar cargas de trabalho grandes e conjuntos de dados se torna um desafio devido à arquitetura técnica. NoSQL ScyllaDB versus MongoDB O ScyllaDB aborda claramente cargas de trabalho críticas ao desempenho que exigem fácil e alta escalabilidade, alta capacidade de transmissão, latência baixa e estável e tudo em uma implantação de datacenters múltiplos. E para fornecer mais insights sobre suas respectivas capacidades de desempenho, fornecemos uma comparação de desempenho transparente e reproduzível em um relatório de referência separado que investiga o desempenho, a escalabilidade e os custos para o MongoDB Atlas e a ScyllaDB Cloud. Adicional ScyllaDB vs. MongoDB comparação Detalhes Veja o completo para uma versão estendida desta comparação técnica, incluindo detalhes de comparação: Comparação BenchANT MongoDB vs ScyllaDB Modelo de Dados Queria língua Casos de uso e exemplos de clientes Opções de consistência de dados Experiência operacional em primeira mão
