Migrando de SQL Server a MySQL

Desde hace un par de meses, en la empresa para la que laboro actualmente, se tomo la decisión de migrar la plataforma de base de datos, de SQL Server 2000 y 2005, a MySQL Server 5.4. Se hicieron todas las pruebas pertinentes, y con los escenarios de prueba, estábamos seguros del rendimiento de ambas bases de datos, y el migrar no iba a cambiar el tiempo de respuesta de nuestras aplicaciones hacia nuestros usuarios y/o clientes. Y es que en verdad el rendimiento y desempeño de MySQL, en estos momentos, no tiene nada que pedir, y en ciertos casos es mejor a SQL Server, si lo vemos desde el punto de vista costo beneficio por transacción. No habíamos encontrado nada que justificase el tener que pagar por una licencia de SQL Server 2008 para todas nuestras aplicaciones existentes, ni para las nuevas que se están desarrollando, en etapas de pruebas o en plena etapa de implementación y de settling (asentamiento).

Aquí es donde nos dimos cuenta, que el modelo del negocio para cual la base de datos, va a realizar su tarea, tiene mucho que ver a la hora de tomar una decisión de cual usar. El norteamericano estadounidense, es muy frio y calculador al hora de tomas las decisiones de negocio, lo que es simplemente, y se toma lo que es mejor para el momento del negocio, empresa y/o proyecto, nunca dejan que sus preferencias personales interfieran en las decisiones que toman para la empresa o compañía para la que trabajan o representan.

Cuando empezamos la pruebas utilizando espejos de la bases de datos reales, la diferencia de desempeño tampoco fue significativa, todo apuntaba a MySQL nuevamente. Después de un par de semanas de pruebas, de apuntar aplicaciones desarrolladas en PHP, tanto en symphony, como en Zend framework, hasta nuestra solución empresarial de soporte y modelo de negocio, redmine, todo estaba listo. Nuestro mayor obstáculo, pensamos, iba a ser cuando el par de aplicaciones que tenemos hechos en Entity Framework de Microsoft, que ahora juegan un rol muy importante en las actividades diarias de cierto departamento, al grado que la aplicación por si misma, hace el trabajo de lo que hacían 3 personas en una jornada laboral normal. El entity framework utilizando el ultimo conector disponible de MySQL para .NET, funciono simplemente increíble, ya no había ningún obstáculo para las demás pruebas. Todo iba bien, hasta que el modelo de negocio nos jugo una increíble situación, que no habíamos contemplado. Tengo la fortuna de labora para una empresa que procesa y administra la información de healthcare a cualquier empresa que no tenga un departamento de recursos humanos con la gente o el tiempo para poder hacerlo. Esto, aunado a que el sistema de salud de Estados Unidos, es muy complicado y puede variar, no solo de estado o ciudad, si no de un proveedor, a otro, o del tipo de plan que se le este ofreciendo a los trabajadores (HRA,HDP,FSA,DCA,HSA).

Debido a la naturaleza de nuestro negocio, mucha de la información que procesamos y administramos son feeds (archivos a procesar) que obtenemos de los carriers y brokers (empresas y encargados de vender y/o administrar los planes de salud de empresa y/o individuos). Esto se hace a través de procesos de EDI, que corren casi cada hora, los 7 días de la semana. Esto hace tener que procesar mucha información en cascada (bulk) y es donde los stored procedures de SQL Server tienen un papel muy importante. Ahí es donde vino la diferencia entre las dos bases de datos. Cuando empezamos a migrar los SP, a MySQL, aun que estos fueron desarrollados usando SQL ANSI, pensando en poder mover la información y las reglas de negocio que tuviese, a cualquier plataforma, sin tener que reinventar los mismos. Bueno, la conclusión que sacamos después de las pruebas, es que en optimizador de queries de SQL Server, y el motor que se encarga del plan de ejecución del mismo, es mucho mejor que el de MySQL, después de todas las demás pruebas, este hecho, muy importante para nuestro modelo de negocio, no cambio nuestra decisión inicial de migrar todo a SQL Server, pero si pudimos ver, hasta hoy, en que es muy bueno MySQL, y que es lo que le falta por mejorar.

Todos los detalles de rendimiento en donde SQL Server superaba a MySQL tenían que ver con el optimizador de consultas y el generador del plan de ejecución del mismo, es infinitamente superior el de SQL Server a MySQL. Esto, sin embargo, provoca que a la hora de escribir consultas, no prestes información en detalles tan básicos, como que todos los campos incluidos en un join, deben de tener un índice asociado a ellos. Lo que en un principio fue un set back para nosotros, acabo siendo un proyecto de optimización de consultas y de stored procedures, que desemboco en el mejoramiento del desempeño de todas nuestras aplicaciones.

Según nuestras conclusiones, SQL Server deja que te enfoques mas en el mantenimiento y administración de los datos, ya que el desempeño, debido a su optimizador, generalmente lo va a optimizar de una manera eficiente, ahora, si quieres saber que tan bueno eres escribiendo consultas y stored procedures, usando SQL ANSI, y dependiendo de tus habilidades y mejores prácticas, sin tener que pagar una exhorbitando cantidad de dinero por una licencia , usa MySQL, eso, sin mencionar el costo beneficio por transacción que de entrada ya tienes con él.

Notas relacionadas :

You can leave a response, or trackback from your own site.

Deje una respuesta

Webdesign