c# - fields - mysql a mongodb

Razones a favor y en contra de pasar de SQL server a MongoDB

Question

Sé que esta es una gran pregunta y no es una respuesta afirmativa o negativa, pero desarrollamos aplicaciones web y estamos buscando utilizar MongoDB para nuestra solución de persistencia. Combinando MongoDB con NoRM para el almacenamiento de objetos.

Lo que quiero preguntar es ¿qué dificultades has experimentado al cambiar de SQL a mongo? ¿Cuándo Mongo simplemente no es la solución correcta y las ventajas de mongodb son suficientes para mover el desarrollo desde SQL?

Answer 1

En mi opinión, el formato de sus datos debe ser la principal preocupación al elegir un back-end de almacenamiento. ¿Tiene datos de naturaleza relacional? Si es así, ¿puede y es una buena idea modelar los datos en los documentos? El modelado de datos es tan importante en una base de datos documental como en una base de datos relacional, simplemente se hace de manera diferente. ¿Cuántos tipos de objetos tienes y cómo están relacionados? ¿Pueden los DBrefs en Mongodb hacer el truco o fallarán las claves externas tanto que será doloroso? ¿Cuáles son sus patrones de acceso para los datos? ¿Acabas de obtener datos de un tipo filtrados por un valor de campo, o tienes modos de búsqueda intrincados?

¿Necesita integridad transaccional ÁCIDA? ¿El dominio impone muchas restricciones sobre los datos? ¿Necesita el factor de escalabilidad de una base de datos documental o es simplemente algo "genial" tener?

¿Cuáles son sus requisitos de coherencia e integridad de datos? Algunas soluciones NoSQL y MongoDB en particular son bastante flexibles en la coherencia de escritura para obtener rendimiento. NoSQL no es un paisaje uniforme y otros productos, por ejemplo, CouchDB tiene otras características en este departamento. Algunos son sintonizables también.

Estas son todas las preguntas que deben incluirse en la opción de almacenamiento.

Algunas experiencias

• Hacer informes exhaustivos sobre los datos almacenados puede ser más difícil cuando se usa MongoDB o cualquier base de datos de documentos, y algunos casos de uso han estado combinando RDBMS y document-db para ese fin.
• (Muy) modelo de consulta diferente. MongoDB también difiere de otros documentos-dbs.
• Flexible para cambiar el formato / esquema de datos durante el desarrollo
• Territorio desconocido
• grado de madurez variable en controladores y marcos
• Rápido
• Herramientas de gestión y productos más simples (en muchos aspectos) (en comparación con muchos productos RDBMS)
• No más desajuste de impedancia. El almacenamiento se ajusta a los datos, no al revés.
• Menos fricción y acceso más directo a los datos.
• El dominio está más vinculado a la persistencia (dependiendo del "nivel" ORM de NoRM, de cuánto abstrae el backend. No he usado NoRM, así que no puedo responder eso).

Answer 2

He estado hurgando con esto hace unos días. Esto es lo que puedo decir al respecto:

PARA:

• No más declaraciones SQL
• Su base de datos se asemeja a sus clases, no al revés
• Su "esquema" es más flexible
• Escala bien
• Muy fácil comenzar con
• <opinión> Es genial </ opinion>

EN CONTRA:

• Actualmente estoy tratando de implementar un Proveedor de Membresía y Proveedor de Roles personalizado para mi aplicación mongo, pero de alguna manera mi clase de usuario de MemberShip tiene campos NULL cuando intento recuperarla de mongo.
• En algún lugar que he leído sobre el controlador C # es relativamente joven pero se está estabilizando, así que espera algunos cambios. (Aunque esto no me detendría)

Una cosa que noté es que falta en los tutoriales: inicialice sus listas dentro de su objeto, de lo contrario arrojará un error al intentar guardar (yourobj). Lo más seguro es escribir un constructor en su clase que se asegure de no tener ningún objeto NULL dentro de su objeto. De esta forma no obtendrás un error si olvidas algo.

Answer 3

Puede encontrar un par de ventajas y desventajas de usar una base de datos NoSQL (MongoDB incluido) en este Getting Start with NoSQL . Un resumen rápido sería: un modelo de datos diferente (piense si se necesita una asignación del modelo de objetos a "este nuevo modelo", ¿funcionará bien?), Un modelo de consulta diferente (las consultas de MongoDB son bastante capaces en comparación con otras) , no hay transacciones (aunque tienes algunas operaciones atómicas).

De todos modos, desde mi punto de vista, el cambio más importante es el modelo de datos y la forma en que está diseñando su aplicación con este nuevo enfoque.

Answer 4

contras

1. (la falta de / visión diferente en) la durabilidad (lea http://www.mikealrogers.com/2010/07/mongodb-performance-durability )
2. Sin transacciones
3. Sin restricciones
4. La agregación con MapReduce es lenta y necesita escribir código para algo como group-by
5. Informes es más difícil, el desarrollador define las relaciones, pero los analistas de negocios no pueden construir sus propias consultas, no pueden, por ejemplo, hacer un ''menos'' (''excepto'' en la jerga del servidor sql)

pros

1. puede agregar fácilmente nuevas ''columnas'' y ''tablas''
2. velocidad
3. sharding (aún beta)
4. el documento se ajusta más a un objeto que un conjunto de tablas relacionales, por lo que la asignación se vuelve más fácil
5. Amplía la mente

Answer 5

Su kilometraje puede variar, pero este es un gráfico rápido que armé para comparar la velocidad de actualización de varias "filas de tabla" (documento plano no jerárquico en MongoDB) con y sin índice para darnos una idea de cómo se escalaría nuestra aplicación.