Pros/contras de MongoDB o MySQL para este propósito

Question

Estoy buscando un poco de ayuda u orientación sobre qué base de datos usar para un proyecto. Si puede plantear algún punto, o anotar fallas, responder cualquier pregunta o promover cualquiera de los tipos de bases de datos para el propósito que estoy a punto de explicar, realmente lo agradecería.

De todas formas:

• Tenemos algún tipo de software que realiza un seguimiento formas.

• Tenemos usuarios que pueden tener MUCHAS propiedades diferentes, literalmente cientos de configuraciones, y no soy fanático de las tablas de MySQL tan amplias. I realmente me gusta Mongo por esto.

• Tenemos diferentes tipos de formularios, cada uno puede tener campos completamente diferentes. En este momento, tenemos una lista de formularios con datos genéricos, luego , únete a la tabla correspondiente para obtener datos adicionales. Tendría todos los estos campos en un documento distinto con Mongo, y podría fácilmente agregar campos sin preocuparse.

• Tenemos tarifas, notas, historial en cada formulario. Me gusta cómo en MySQL son están en una tabla diferente, y puedo obtener el historial por formulario o por usuario - igual que las notas.

• Nuestra política es más o menos mantener TODOS los datos, incluso eliminados o pre-editados datos ... para siempre. ¿Debo ser preocupado por alcanzar un límite de tamaño? Probablemente estamos hablando de 100gb a fines de 2013

• ¿Cuántas consultas de Mongo por página atascarán las cosas? 20? 100? ¿Cambiaría si tuviera una SSD en el servidor? (En este momento, tenemos alrededor de 60 MySQL consulta una página. Esto puede mejorarse sucesivamente.)

• ¿Es una mala idea para mi primer proyecto Mongo sea un poco mayor poco de software? ¿Es algo que puedo aprender mientras voy?

• Me gusta la insensibilidad a las mayúsculas y minúsculas de los nombres de las columnas MySQL para cosas sucias.

• En MySQL, reparto las cosas en diferentes tablas. ¿Está bien, en Mongo, juntar datos que PUEDEN separarse? Ejemplo: username, email, phone, license1 => [num,isValid], license2 => [num, isValid], notifications => [notification1...notification50000], password hash, salt, setting1, setting2...setting1000, permission1, permission2...permission1000 Por supuesto, haría uso del estilo anidado para organizar, pero ¿es mejor almacenar todo esto en "usuario" o dividirlo en configuraciones, licencias, permisos? Segundo ejemplo: formName, address, notes => [note1 => [user,note,date], note2 => [user,note,date]]

• ¿Hay algún problema al hacer una configuración HÍBRIDA, donde los datos del usuario son Mongo, y los datos del formulario están en MySQL?

• Tenemos que ejecutar muchos informes, ¿hay limitaciones en esto en Mongo? Por ejemplo, ¿me encontraría con problemas para buscar todas las formas de los últimos 40 días con una tarifa de más de $ 10, con las tarifas en cada fila sumadas, clasificadas por la edad del usuario que las completó?

• Redundancia de datos: en la nube de Amazon, MySQL tiene MASSIVE cantidades de redundancia. ¿Hay algún servicio que coincida con Mongo? ¿Es complejo entrar en eso por mi cuenta?

• ¿MongoDB es compatible con cualquier proveedor de "nube"? AWS hace mucho por MySQL, pero parece que estaría en mi propia para Mongo

sólo algunas cosas de la parte superior de mi cabeza - Realmente aprecio todo lo que nadie tiene que decir.

Answer 1

Tenemos usuarios que pueden tener MUCHAS propiedades diferentes, literalmente cientos de configuraciones, y no soy fanático de las tablas de MySQL tan amplias. I realmente me gusta Mongo por esto.

Tenemos diferentes tipos de formularios, cada uno puede tener campos completamente diferentes . En este momento, tenemos una lista de formularios con datos genéricos de , luego, únete a la tabla correspondiente para obtener datos adicionales. Tendría todos estos campos en un único documento con Mongo, y podría agregar campos fácilmente sin preocuparme.

De su post entiendo que su objetivo final es manejar los formularios de los usuarios & que contienen diferentes esquemas (también conocidos como schemaless). Creo que mongodb es una buena elección para este propósito.

Tenemos tarifas, notas, historial en cada formulario. Me gusta cómo en MySQL son están en una tabla diferente, y puedo obtener el historial por formulario o por usuario - igual que las notas.

No hay problema, puede utilizar diferentes documentos (o documentos incrustados basados ​​en el tamaño de la misma - 16 mb es el tamaño máximo del documento) para manejar esto sin ningún problema. lo que puede tener el esquema como

Form 
    - form field1 
    - form field1 
    - id of the fees doc 
    - id of the notes doc 
    - id of the history doc 

o (para los documentos incrustados)

Form 
    - form field1 
    - form field2 
    - embedded fees doc 
      - fees field1 
      - fees field2 
    - embedded notes doc 
      - notes field1 
      - notes field2 

Nuestra política se mantienen más o menos todos los datos, incluso borrados o datos pre-editado ... para siempre. > ¿Debería preocuparme por alcanzar un límite de tamaño? Probablemente estamos hablando de 100 GB a finales de> 2013

Va a almacenar los datos tanto como lo haría, ya que hay production deployments almacenamiento de datos más de terabytes.

¿Es una mala idea para mi primer proyecto de Mongo ser un bit algo importante del software? ¿Es algo que puedo aprender mientras voy?

Sí, si va a usar mongodb sin crear prototipos de su modelo de aplicación. Yo recomendaría implementar (prototipo) un conjunto mínimo de su aplicación (como características que apesta en mysql) y aprender conceptos básicos y ver qué tan cómodo está.

Me gusta la insensibilidad de mayúsculas y minúsculas de los nombres de las columnas MySQL para cosas rápidas y sucias.

Mongo impone la sensibilidad de mayúsculas y minúsculas, porque esa es la naturaleza de los pares de valores de clave BSON (así como JSON).

En MySQL, puedo dividir las cosas en diferentes tablas. ¿Está bien, en Mongo, juntar datos que PUEDEN separarse? Ejemplo: nombre de usuario, correo electrónico, teléfono, license1 => [num, isValid],

principal ventaja de mongo sobre otro almacén de datos SQL es, se puede almacenar la mayor cantidad de información relevante dentro del mismo documento (dentro del Tamaño de 16 mb). Si no está seguro sobre el tamaño o ciertas partes de los datos están creciendo, entonces puede dividir la parte en otra. Dado que le preocupa el número de consultas, reducirá drásticamente el número de solicitudes.

¿Hay algún problema con hacer una configuración híbrida, en donde los datos de usuario es Mongo, y la forma de datos está en MySQL?

Absolutamente no, de hecho, actualmente estoy ejecutando mongodb junto con mysql (solo para transacciones). Pero si no está manejando ninguna transacción, puede quedarse con mongodb.

Tenemos que ejecutar muchos informes, ¿hay limitaciones en esto en Mongo? Por ejemplo, ¿me encontraría con problemas para buscar cada formulario de los últimos 40 días con una tarifa superior a $ 10, con las tarifas en cada fila totalizadas, clasificadas por la edad del usuario que lo completó?

No, no veo ninguna limitación en esto. De hecho, se trata de consultas de gestión muy rápidas con los índices adecuados. Pero hay ciertas cosas que no se pueden hacer con mongo como las uniones normales, en su lugar se puede usar map/reduce para manejar los datos de los informes.

¿MongoDB es compatible con cualquier proveedor de "nube"? AWS hace mucho por MySQL, pero parece que estaría en mi propia para Mongo

Mongohq, Mongolab son algunos de los mongo gestionado dedicado servicios de alojamiento disponibles. También RedHat OpenShift & VMware cloundfoundry proporciona las plataformas de alojamiento para mongo, se puede extraer la mongo hosting center para obtener más información

Esperanza esto ayuda

Answer 2

He aquí alguna información sobre MongoDB en la nube: http://www.mongodb.org/display/DOCS/Hosting+Center

Answer 3

usted podría utilizar ya sea MongoDB o MySQL para lo que usted está deseando. Lo principal a tener en cuenta es la escala. En MySQL, escala verticalmente. Usted obtiene una máquina más grande, una mejor máquina. Y espero que haga la diferencia. En MongoDB escalas horizontalmente. Tiene varias máquinas y shard. Escalar verticalmente tiene un límite. Pero escalar horizontalmente no. En términos de escala de costo verticalmente es fácil de entender. Escalar horizontalmente generalmente resulta en la compra de un grupo de máquinas, y luego, cuando se quiere escalar más, se vuelve exponencial. Entonces es algo que debes considerar.

Hacer consultas estadísticas es una desventaja de MongoDB. Por algunas razones En primer lugar, habrá características de MySQL que simplemente no tendrá en MongoDB. En segundo lugar, para cualquiera que sea más una persona de DB y esté familiarizado con las sentencias de SQL, puede ser muy difícil ajustarse a la sintaxis de MongoDB. Es algo nuevo de aprender Y las personas a menudo les gusta (y trabajan bien con) lo que saben.

Como la mayoría de las otras plataformas 'NoSQL', MongoDB no emplea ACID, lo que le da un impulso de rendimiento. Pero eso significa que puede ser más arriesgado.

Existen algunas soluciones basadas en la nube. Eche un vistazo a MongoHQ y MongoLab. Puedo estar equivocado, pero no creo que tengan SSD. Son todos los ejes. Pero ping su apoyo. Por lo general responden rápido.

En mi experiencia, MongoDB va rápido. Muy rapido. MySQL es lento cuando tiene tablas grandes, combinaciones, etc. Y puede indexar en MongoDB, como era de esperar. He visto que si indexas demasiadas cosas, o cosas como las matrices donde debe indexar cada elemento, entonces puede ser más exigente por transacción.

No te empujaría en ninguna dirección. Es algo que requiere un poco de investigación. No diría que usar MongoDB es una mala idea para un proyecto tan grande, pero llevaría tiempo averiguar si funciona para su situación. Como con todas las cosas.

Existen algunas alternativas, específicamente extensiones propietarias de MySQL que pueden darle un gran aumento de rendimiento (dependiendo de su configuración, tipo promedio de transacciones, etc.). Uno que viene a la mente es InfoBright, pero a menudo son costosos.