Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. Dentro del dominio NoSQL, ScyllaDB y MongoDB son dos animales totalmente diferentes. MongoDB no necesita introducción. Su simple adopción y extensa comunidad / ecosistema lo han hecho el estándar de facto para comenzar con La arquitectura cercana al metal de ScyllaDB permite una predicción de baja latencia a alta capacidad. , de y muchos otros que están escalando y golpeando el muro con sus bases de datos existentes. NoSQL Discordia Tráiler Aplicaciones intensivas de datos Pero las migraciones de bases de datos no son el foco aquí. en lugar de eso, echemos un vistazo a cómo estas dos bases de datos claramente diferentes podrían coexistir dentro de la misma pila de tecnología - cómo son fundamentalmente diferentes, y los mejores casos de uso para cada uno. al igual que diferentes zapatos funcionan mejor para correr una maratón vs. escalar el Monte Everest vs. asistir a su boda, diferentes bases de datos funcionan mejor para diferentes casos de uso con diferentes cargas de trabajo y expectativas de latencia / rendimiento. En lugar de proporcionar la perspectiva del vendedor, vamos a compartir las ideas de un entusiasta de código abierto que tiene una amplia experiencia usando tanto ScyllaDB como MongoDB en la producción: Alexys Jacob, el CTO de Numberly. Aquí hay tres tomas clave de su discurso técnico detallado: Scaling Writes es más complejo en MongoDB La unidad base de una topología MongoDB se llama un conjunto de réplicas, que se compone de un nodo primario y generalmente varios nodos secundarios (pensemos en réplicas calientes). Sólo se permite que el nodo primario escriba datos. Después de maximizar el escalado vertical de la escritura en MongoDB, su única opción para escalar las escrituras se convierte en lo que se llama un clúster fragmentado. Esto requiere la adición de nuevos conjuntos de réplicas porque no puede tener múltiples primarias en un único conjunto de réplica. El reparto de datos en los conjuntos de réplica de MongoDB requiere el uso de una clave especial para especificar qué datos es responsable cada conjunto de réplica, así como la creación de un conjunto de réplica de metadatos que rastrea qué fragmento de datos vive en cada réplica (el triángulo azul en el diagrama de abajo). La complejidad de escalar escritos en MongoDB Tener todos estos nodos conduce a mayores costes de operación y mantenimiento, así como a desperdicios de recursos ya que no se puede tocar la IO de los nodos de replicación para escribir, lo que hace que los clusters MongoDB fragmentados sean el peor enemigo de su coste total de propiedad, como señaló Alexys. Para ScyllaDB, escalar es mucho más simple. explicó, “En el lado de ScyllaDB, si desea agregar más rendimiento, simplemente añade nodos. Alejandro se puso en contacto con esta escalera: “¡Evite crear clusters MongoDB, por favor! Yo podría escribir un libro con historias de guerra sobre este mismo tema. La razón principal es el hecho de que MongoDB no vincula la carga de trabajo a CPUs. Y el sharding, la distribución de datos entre conjuntos de réplica en un clúster se hace por un trabajo de fondo (el equilibrador). Este equilibrador siempre se ejecuta, siempre mirando cómo se debe hacer el sharding, y siempre asegurando que los datos se dispersan y se equilibren en todo el clúster. No es natural porque no se basa en un hash consistente. Es algo que debe calcularse una y otra vez. Divide los datos en pedazos y luego los mueve alrededor. Esto tiene un impacto directo en el rendimiento de su clúster MongoDB porque no hay aislamiento de esta carga de trabajo MongoDB favorece la flexibilidad sobre el rendimiento, mientras que ScyllaDB favorece el rendimiento consistente sobre la versatilidad ScyllaDB y MongoDB tienen prioridades claramente diferentes cuando se trata de flexibilidad y rendimiento. En el frente de modelado de datos, MongoDB soporta nativamente consultas geoespaciales, búsqueda de texto, tuberías de agregación, consultas de gráficos y flujos de cambio. Aunque ScyllaDB – un almacén de columnas amplias (a.k.a. key-value) – soporta tipos definidos por el usuario, contadores y transacciones ligeras, las opciones de modelado de datos son más restringidas que en MongoDB. Alexys observó, “Desde una perspectiva de desarrollo, interactuar con un objeto JSON simplemente se siente más natural que interactuar con una fila”. de aplicar la validación del esquema antes de la inserción de datos, ScyllaDB Estos datos se ajustan al esquema definido. Opciones Requiere La consulta también es más sencilla con MongoDB ya que sólo está filtrando e interactuando con JSON. También es más flexible, para mejor o para peor. MongoDB le permite emitir cualquier tipo de consulta, incluidas las consultas que causan un rendimiento suboptimal con su carga de trabajo de producción. ScyllaDB no lo permitirá. Si lo intenta, ScyllaDB le advertirá. Si decide proceder a su propio riesgo, puede introducir un cualificador que indica que realmente entiende lo que está entrando en usted mismo. Alexys resumió las diferencias clave desde una perspectiva de desarrollo: “MongoDB favorece la flexibilidad sobre el rendimiento. Es fácil de interactuar con y no va a entrar en tu camino. Pero tendrá impactos en el rendimiento – impactos que son buenos para algunas cargas de trabajo, pero inaceptables para otros. Por otro lado, ScyllaDB favorece el rendimiento consistente sobre la versatilidad. Parece un poco más fijo y un poco más rígido en el exterior. Pero una vez más, eso es para tu propio bien para que puedas tener un rendimiento consistente, funcionar bien y interactuar bien con el sistema. En mi opinión, esto hace una verdadera diferencia cuando tienes cargas de trabajo que son sensibles a la latencia y el rendimiento.” Es importante tener en cuenta que incluso las consultas que siguen las mejores prácticas de rendimiento se comportarán de manera diferente en MongoDB que en ScyllaDB. No importa cuán cuidadoso esté, no superará la sanción de rendimiento que se deriva de diferencias arquitectónicas fundamentales. Juntos, ScyllaDB y MongoDB son una gran combinación de NoSQL "No es una pelea de muerte; somos usuarios felices de MongoDB y ScyllaDB", continuó Alexys. Número selecciona la mejor base de datos para los requisitos técnicos de cada caso de uso. En Numerly, MongoDB se utiliza para dos tipos de casos de uso: Web backend con APIs REST y, posiblemente, esquemas flexibles. Preguntas en tiempo real sobre datos de comportamiento impredecibles. Por ejemplo, algunas de las aplicaciones de Numberly se inundan con datos de seguimiento web que sus clientes recopilan y envían (cada cliente con sus propias aplicaciones desarrolladas internamente). Numberly no tiene una manera de imponer un esquema estricto a esos datos, pero necesita poder consultarlo y procesarlo. ScyllaDB se utiliza para tres tipos de casos de uso en Numberly: Pipelines de datos sensibles a la latencia en tiempo real. Esto implica una gran cantidad de enriquecimiento de datos, donde hay múltiples fuentes de datos que necesitan ser correlacionadas, en tiempo real, en las pipelines de datos. Según Alexys, “Esto es complicado de hacer... y necesitas fuertes garantías de latencia para no romper los SLA [acuerdos de nivel de servicio] de las aplicaciones y los procesos de datos en los que tus clientes dependen”. Numerly también mezcla una gran cantidad de cargas de trabajo en serie y en tiempo real en ScyllaDB porque proporciona lo mejor de ambos mundos (como Numerly compartió anteriormente). “Tuvimos Hive en un camino y MongoDB en el otro. Algunos de los backends web de Numberly se implementan en GraphQL. Cuando se trabaja con APIs basadas en esquemas, tiene sentido tener una base de datos basada en esquemas con baja latencia y alta disponibilidad. Alexys concluyó: “Muchos de nuestros ingenieros de backend, y también los ingenieros de frontend, están adoptando ScyllaDB. Vemos una tendencia de personas que adoptan ScyllaDB, más y más personas de tecnología preguntando ‘Tengo este caso de uso, ¿sería ScyllaDB un buen ajuste?’ La mayoría del tiempo, la respuesta es ‘sí.’ Así que, la adopción de ScyllaDB está creciendo. Bonus: Más insights de Alexys Jacob Alexys es un contribuyente extremadamente generoso a las comunidades de código abierto, con respecto tanto al código como a las conversaciones de conferencias. https://ultrabug.fr/ Sobre Siguiente Cynthia Dunlop Cynthia es directora senior de estrategia de contenido en ScyllaDB. Ha estado escribiendo sobre desarrollo de software e ingeniería de calidad durante más de 20 años.
