Esta es la respuesta más correcta que te podemos compartir, pero obsérvala pausadamente y analiza si se adapta a tu trabajo.
Solución:
Existen algunas herramientas para ayudar con la migración, pero al final, MySQL es una base de datos relacional que tiene una estructura completamente diferente a las bases de datos noSQL.
Al final, casi siempre tendrá que realizar estos cuatro pasos indicados en este artículo (se refiere a mongoDB, y no especificó, pero se aplica a cualquiera):
1. Conozca MongoDB. Descárgalo, lee los tutoriales, prueba algunos proyectos de juguetes.
2. Piense en cómo representar su modelo en su almacén de documentos.
3. Migre los datos de la base de datos a MongoDB, probablemente simplemente escribiendo un montón de
SELECT * FROMdeclaraciones contra la base de datos y luego cargar los datos en su modelo MongoDB usando el lenguaje de su elección.4. Reescriba el código de su aplicación para consultar MongoDB a través de instrucciones como insert() o find().
Para simplificar un poco las cosas, una base de datos Oracle tendría un dominio completo sobre lo que se almacena en la base de datos. Oracle o cualquier RDBMS harían esto manteniendo relaciones entre fragmentos de datos almacenados en tablas.
Una base de datos basada en documentos, por otro lado, almacena principalmente la cómo se consumen los datos en el sistema. Lo logra utilizando los pares clave-valor, con keys jugando cierta variable fundamental dentro.
Dependería de la complejidad del sistema que se está migrando, de los volúmenes, de la funcionalidad que se va a ofrecer, etc. Aunque hay varias formas de migrar de un RDBMS a una base de datos basada en json, un enfoque estándar implicaría la construcción de vistas en la base de datos SQL existente y migrando por etapas.
Por supuesto, el proceso fundamental en tal migración es comience con el rediseño del esquema como primer paso. En una estructura de documento como Mongo JSON o BSON, la mayoría de las relaciones entre padres e hijos se pueden acomodar en una sola estructura (o documento). Por ejemplo, Person_ID, Car_Ownership_ID se pueden combinar para generar un solo documento json que enumera todos los propietarios de un automóvil.
Un proceso de diseño de esquema de sonido mantendría ciertos objetivos bajo consideración, al mismo tiempo que desnormalizaría la base de datos completamente normalizada en el RDBMS. como un buen segundo paso, la mayoría de los JOIN deberán combinarse en colecciones entrelazadas para un acceso más fácil con la excepción de ciertas uniones externas.
Una vez que el esquema está listo, se puede usar un proceso ETL o un script sustitutivo para extraer, transformar y cargar el esquema más nuevo con una réplica de datos en el RDBMS.
Recuerda algo, que te permitimos reseñar si te ayudó.