2012-01-09 16 views
12

Heredo de un sistema cuando mi empresa compró otra empresa. Este sistema es una mezcla de LAMP y .NET.Migración del sistema defectuoso a nuestro sistema actual con toneladas de datos

  1. 1 servidor Windows asp.net funcionamiento que controla la validación de terceros usados ​​sólo para las API de servicio web y - (vamos a llamarlo WIN) servidores
  2. 8 lámpara (web, informes, cron, depósitos, etc ...) - (vamos a llamarlo NUEVO)

Nuestro entorno actual:

14 servidores LAMP (web, correo, depósitos, etc ...) - (vamos a llamarlo aCTUAL)

El ir La noticia es que el NUEVO código es bastante directo. Unas pocas millones de líneas de código (que la mayoría son apis, de terceros) y puedo convertirlo al sistema CURRENT. El NUEVO y ACTUAL usan ambos CentOs que harán que la transición sea fácil, excepto el servidor de Windows que no tengo idea de qué hacer ahora.

Ahora las malas noticias. El NUEVO esquema de la base de datos del sistema no es bueno en absoluto. No está normalizado y las consultas son lentas (consultas de bases de datos y el código también). Mi primera idea es rediseñarlos a una estructura más normalizada que coincida con el código CURRENT, pero no funciono. Las tablas del NUEVO sistema son gigantescas. El NUEVO sistema tiene 7 bases de datos, más de 10000 tablas, las tablas más pequeñas tienen más de 100k filas y algunas tablas tienen más de 500 millones de filas. Una de las bases de datos tiene la mayoría de las tablas con más de 25 millones de filas cada una.

¿Es seguro migrar o debería seguir funcionando? Si debo migrar, quiero saber cuál será la solución más segura para mí para migrar el sistema Windows y NUEVO a mi sistema CURRENT.

Respuesta

29

En primer lugar, moviendo los sistemas WIN + NUEVO en el actual sistema tomará tiempo. así que debes asegurarte de que cuando comiences a migrar/convertir todo, ya sabes a dónde vas. La migración puede no ser una tarea fácil y puede encontrarse con problemas que nunca pensó después de comenzar el proceso.

Su idea de migrar el NUEVO sistema tiene sus pros y sus contras y necesita asegurarse de que funcione sin problemas para obtener un producto bueno y confiable al final.

Pros:

  • único sistema para mantener: usted no desea mantener los sistemas 3;
  • un entorno de código/base de datos: PHP vs ASP.NET y MSSQL vs MySQL;
  • código/base de datos centralizada;
  • un estándar de codificación (código y base de datos);
  • guardar/venta equiments (se le migrar el código a sus 14 servidores, tal vez usted no necesita otro 9 (WIN + NUEVO), por lo que puede vender o mantenerlos durante los próximos proyectos)

contras:

  • mayor riesgo (accidente, incompatibilidad, función desconocida que hay que entender, etc ..);
  • más barato que la migración o el rediseño de todo
  • riesgo de fracaso es más baja que la migración (puesto que ya conoce tanto el sistema funciona)
  • planificación, control, ejecución, control de calidad: muy malo si uno de ellos falla;
  • caro: la migración puede ser costosa en tiempo y dinero;

Esta es una gran base de datos, cambiando/optimizando esto supondrá una importante inversión en horas de trabajo. Esto no es algo que pueda hacer fácilmente en pocas horas. Esto puede llevar semanas o meses para migrar datos al sistema CURRENT sin errores. Si puede, puede comenzar migrando características comunes o similitudes de ambos esquemas de bases de datos, como clientes o productos. De esta forma, importará datos que el sistema CURRENT puede ejecutar sin errores y también reconocerá su código. Los usuarios de su sistema CURRENT pueden comenzar inmediatamente a gestionar estos elementos/registros sin problema. A partir de nuevos o registros que su sistema actual no reconoce, puede simplemente rediseñar estas tablas y migrarlas al sistema CURRENT (luego actualice su código actual).

A partir de la migración de código, si el código del NUEVO sistema es lo suficientemente bueno y coincide con su estándar, puede conservarlo. Esto ahorrará tiempo en el desarrollo, solo asegúrese de actualizar las consultas y las conexiones de los servidores. Por otro lado, si es como el código de spaghetti, tendrá que entender lo que hace el código. Esto también puede requerir una inversión significativa en horas de trabajo. Puedo recomendar aquí estandarizar este y organizar su código de la misma manera que lo organiza en el CURRENT. Puede centralizar su código en una carpeta común usando una estructura común de archivos y carpetas. Puede poner todas sus bibliotecas comunes, terceros, etc. allí, de modo que cuando llame al código CURRENT y al código NEW, cargue la misma clase PHP. Esto facilitará las transiciones del sistema NUEVO al sistema ACTUAL. De esta forma, conoce todos sus archivos necesarios en el mismo lugar y es muy fácil de mantener. Especialmente si su código requiere archivos requeridos que requieren archivos. Si el código está alrededor de sus servidores, puede crear un NFS si le gusta esta idea.

Ahora, lo que puedo sugerir es comenzar con un Parallel Adoption. De esta forma, se asegura de que todos los sistemas funcionen correctamente y sean saludables. Luego, migre lentamente datos/código al sistema CURRENT hasta que todo se complete. Esto no será fácil y debe identificar qué parte de los sistemas NEW + WIN tiene que migrar primero. Mi recomendación será migrar el sistema WIN. Debido a que esto es independiente de los sistemas ACTUAL y NUEVO, siempre que muestre el mismo resultado, estará bien. Busque validación de fuente abierta o similar en PHP o, si no puede encontrar ninguna, compilación.De esta forma, este sistema WIN se puede migrar fácilmente a la estructura de su organización y a los estándares de codificación actuales. Realizar pruebas y garantías de calidad será fácil y puede completarlo muy rápidamente.

Una vez que se migra este WIN, primero debe identificar lo que necesita transferir al sistema CURRENT. Por ejemplo, si el sistema NUEVO y ACTUAL tiene "clientes", reúna toda la información del NUEVO sistema y muévalos al sistema ACTUAL utilizando un script (manual o con guiones). Luego, puede migrar elementos de clientes como productos, estado de cuenta o cualquier otro registro relacionado con estos clientes). Repita estos pasos hasta que se migren todos los datos. De esta forma, no tiene que volver a diseñar ninguna tabla ni cambiar ningún código del NUEVO sistema, todo se guarda en el sistema ACTUAL y todo funciona correctamente.

No recomendaré el big bang adoption para este caso.

2

La decisión de migrar no es realmente su decisión, sino más, usted es la decisión de los jefes.

Por el cómo, depende de la cantidad de datos que necesita hacer. Obviamente, recomendaría trabajar los datos de SQL a SQL utilizando declaraciones entre bases de datos, pero eso no siempre es factible.

La primera razón es que puede necesitar transformar datos realmente complejos en otra forma y no puede hacerlo usando SQL puro.

El segundo, sería que si codificar un script de transferencia en PHP o en cualquier otro idioma requeriría tanto esfuerzo como hacerlo en SQL puro, es mejor que lo haga en PHP para que cuando tenga algo que cambiar está seguro de que será posible y no se verá afectado por el hecho de que está en SQL y necesita recodificar todo.

En general, tiene que hacer un gran análisis para comprender todos los datos que está tratando y planificar su traslado. Con la cantidad de mesas y filas de las que está hablando, tiene un gran viaje por delante, creo que Tylenol será su mejor amigo.

Buena suerte

+1

bueno yo soy el jefe – aki

+0

Maldición, entonces acabas de conseguir una decisión aún más difícil de tomar;) –

+0

yup! Lo sé, es por eso que quería preguntar aquí, pero creo que a la gente no le gusta este tipo de preguntas ... – aki

Cuestiones relacionadas