replicar - MongoDB contra Cassandra
mongodb replication (6)
Estoy evaluando cuál podría ser la mejor opción de migración.
Actualmente, estoy en un MySQL fragmentado (partición horizontal), con la mayoría de mis datos almacenados en blobs JSON. No tengo ninguna consulta de SQL compleja (ya migré después, ya que particioné mi db).
En este momento, parece que tanto MongoDB como Cassandra serían opciones probables. Mi situación:
- Un montón de lecturas en cada consulta, escrituras menos regulares
- No preocupado por la escalabilidad "masiva"
- Más preocupado por la simple configuración, mantenimiento y código
- Minimizar el costo de hardware / servidor
¿Por qué elegir entre una base de datos tradicional y un almacén de datos NoSQL? ¡Usa ambos! El problema con las soluciones NoSQL (más allá de la curva de aprendizaje inicial) es la falta de transacciones: usted hace todas las actualizaciones a MySQL y hace que MySQL llene un almacén de datos NoSQL para lecturas; luego se beneficia de las fortalezas de cada tecnología. Esto agrega más complejidad, pero ya tiene el lado de MySQL, solo agregue MongoDB, Cassandra, etc. a la mezcla.
Los almacenes de datos NoSQL generalmente escalan mucho mejor que un DB tradicional para las mismas especificaciones de lo contrario: hay una razón por la que Facebook, Twitter, Google y la mayoría de las empresas de nueva creación están utilizando soluciones NoSQL. No se trata solo de que los geeks se pongan al día con la nueva tecnología.
He usado MongoDB ampliamente (durante los últimos 6 meses), construyendo un sistema de administración de datos jerárquico, y puedo responder por la facilidad de configuración (instálelo, ejecútelo, utilícelo!) Y la velocidad. Mientras piense en los índices con cuidado, puede gritar a lo largo de la velocidad.
Supongo que Cassandra, debido a su uso con proyectos a gran escala como Twitter, tiene una mejor funcionalidad de escala, aunque el equipo de MongoDB está trabajando en paridad allí. Debo señalar que no he usado a Cassandra más allá de la etapa de prueba, por lo que no puedo hablar por los detalles.
Lo que realmente me gustó, cuando evaluábamos las bases de datos NoSQL, fue la consulta: Cassandra es básicamente un gigante almacén de clave / valor, y la consulta es un poco complicada (al menos en comparación con MongoDB), por lo que para el rendimiento tendrías que Duplique una gran cantidad de datos como una especie de índice manual. MongoDB, por otro lado, utiliza un modelo de "consulta por ejemplo".
Por ejemplo, supongamos que tiene una Colección (lenguaje MongoDB para el equivalente a una tabla RDMS) que contiene Usuarios. MongoDB almacena registros como Documentos, que son básicamente objetos JSON binarios. p.ej:
{
FirstName: "John",
LastName: "Smith",
Email: "[email protected]",
Groups: ["Admin", "User", "SuperUser"]
}
Si quisiera encontrar a todos los usuarios llamados Smith que tienen derechos de administrador, simplemente crearía un nuevo documento (en la consola de administración usando Javascript, o en producción usando el idioma de su elección):
{
LastName: "Smith",
Groups: "Admin"
}
... y luego ejecuta la consulta. Eso es. Hay operadores agregados para comparaciones, filtros RegEx, etc., pero todo es bastante simple, y la documentación basada en Wiki es bastante buena.
No he usado Cassandra, pero he usado MongoDB y creo que es increíble.
Si tu después de la configuración simple, esto es todo. Simplemente descomprime MongoDB y ejecuta el demonio mongod y listo. Se está ejecutando.
Obviamente, eso es solo un arranque, pero para comenzar es fácil.
Probablemente voy a ser un hombre extraño, pero creo que necesitas quedarte con MySQL. No ha descrito un problema real que deba resolver, y MySQL / InnoDB es un excelente back-end de almacenamiento incluso para datos blob / json.
Existe un truco común entre los ingenieros web para tratar de usar más NoSQL tan pronto como llegue la conclusión de que no se utilizan todas las características de un RDBMS. Esto solo no es una buena razón, ya que la mayoría de las bases de datos NoSQL tienen motores de datos bastante pobres (lo que MySQL llama un motor de almacenamiento).
Ahora, si no es de ese tipo, especifique lo que falta en MySQL y busque en una base de datos diferente (como, shards automáticos, failover automático, replicación multi-master, una garantía de consistencia de datos más débil en clúster pagando en mayor rendimiento de escritura, etc).
Vi una presentación en mongodb ayer. Definitivamente puedo decir que la configuración fue "simple", tan simple como descomprimirla y encenderla. Hecho.
Creo que tanto mongodb como cassandra se ejecutarán en prácticamente cualquier hardware regular de Linux, por lo que no debería encontrar demasiada barrera en esa área.
Creo que en este caso, al final del día, dependerá de con qué personal se sienta más cómodo y con el conjunto de herramientas que prefiera. En cuanto a la presentación en mongodb, el presentador indicó que el conjunto de herramientas para mongodb era bastante ligero y que no había muchas herramientas (dijeron realmente) similares a lo que está disponible para MySQL. Esta fue, por supuesto, su experiencia tan YMMV. Una cosa que me gustó de mongodb fue que parecía haber un montón de soporte de idiomas (Python y .NET son los dos que uso principalmente).
La lista de sitios que usan mongodb es bastante impressive , y sé que Twitter acaba de cambiar a usar Cassandra.
Un montón de lecturas en cada consulta, menos escrituras regulares
Ambas bases de datos se desempeñan bien en lecturas donde el conjunto de datos activos cabe en la memoria. Ambos también enfatizan los modelos de datos sin unión (y fomentan la desnormalización en su lugar), y ambos proporcionan índices en documents o rows , aunque los índices de MongoDB son actualmente más flexibles.
El motor de almacenamiento de Cassandra proporciona escrituras de tiempo constante sin importar qué tan grande crezca su conjunto de datos. Las escrituras son más problemáticas en MongoDB, en parte debido al motor de almacenamiento basado en b-tree, pero más debido al bloqueo de granularidad que hace.
Para el análisis, MongoDB proporciona un mapa personalizado / implementación de reducción; Cassandra proporciona compatibilidad nativa con Hadoop, incluso para Hive (un almacén de datos SQL creado en Hadoop map / reduce) y Pig (un lenguaje de análisis específico de Hadoop que muchos piensan que es mejor para mapear / reducir cargas de trabajo que SQL). Cassandra también apoya el uso de Spark .
No preocupado por la escalabilidad "masiva"
Si está buscando un solo servidor, MongoDB es probablemente un ajuste mejor. Para aquellos más preocupados por el escalado, la arquitectura de punto único de falla de Cassandra será más fácil de configurar y más confiable. (El bloqueo de escritura global de MongoDB también tiende a ser más doloroso). Cassandra también ofrece mucho más control sobre cómo funciona su replicación, incluido el soporte para múltiples centros de datos.
Más preocupado por la simple configuración, mantenimiento y código
Ambos son triviales de configurar, con valores predeterminados razonablemente listos para usar para un solo servidor. Cassandra es más fácil de configurar en una configuración de varios servidores, ya que no hay que preocuparse por los nodos de rol especial.
Si actualmente está utilizando blobs JSON, MongoDB es una combinación increíblemente buena para su caso de uso, ya que utiliza BSON para almacenar los datos. Podrá tener datos más ricos y más consultables que los que tendría en su base de datos actual. Esta sería la victoria más importante para Mongo.