MongoDB vs Cassandra: cuál es mejor para los datos de Internet de las cosas [cerrado]

Recientemente, uno de mis clientes me pidió que tomara una decisión sobre la elección de la base de datos para un proyecto industrial (donde puede haber muchos sensores, incluida la cámara para fotos o videos), donde el flujo de datos es enorme.

Estoy pensando en usar MongoDB o Cassandra. Además, mi cliente solicita elegir una base de datos cuyo lenguaje de programación es similar a T-SQL (SQL Server) [No estoy seguro de si alguno de estos lenguajes es similar a T-SQL o NO; si no, es posible que deba hacer que el cliente entienda esto] - Puede ser que tengan personas que puedan entender T-SQL.

¿Alguien podría decirme cuál sería mejor y por qué? ¿Hay algún otro DB que pueda usar para esto?

Tenga en cuenta que este sitio no presenta solicitudes de comparaciones de productos: SR se trata de sugerir software específico para necesidades específicas que usted defina. Para obtener más información, consulte: ¿Es la herramienta x frente a la herramienta ya una pregunta justa?

Respuestas (2)

tldr; Voy a decir que Cassandra es probablemente la mejor opción para ti.

puede haber muchos sensores, incluida la cámara para fotos o videos] - Donde el flujo de datos es enorme.

Debido a su naturaleza basada en registros, el seguimiento de los datos del sensor es un buen caso de uso para Cassandra. La capacidad de manejar grandes cantidades de rendimiento de escritura es una fortaleza de Cassandra, y puede escalar linealmente agregando tantos nodos como sea necesario para manejar la carga de trabajo. También encontrará que la fragmentación de réplicas en varios nodos será más fácil de configurar con Cassandra (debido a su implementación de nodos virtuales).

el cliente pide elegir DB cuyo lenguaje de programación es similar a T-SQL

El lenguaje de consulta de Cassandra (CQL) es muy similar a SQL. Varios de los comandos son exactamente iguales. Esto se hizo intencionalmente para tratar de reducir la curva de aprendizaje de Cassandra.

Sin embargo, esto también es un arma de doble filo. Si bien se sienten similares, CQL y SQL no son lo mismo. La mayor parte de mi representante en StackOverflow proviene de ayudar a los desarrolladores con consultas de CQL que abordaron con una mentalidad SQL/relacional. Para resumir, puede meterse en problemas al hacer suposiciones basadas en SQL sobre CQL, por lo que usted y/o su cliente deberán tener cuidado al respecto.

MongoDB utiliza un lenguaje de consulta basado en Javascript. Si bien no es ni remotamente similar a SQL, los piratas informáticos de Javascript experimentados tienden a hacerlo bien.

Algunos puntos de advertencia adicionales sobre Cassandra:

  • La misma naturaleza basada en registros que permite que Cassandra funcione bien mientras maneja grandes cantidades de rendimiento de escritura, también hace que sea problemático cuando se trata de eliminar datos. Si planea eliminar datos con frecuencia, es posible que Cassandra no sea la mejor opción.
  • El modelo de datos lo es todo con Cassandra. Deberá adoptar un enfoque de diseño basado en tablas para el modelado. Esto significa que podría crear una tabla para cada consulta que se pudiera realizar y, por lo general, significa desnormalizar y/o duplicar datos en algunas tablas. MongoDB funciona de la misma manera, pero según mi experiencia, Cassandra es menos indulgente si tiene un modelo de datos incorrecto.
  • Los índices secundarios a veces pueden ayudar con la flexibilidad de las consultas. Pero tienen la reputación de ser un asesino del rendimiento, por lo que es mejor evitarlos con Cassandra. Si construye un modelo de datos apropiado, no debería necesitarlos en absoluto. No tengo experiencia usándolos a escala con MongoDB, pero pueden funcionar mejor.

En resumen, Cassandra parece una mejor opción para usted (suponiendo que cree un buen modelo de datos y no lo elimine con frecuencia), ya que cumple con estos criterios:

  • Capacidad para manejar grandes cantidades de datos.
  • Muchos casos de uso existentes de Cassandra para datos basados ​​en sensores.
  • CQL debe pasar como un lenguaje de consulta "SQL familiar".

En primer lugar: si su cliente le pregunta algo que no puede responder completamente según su propio conocimiento y experiencia, es una muy mala práctica comercial hacer cualquier sugerencia, en mi humilde opinión.

Comentarios sobre Cassandra vs/y MongoDB

Los requisitos también son un poco blandos, por decir lo menos.

Donde el flujo de datos es enorme

Si se configura correctamente, tanto Cassandra como MongoDB pueden manejar grandes cantidades de datos. Nuevamente: si se configura correctamente . Ambos DBMS requieren bastante conocimiento y experiencia para manejar la carga de manera eficiente. Dado que parece que ambos son inexistentes, ya sea de su lado o del lado de los clientes, contratar a alguien que tenga tanto conocimiento como experiencia es inevitable a corto o mediano plazo. Una decisión tecnológica de tan alto impacto debe basarse en hechos y análisis, no en meras suposiciones o documentación desnatada.

Además, mi cliente pide elegir DB cuyo lenguaje de programación es un poco similar a T-SQL

Por supuesto que lo es, ya que el cliente asume que el conocimiento existente en la empresa puede ser reutilizado. La mayoría de las veces, esa es una inferencia errónea como @Aaron describió elocuentemente . Sugiero encarecidamente no tomar una decisión por el idioma de acceso, sino por la idoneidad para el propósito previsto. Como se escribió anteriormente, esta idoneidad debe determinarse analizando los casos de uso y otros requisitos.

Alternativas

Aunque no se indica explícitamente, presumiblemente estamos hablando de datos de series temporales. Podría valer la pena echar un vistazo a InfluxDB , que es una parte de una colección completa de software para manejar datos de series temporales, desde la recopilación hasta el metanálisis.