En las discusiones sobre las bases de datos NoSQL vs SQL, a veces escucho que las empresas prefieren usar bases de datos NoSQL sin esquema porque es problemático migrar el esquema a una nueva versión. Pero, ¿es realmente un gran problema al hacer actualizaciones? ¿Las bases de datos relacionales son malas para tales operaciones?
Leí esta publicación en el blog de MongoDB: ¿Por qué Schemaless?
El hecho de que su base de datos NoSql no tenga un esquema en un sentido tradicional no significa que no haya un esquema lógico con el que deba lidiar a medida que cambia. En el caso de una aplicación típica que usa MongoDb, lo más probable es que su código espere que ciertos campos del objeto json se comporten de ciertas maneras. Si cambia el comportamiento, se deduce que quizás desee actualizar los datos ya existentes en la base de datos. Ahora, con el RDBMS tradicional, este era un problema ampliamente resuelto: solo tenía que ALTERAR las tablas subyacentes. Pero con estas nuevas bases de datos NoSQL, usted tiene una decisión: ¿escribe un script para combinar y actualizar todos sus objetos? ¿O agrega código para convertir entre versiones sobre la marcha? Si es así, ¿cuánto tiempo soporta objetos v1? ¿Siempre? Hasta v3?
Agregaré que el ejemplo utilizado en la publicación del blog de MongoDb es un poco simplista y un caso muy fácil de manejar si tienes un proceso de actualización decente, sin importar cuál sea el RDBMS; agregar un campo rara vez duele. Es cuando decides dividir tu Namecampo FirstNamey LastNameque las cosas se ponen emocionantes.
Puede ser.
Algunas organizaciones están, bueno, desorganizadas, y hacen un muy mal trabajo de migración de esquemas.
"Fin de semana de migración". Detén los servidores. Haga una copia de seguridad y exporte todos los datos. Construya el nuevo esquema (a menudo modificando el esquema existente). Vuelva a cargar los datos o intente reestructurar en su lugar.
"Ajustes continuos". Modifique las tablas en la medida permitida por SQL. Sin seguir la secuencia de ALTER's realizada. Sin forma de volver a una versión de esquema anterior. Cuando sea necesario, cree nuevas tablas a partir de las tablas existentes, con la esperanza de ajustar todas las aplicaciones para usar las nuevas tablas. Pero, al carecer de un buen control de calidad, dejar las viejas tablas en su lugar "por si acaso".
"Pánico completo". Simplemente evite modificaciones de esquema. Haz un gran mal olor. Reclama que el riesgo es demasiado alto. Bloquee todos los esfuerzos en esta dirección. Tome el esquema como rehén hasta que se vea obligado a adoptar un enfoque más sensato.
Cualquier esquema es un dolor para migrar.
El mayor problema no es técnico.
Es semántico.
Una razón principal para un cambio de esquema es que el esquema anterior no coincide muy bien con el dominio del problema. Como la semántica ha cambiado, la base de datos (y las aplicaciones) deben cambiar. A veces, estos son cambios profundos que requieren repensar la forma en que las aplicaciones funcionan con los datos.
Revisar la semántica de la base de datos puede ser muy difícil.
Lo que la gente hace en lugar de los cambios de esquema es usar mal el esquema físico. Comienzan a cargar datos incorrectos en los campos existentes porque pueden hacerlo. Un campo de "comentario" de repente comienza a tener una pieza importante de información de gestión del cliente seguido de "//" seguido del comentario real. Eso crece para tener que tener datos "campo 1 - campo 2 // comentario". Los usuarios tienen una hoja de cálculo que extrae estos datos adicionales del campo de comentarios porque el software de aplicación "real" tenía un esquema difícil de cambiar que TI se negó a cambiar.
fuente
Actualizamos bases de datos de producción agregando tablas y columnas (anulables) sin problemas. Las versiones anteriores de la aplicación funcionan bien con la base de datos actualizada, simplemente no hacen referencia a las cosas nuevas. Evitamos eliminar tablas o columnas, o cambiar la forma en que se almacenan los datos existentes, aunque cuando sea necesario producimos scripts de conversión apropiados. Ya sea que su base de datos tenga un esquema seguro de tipo declarado o no, los cambios en la estructura de datos requieren conversión de datos y actualizaciones de la aplicación para interactuar con la nueva estructura.
fuente
Depende.
Primero, si tiene una base de datos realmente grande que abarca múltiples máquinas, entonces todo (no solo la actualización de la base de datos) será doloroso. (No importa cuánto haya planeado con anticipación).
En segundo lugar, actualizar una base de datos NO es solo una cuestión de base de datos, sino que también depende del sistema más grande del que forma parte la base de datos. Esto también incluye la implementación de la base de datos (muchos servidores de bases de datos, múltiples centros de datos, configuraciones maestro-esclavo, etc.)
El dolor puede aliviarse mediante la arquitectura de los componentes del sistema de modo que todos tengan algún tipo de "conocimiento" del evento de cambio de esquema de DB. Esto significa que todo el sistema debe ser tolerante a los cambios de esquema y puede responder a él de una manera "sensata".
Puede consultar una utilidad desarrollada por Facebook para abordar las actualizaciones del esquema MySQL.
Además, existen prácticas recomendadas estándar como convertirlo en maestro de solo lectura, realizar cambios en esclavos o en copias de desarrollo, etc.
En cualquier caso, es imprescindible tener una copia de seguridad completa y un amplio conjunto de pruebas . Solo entonces, puede hacer cualquier cambio con confianza y seguridad.
fuente