benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability Al elegir una base de datos NoSQL, las opciones pueden ser abrumadoras. Una de las opciones más populares es MongoDB, conocida por su facilidad de uso. El informe toma una mirada técnica más de cerca de ambas bases de datos, comparando sus arquitecturas desde un ángulo técnico independiente. Benchante Tanto MongoDB como ScyllaDB prometen una arquitectura altamente disponible, de alto rendimiento y escalable. Pero la forma en que logran estos objetivos es mucho más diferente de lo que podrías pensar a primera vista. Por ejemplo, un informe de experiencia demuestra cómo ScyllaDB puede operarse fácilmente en instancias spot de AWS EC2 gracias a su arquitectura distribuida, mientras que la arquitectura distribuida de MongoDB haría de esto una tarea muy desafiante. Para resaltar estas diferencias, proporcionamos una discusión en profundidad de la arquitectura de almacenamiento interno y las arquitecturas distribuidas que permiten una alta disponibilidad y escalabilidad horizontal. También acabamos de publicar un índice de referencia cuantificando el impacto de estas diferencias. Note: Comentarios sobre DynamoDB vs MongoDB Benchmark Summary Descarga el informe de comparación Read the DynamoDB vs MongoDB Benchmark Summary Comentarios sobre DynamoDB vs MongoDB Benchmark Summary Download this Comparison Report Descarga el informe de comparación Un punto de vista de rendimiento sobre la arquitectura de almacenamiento de MongoDB vs ScyllaDB Ambas bases de datos se implementan en C++ y recomiendan el uso del sistema de archivos XFS. Además, MongoDB y ScyllaDB se basan en la , Commit Log en la terminología ScyllaDB y Oplog en la terminología MongoDB. Con el registro de antecedentes de escritura, todas las operaciones se escriben en una tabla de registro antes de que se ejecute la operación. El registro de antecedentes de escritura sirve como una fuente para replicar los datos a otros nodos, y se utiliza para restaurar los datos en caso de fallos porque es posible 'replicar' las operaciones para restaurar los datos. Concepto de escritura antecedente MongoDB utiliza como motor de almacenamiento por defecto un índice B+-Tree (Wired Tiger) para almacenar y recuperar datos. Los índices B+-Tree son estructuras de datos de árboles equilibrados que almacenan datos en un orden ordenado, lo que facilita la realización de consultas basadas en el rango. MongoDB admite múltiples índices en una colección, incluyendo índices compuestos, índices de texto y índices geoespaciales. También es posible indexar elementos de array y campos envueltos, permitiendo consultas eficientes sobre estructuras de datos complejas. Además, la versión empresarial de MongoDB admite un motor de almacenamiento en memoria para cargas de trabajo de baja latencia. ScyllaDB divide los datos en fragmentos mediante la asignación de un fragmento de los datos totales en un nodo a una CPU específica, junto con su memoria asociada (RAM) y almacenamiento persistente (como NVMe SSD). El motor de almacenamiento interno de ScyllaDB sigue el concepto de escritura ante-logging aplicando un registro de comisión persistente del disco junto con memtables basados en la memoria que se borran al disco a lo largo del tiempo. ScyllaDB admite índices primarios, secundarios y compuestos, tanto locales por nodo como globales por cluster. El índice primario consiste en un anillo de hashing donde se almacena la clave hashada y la partición correspondiente. Y dentro de la partición, ScyllaDB encuentra la fila en una estructura de datos ordenada (SSTable Estas diferentes arquitecturas de almacenamiento resultan en un uso diferente del hardware disponible para manejar la carga de trabajo. MongoDB no pincha los hilos internos a los núcleos de CPU disponibles, sino que aplica un enfoque desconectado a los hilos distribuidos a los núcleos. En arquitecturas de CPU, esto puede causar una degradación del rendimiento, especialmente para los grandes servidores, ya que los hilos se pueden asignar dinámicamente a los núcleos en diferentes sockets con diferentes nodos de memoria. que le permite pinar los hilos responsables a núcleos específicos y evita cambiar entre diferentes núcleos y espacios de memoria. En consecuencia, la clave de fragmentos debe ser seleccionada cuidadosamente para asegurar una distribución de datos igualitaria entre los fragmentos y para prevenir los fragmentos calientes. que proporciona clases de prioridad integradas para consultas sensibles a la latencia e insensibles, así como la planificación I/O coordinada a través de los fragmentos en un nodo para maximizar el rendimiento del disco. Finalmente, los scripts de instalación de ScyllaDB vienen con un paso de ajuste automático del rendimiento aplicando la configuración de base de datos óptima basada en los recursos disponibles. Número basado Shard por enfoque Calendario I/O ScyllaDB permite al usuario controlar si los datos deben residir en la caché de DB o eludirlo para particiones de acceso raro. ScyllaDB permite al cliente acceder al nodo y el núcleo de CPU (shard) que posee los datos. Esto proporciona una latencia más baja, un rendimiento consistente y un equilibrio de carga perfecto. ScyllaDB también proporciona "priorización de carga de trabajo" que proporciona al usuario diferentes SLAs para diferentes cargas de trabajo para garantizar una latencia más baja para ciertas cargas de trabajo cruciales. La arquitectura distribuida de MongoDB: dos modos de operación para alta disponibilidad y escalabilidad La arquitectura de base de datos MongoDB ofrece dos modos de clúster que se describen en las siguientes secciones: un clúster conjunto de réplica tiene como objetivo una alta disponibilidad, mientras que un clúster fragmentado tiene como objetivo una escalabilidad horizontal y una alta disponibilidad. Cluster de Replica: Alta disponibilidad con escalabilidad limitada La arquitectura MongoDB permite una alta disponibilidad por el concepto de conjuntos de réplica. Los conjuntos de réplica de MongoDB siguen el concepto de nodos primario-secundario, donde sólo el primario maneja las operaciones de WRITE. Los secundarios tienen una copia de los datos y pueden ser habilitados para manejar solo las operaciones de READ. Una implementación de conjunto de réplica común consiste en dos secundarios, pero se pueden añadir secundarios adicionales para aumentar la disponibilidad o escalar cargas de trabajo pesadas de lectura. MongoDB soporta hasta 50 secundarios dentro de un conjunto de réplica. Los secundarios se elegirán como primarios en caso de un fracaso en el anterior primario. En cuanto a la geo-distribución, MongoDB admite implementaciones geo-distribuidas para conjuntos de réplica para garantizar una alta disponibilidad en caso de fallos en el centro de datos. En este contexto, las instancias secundarias se pueden distribuir a través de varios centros de datos, como se muestra en la siguiente figura. Además, las secundarias con recursos limitados o restricciones de red se pueden configurar con una prioridad para controlar su electabilidad como primaria en caso de fallos. Clúster dividido: Escalabilidad horizontal y alta disponibilidad con complejidad operativa MongoDB soporta la escalación horizontal mediante la división de datos en varias instancias primarias para hacer frente a las cargas de trabajo intensivas de escritura y los tamaños de datos crecientes. En un clúster dividido, cada conjunto de réplica que consta de una primaria y varias secundarias representa una división. Para habilitar el sharding, se requieren tipos de nodo MongoDB adicionales: Una instancia de mongos actúa como un router de consulta, proporcionando una interfaz entre las aplicaciones del cliente y el clúster fragmentado. En consecuencia, los clientes nunca se comunican directamente con los fragmentos, sino siempre a través del router de consulta. Los routers de consulta son componentes sin estado y ligeros que pueden operarse en recursos dedicados o junto con las aplicaciones del cliente. Rutas de consulta (mongos) Se recomienda desplegar múltiples routers de consulta para garantizar la accesibilidad del clúster porque los routers de consulta son la interfaz directa para los controladores del cliente. No hay límite al número de routers de consulta, pero como se comunican con frecuencia con los servidores de config, debe tenerse en cuenta que demasiados routers de consulta pueden sobrecargar los servidores de config. Los servidores de config almacenan los metadatos de un clúster fragmentado, incluyendo el estado y la organización de todos los datos y componentes. Los metadatos incluyen la lista de fragmentos en cada fragmentos y los rangos que definen los fragmentos. El sharding de datos en MongoDB se realiza a nivel de colección, y una colección puede ser shardada basándose en una clave de shard. MongoDB utiliza una clave de shard para determinar qué documentos pertenecen a qué shard. Las opciones comunes de clave de shard incluyen el campo _id y un campo con una alta cardinalidad, como un timestamp o ID de usuario. MongoDB soporta tres estrategias de sharding: base de rango, base de hash y base de zona. Las particiones de división ordenadas distribuyen los documentos entre las fracciones de acuerdo con el valor de la clave de división. Esto mantiene los documentos con los valores de la clave de división cercanos entre sí y funciona bien para consultas basadas en el rango, por ejemplo en datos de serie de tiempo. La división ordenada garantiza una distribución uniforme de escritos entre las fracciones, lo que favorece las cargas de trabajo de escritura. La división de zona permite a los desarrolladores definir reglas de división personalizadas, por ejemplo, para asegurarse de que los datos más relevantes se encuentren en las fracciones que están geográficamente más cercanas a los servidores de la aplicación. Además, los clusters fragmentados se pueden desplegar en una configuración geo-distribuida para superar fallas en los centros de datos, como se muestra en la siguiente figura. La arquitectura ScyllaDB – Multi-Primary para alta disponibilidad y escalabilidad horizontal A diferencia de MongoDB, ScyllaDB no sigue las arquitecturas RDBMS clásicas con un nodo primario y varios nodos secundarios, sino que utiliza una estructura descentralizada, donde todos los datos se distribuyen y replican sistemáticamente a través de varios nodos formando un clúster. Un clúster es una colección de nodos interconectados organizados en una arquitectura de anillo virtual, a través de la cual se distribuyen los datos. El anillo se divide en vNodes, que representan una serie de tokens asignados a un nodo físico, y se replican a través de nodos físicos de acuerdo con el factor de replicación establecido para el espacio clave. Todos los nodos se consideran iguales, en un sentido multiprimario. Sin un líder definido, el clúster no tiene un único punto de fallo. Los nodos pueden ser servidores individuales en el lugar de trabajo, o servidores virtuales (instancias de nube pública) compuestos por un subconjunto de hardware en un servidor físico más grande. En cada nodo, los datos se dividen más adelante en fragmentos. Todos los nodos se comunican entre sí a través de la Este protocolo decide en qué partición se escriben los datos y busca los registros de datos en la partición derecha utilizando los índices. Protocolo de GOSP Cuando se trata de escalar, la arquitectura de ScyllaDB está diseñada para facilitar el sharding horizontal a través de múltiples servidores y regiones. El sharding en ScyllaDB se realiza a nivel de tabla, y una tabla se puede sharding basado en una clave de partición. La clave de partición puede ser una sola columna o un compuesto de varias columnas. ScyllaDB también admite el sharding basado en rango, donde las filas se distribuyen a través de los shards basados en el rango de valor de la clave de partición, así como el sharding basado en hash para distribuir de manera uniforme los datos y evitar los puntos calientes. Además, ScyllaDB permite que los datos se replicen en varios centros de datos para una mayor disponibilidad y latencias más bajas.En esta configuración multi-centro de datos o multi-región, los datos entre centros de datos se replican de forma asíncrona. En el lado del cliente, las aplicaciones pueden o no ser conscientes de la implementación de varios centros de datos, y cabe al desarrollador de aplicaciones decidir sobre la conciencia de los centros de datos fallback. Esto se puede configurar a través de las opciones de coherencia de lectura y escritura que definen si las consultas se ejecutan contra un único centro de datos o entre todos los centros de datos. Un punto de vista comparativo de escalabilidad sobre las arquitecturas distribuidas de MongoDB y ScyllaDB Cuando se trata de escalabilidad, es necesario considerar los enfoques de distribución significativamente diferentes de ScyllaDB y MongoDB, especialmente para los clusters autogestionados que se ejecutan en el lugar o en IaaS. La arquitectura de MongoDB permite escalar fácilmente las cargas de trabajo de lectura pesada aumentando el número de secundarios en un conjunto de réplica. Sin embargo, para escalar cargas de trabajo con una notable proporción de escritura, los conjuntos de réplica necesitan ser transformados en un conjunto de réplica fragmentada y esto viene con varios desafíos. En primer lugar, se requieren dos servicios MongoDB adicionales: n routers de consulta (mongos) y un conjunto de replica de servidores de configuración para garantizar una alta disponibilidad. Por lo tanto, se requieren considerablemente más recursos para permitir el fragmentado en primer lugar. Además, la complejidad operativa aumenta claramente. Por ejemplo, un clúster fragmentado con tres partes requiere un conjunto de réplica de tres instancias de mongos, un conjunto de réplica de tres servidores de configuración y tres partes - cada una de las cuales consiste en una primaria y al menos dos secundarias. El segundo desafío es la repartición de datos en el clúster fragmentado. Aquí, MongoDB aplica una tarea de fondo en curso que desencadena de forma autónoma la redistribución de datos a través de los fragmentos. La repartición no ocurre tan pronto como se agrega un nuevo fragmento al clúster, sino cuando se alcanzan ciertos umbrales internos. En consecuencia, aumentar el número de fragmentos escalará inmediatamente el clúster pero puede tener un efecto de escalado retardado. Hasta la versión 5.0 de MongoDB, los propios ingenieros de MongoDB recomiendan no escalar, sino escalar verticalmente con máquinas más grandes si es posible. Escalar un clúster ScyllaDB es comparativamente fácil y transparente para el usuario gracias a la arquitectura multiprimaria de ScyllaDB. Aquí, cada nodo es igual, y no se necesitan servicios adicionales para escalar el clúster a cientos de nodos. Además, la repartición de datos se activa tan pronto como se agrega un nuevo nodo al clúster. En este contexto, ScyllaDB ofrece claras ventajas sobre MongoDB. En primer lugar, gracias al enfoque de hashing consistente, los datos no necesitan ser repartidos por todo el clúster, sólo por un subconjunto de nodos. En segundo lugar, la repartición comienza con la adición del nuevo nodo, lo que facilita el timing de la acción de escalado. Esto es importante, ya que la repartición pondrá una carga adi Las principales diferencias de escalabilidad se resumen en la siguiente tabla: Conclusión y Outlook Si comparamos dos distribuidos En las bases de datos, siempre se descubren algunos paralelos, pero también numerosas diferencias considerables. . Ambas bases de datos abordan casos de uso similares y tienen una estrategia similar de producto y comunidad. Pero cuando se trata del lado técnico, se pueden ver los diferentes enfoques y enfoques. Ambas bases de datos están construidas para permitir una alta disponibilidad a través de una arquitectura distribuida. Pero cuando se trata de las cargas de trabajo objetivo, MongoDB permite comenzar fácilmente con implementaciones de nodo único o conjunto de réplica que se ajustan bien para cargas de trabajo pequeñas y medianas, mientras que abordar cargas de trabajo grandes y conjuntos de datos se convierte en un reto debido a la arquitectura técnica. NoSQL ScyllaDB y MongoDB ScyllaDB aborda claramente las cargas de trabajo críticas al rendimiento que requieren fácil y alta escalabilidad, alto rendimiento, latencia baja y estable, y todo en una implementación de varios centros de datos. Esto también se demuestra por los casos de uso intensivo de datos de empresas como Discord, Numerly o TRACTIAN que migraron de MongoDB a ScyllaDB para resolver con éxito problemas de rendimiento. Y para proporcionar más información sobre sus respectivas capacidades de rendimiento, proporcionamos una comparación de rendimiento transparente y reproducible en un informe de referencia separado que investiga el rendimiento, la escalabilidad y los costes de MongoDB Atlas y ScyllaDB Cloud. Detalles adicionales de comparación de ScyllaDB vs MongoDB Ver el completo para una versión ampliada de esta comparación técnica, incluidos los detalles de la comparación: Comparación BenchANT MongoDB vs ScyllaDB Modelo de datos Lenguaje Querido Casos de uso y ejemplos de clientes Opciones de consistencia de datos Experiencia operativa de primera mano
