optimizar - ¿Usando MongoDB vs MySQL con muchos campos JSON?
convertir sql a nosql (3)
Hay un tipo de aplicación de microblogging. Dos tiendas de bases de datos básicas principales puestas a cero son: MySQL o MongoDB.
Estoy planeando desnormalizar gran cantidad de datos, es decir, un voto realizado en una publicación se almacena en una mesa de votación, y también se incrementa el recuento en la tabla de publicaciones principales. También hay otras acciones relacionadas con la publicación (por ejemplo, Me gusta, vota abajo).
Si utilizo MySQL, algunos de los datos se adaptan mejor a JSON que a un esquema fijo, para búsquedas más rápidas.
P.ej
POST_ID | activity_data
213423424 | { ''likes'': {''count'':213,''recent_likers'' :
[''john'',''jack'',..fixed list of recent N users]} , ''smiles'' :
{''count'':345,''recent_smilers'' :
[''mary'',''jack'',..fixed list of recent N users]} }
También hay otros componentes de la aplicación, donde se propone el uso de JSON. Entonces, para actualizar un campo JSON, la secuencia es:
Lee el JSON en script python.
Actualizar el JSON
Almacena el JSON de nuevo en MySQL.
Hubiera sido una operación única en MongoDB con operaciones atómicas como $push , $inc , $pull etc. También la estructura de documentos de MongoDB se adapta bien a mis datos.
Mis consideraciones al elegir el almacén de datos.
Respecto a MySQL:
- Estable y familiar.
- Copia de seguridad y restauración es fácil.
- Algunos cambios de esquema futuros se pueden evitar utilizando algunos campos como JSON sin esquema.
- Puede que tenga que usar capa de memcached temprano.
- Los blobs de JSON serán estáticos en algunas tablas como las Publicaciones principales, sin embargo, se actualizarán mucho en otras tablas como Publicación de votos y Me gusta.
Respecto a MongoDB:
- Más adecuado para almacenar el esquema menos datos como documentos.
- Se podría evitar el almacenamiento en caché hasta una etapa posterior.
- A veces, la aplicación puede volverse intensiva en escritura, MongoDB puede funcionar mejor en aquellos puntos donde las escrituras inseguras no son un problema.
- No estoy seguro acerca de la estabilidad y la fiabilidad.
- No estoy seguro de lo fácil que es hacer una copia de seguridad y restaurar.
Preguntas:
- ¿Debemos elegir MongoDB si la mitad de los datos no tiene esquemas y se está almacenando como JSON si se usa MySQL?
Algunos de los datos, como las publicaciones principales, son críticos, por lo que se guardarán con escrituras seguras, los contadores, etc., se guardarán con escrituras inseguras. ¿Está esta política basada en la importancia de los datos y la intensidad de la escritura correcta?
¿Qué tan fácil es monitorear, respaldar y restaurar MongoDB en comparación con MySQL? Necesitamos planificar copias de seguridad periódicas (por ejemplo, diariamente) y restaurarlas con facilidad en caso de desastre. ¿Cuáles son las mejores opciones que tengo con MongoDB para que sea una apuesta segura para la aplicación?
La estabilidad, la copia de seguridad, las instantáneas, la restauración, la adopción más amplia La durabilidad de la base de datos son las razones que me indican el uso de MySQL como RDBMS + NoSql, aunque un almacenamiento de documentos NoSQL podría servir mejor a mi propósito.
Concentre sus opiniones en la elección entre MySQL y MongoDB teniendo en cuenta el diseño de la base de datos que tengo en mente. Sé que podría haber mejores maneras de planificar el diseño de la base de datos con documentos RDBMS o MongoDB. Pero ese no es el foco actual de mi pregunta.
ACTUALIZACIÓN : desde MySQL 5.7 en adelante, MySQL admite un tipo de datos JSON nativo rico que proporciona flexibilidad de datos así como consultas JSON enriquecidas.
Entonces, para responder directamente a las preguntas ...
¿Debemos elegir mongodb si la mitad de los datos no tienen esquemas y se está almacenando como JSON si se usa MySQL?
El almacenamiento sin esquemas es sin duda una razón de peso para ir con MongoDB, pero como ha señalado, también es bastante fácil almacenar JSON en un RDBMS. El poder detrás de MongoDB está en las consultas enriquecidas contra el almacenamiento sin esquemas.
Si puedo señalar una pequeña falla en la ilustración sobre la actualización de un campo JSON, no es simplemente una cuestión de obtener el valor actual, actualizar el documento y luego enviarlo a la base de datos. El proceso debe estar envuelto en una transacción. Las transacciones tienden a ser bastante sencillas, hasta que comienza a desnormalizar su base de datos. Entonces, algo tan simple como grabar un upvote puede bloquear tablas en todo su esquema.
Con MongoDB, no hay transacciones. Pero las operaciones casi siempre se pueden estructurar de manera que permitan actualizaciones atómicas. Esto generalmente involucra algunos cambios dramáticos de los paradigmas de SQL, pero en mi opinión son bastante obvios una vez que dejas de intentar forzar objetos en tablas. Por lo menos, muchas otras personas se han encontrado con los mismos problemas a los que se enfrentará, y la comunidad de Mongo tiende a ser bastante abierta y vocal acerca de los desafíos que han superado.
Algunos de los datos, como las publicaciones principales, son críticos, por lo que se guardarán con escrituras seguras, los contadores, etc., se guardarán con escrituras inseguras. ¿Está esta política basada en la importancia de los datos y la intensidad de la escritura correcta?
Por "escrituras seguras" asumo que te refieres a la opción de activar un "getLastError () automático después de cada escritura. Tenemos una envoltura muy delgada sobre un DBCollection que nos permite un control muy preciso sobre cuándo se llama a getLastError (). Sin embargo, nuestra política no se basa en qué tan importantes son los datos, sino en si el código que sigue a la consulta espera que las modificaciones sean visibles de inmediato en las siguientes lecturas.
En general, este indicador sigue siendo deficiente y, en cambio, hemos migrado a findAndModify () por el mismo comportamiento. En la ocasión en que aún llamamos explícitamente a getLastError () es cuando es probable que la base de datos rechace una escritura, como cuando insertamos () con un _id que puede ser un duplicado.
¿Qué tan fácil es monitorear, respaldar y restaurar Mongodb en comparación con mysql? Necesitamos planificar copias de seguridad periódicas (por ejemplo, diariamente) y restaurarlas con facilidad en caso de desastre. ¿Cuáles son las mejores opciones que tengo con mongoDb para que sea una apuesta segura para la aplicación?
Me temo que no puedo hablar sobre si nuestra política de copia de seguridad / restauración es efectiva ya que aún no hemos tenido que restaurarla. Estamos siguiendo las recomendaciones de MongoDB para realizar copias de seguridad; @ mark-hillick ha hecho un gran trabajo al resumirlos. Estamos utilizando conjuntos de réplicas, y hemos migrado versiones de MongoDB, así como también hemos introducido nuevos miembros de réplicas. Hasta ahora no hemos tenido tiempo de inactividad, por lo que no estoy seguro de poder hablar bien sobre este punto.
La estabilidad, la copia de seguridad, las instantáneas, la restauración, la adopción más amplia y la durabilidad de la base de datos son las razones que me indican el uso de MySQL como RDBMS + NoSql, aunque un almacenamiento de documentos NoSQL podría servir mejor a mi propósito.
Por lo tanto, en mi experiencia, MongoDB ofrece almacenamiento de datos sin esquemas con un conjunto de primitivas de consulta lo suficientemente ricas como para que las transacciones a menudo puedan ser reemplazadas por operaciones atómicas. Ha sido difícil desaprender más de 10 años de experiencia en SQL, pero cada problema que he encontrado ha sido abordado por la comunidad o 10gen directamente. No hemos perdido datos ni hemos tenido ningún tiempo de inactividad que pueda recordar.
En pocas palabras, MongoDB es indiscutiblemente el mejor ecosistema de almacenamiento de datos que he usado en términos de consultas, mantenimiento, escalabilidad y confiabilidad. A menos que tuviera una aplicación que fuera tan claramente relacional que no pudiera, con buena conciencia, usar otra cosa que no fuera SQL, haría todo lo posible por usar MongoDB.
No trabajo para 10gen, pero estoy muy agradecido por la gente que lo hace.
No voy a comentar sobre las comparaciones (trabajo para 10gen y no creo que sea apropiado que lo haga), sin embargo, responderé las preguntas específicas de MongoDB para que pueda tomar una mejor decisión.
Apoyo
La documentación here es muy completa, cubriendo muchos aspectos:
- Métodos a nivel de bloque (LVM lo hace muy fácil y mucha gente lo hace)
- Con / Sin Diario
- Instantáneas de EBS
- Instantáneas generales
- Replicación (técnicamente no es una copia de seguridad, sin embargo, mucha gente usa conjuntos de réplicas para su redundancia y copia de seguridad, no lo recomiendo pero está hecho)
Hasta hace poco, no hay un equivalente de MongoDB de mylvmbackup pero un buen tipo escribió uno :) En sus palabras
Primeros días hasta ahora: es solo un script de shell glorificado y necesita mucho más control de errores. Pero ya me funciona y pensé en compartir la alegría. Informes de errores, parches y sugerencias de bienvenida.
Consíguete una copia de here .
Restaura
mongodump está completamente documentado here y mongorestore está here .
mongodump no contendrá los índices pero sí la colección system.indexes, por lo que mongorestore puede reconstruir los índices cuando restaure el archivo bson. El archivo bson es el dato real, mientras que mongoexport/mongoimport no es de tipo seguro por lo que podría ser cualquier cosa (técnicamente hablando) :)
Vigilancia
Documentado here .
Me gustan los Cacti, pero afaik, las plantillas de Cacti no se han mantenido al tanto de los cambios en MongoDB y, por lo tanto, dependen de la sintaxis antigua, de modo que después de la versión 2.0.4, creo que hay problemas.
Nagios funciona bien, pero es Nagios, así que o lo amas o lo odias. Mucha gente usa Nagios y parece que les proporciona una gran visibilidad.
He escuchado de algunas personas que miran Zappix pero nunca lo he usado, así que no puedo comentar.
Además, puede utilizar MMS, que es gratuito y está alojado externamente. Sus instancias de MongoDB ejecutan un agente y uno de esos agentes se comunica (utilizando el código de Python) a través de https a mms.10gen.com. Usamos MMS para ver todas las estadísticas de rendimiento en las instancias de MongoDB y es muy beneficioso desde un punto de vista amplio de alto nivel, además de ofrecer la posibilidad de profundizar. Es fácil de instalar y no tiene que ejecutar ningún hardware para esto. Muchos clientes lo ejecutan y algunos lo complementan con Cacti / Nagios.
La información de ayuda sobre MMS se puede encontrar here (es un documento muy detallado e inclusivo).
Una de las desventajas de una solución mysql con json almacenado es que no podrá buscar eficientemente en los datos de json. Si lo almacena todo en mongodb, puede crear índices y / o consultas en todos sus datos, incluido el json.
Las escrituras de Mongo funcionan muy bien, y realmente lo único que pierde frente a mysql es el soporte de transacciones y, por lo tanto, la capacidad de deshacer copias guardadas en varias partes. Sin embargo, si puede confirmar sus cambios en las operaciones atómicas, entonces no hay un problema de seguridad de los datos. Si eres replicado, mongo proporciona una promesa "eventualmente consistente" de tal manera que los esclavos eventualmente reflejarán al maestro.
Mongodb no proporciona la aplicación nativa o la cascada de ciertas construcciones de db, como las claves foráneas, por lo que debe administrarlas usted mismo (por ejemplo, a través de la composición, que es una de las fortalezas de Mongo), o mediante el uso de dbrefs.
Si realmente necesita soporte de transacciones y escrituras sólidas y "seguras", pero aún desea la flexibilidad que proporciona nosql, puede considerar una solución híbrida. Esto le permitiría usar mysql como su tienda principal de correos, y luego usar mongodb como su tienda ''sin detalles''. Aquí hay un enlace a un documento que analiza soluciones híbridas de mongo / rdbms: http://www.10gen.com/events/hybrid-applications El artículo es del sitio de 10gen, pero puede encontrar otros ejemplos simplemente haciendo una búsqueda rápida en Google.