Postgres es mundialmente conocida como una excelente base de datos de código abierto, con gran madurez y unas características que permiten a las organizaciones escalar y lograr una alta disponibilidad. Hemos visto a muchas empresas despuntar con Postgres. A lo largo de estos años, también hemos visto errores que pueden ralentizar y afectar al rendimiento de PostgreSQL o incluso hacer descarrilar todos los esfuerzos invertidos.
En este post enumeramos los errores más comunes del uso de PostgreSQL, junto con algunas recomendaciones a evitar.
Error nº6 : no testear adecuadamente antes de migrar
Este es un error que realmente nadie desea cometer, ya que puede causar problemas imprevistos y tiempo de inactividad. Antes de migrar las bases de datos de producción de un tipo a otro, asegúrate de realizar una prueba en un entorno de no- productivo que refleje de cerca el entorno final o el de producción. No importa que estés migrando de Oracle a PostgreSQL o migrando de MySQL a PostgreSQL; cada vez que realices la migración, necesitas hacer una prueba antes. Asegúrate de probar sus funciones plsql para comprobar que se transfieran correctamente de la base de datos existente a la nueva. Una vez que se haya probado la migración en un entorno de no-productivo y se hayan resuelto los problemas, se puede pasar al entorno de producción con más confianza y seguridad.
Error nº5: saltarse el manual
Postgres tiene una excelente documentación, que se puede encontrar aquí. La sección Getting Started puede ser de gran ayuda para comanzar a navegar por el material de PostgreSQL. Así mismo se puede navegar por el índice en busca de otros apartados de interés como puede ser el SQL Syntax, Backup and Restore o High Availability Setup. Los documentos son bastante completos y están bien organizados. Otra opción es la documentación EDB PostgreSQL en sus tutoriales.
Error nº4: no compartir información
Suele ocurrir que el experto en Postgres de la empresa sabe configurar e implementar Postgres sobre una infraestructura de OpenStack solution o PostgreSQL sobre Kubernetes. A menudo, su trabajo es excelente, pero un día esa persona decide abandonar la empresa, y en ocasiones es posible que deje algún documento wiki como back up de su trabajo, pero en otras nadie sabe nada acerca de esa solución.
La mejor solución para que esto no ocurra es que el equipo de devOps y los DBA se impliquen por igual en el proceso. Al menos dos personas deben implementar la arquitectura para que nadie sea insustituible (¡y todos pueden irse de vacaciones de vez en cuando!). Las sesiones de capacitación pueden ser muy útiles para lograr que todo un equipo de personas comprenda las mejores prácticas de Postgres y comprenda el objetivo de la transición a Postgres. Aprendimos desde el principio que un servicio de implementación exitoso debería incluir una persona para implementar la solución deseada y otra para capacitar al equipo y administrar el proceso y cualquier pregunta durante el mismo. Tanto el Servicio de Implementación de EnterpriseDB como el de Hopla! Software siempre tienen dos consultores de Postgres trabajando en un mismo proyecto.
Error nº 3: Migrar las bases de datos más difíciles primero
Cuando estamos aprendiendo a nadar, no se nos ocurre ponernos a bucear directamente, ¿verdad? Eso es precisamente lo que hacen muchas empresas al migrar sus bases de datos a Postgres. Tanto desde EnterpriseDB como desde Hopla!, principal partner en España, se ha ayudado a muchas empresas que migran de Oracle a Postgres.
A menudo, la elección de una base de datos es aleatoria y puede estar basada en el conocimiento de los empleados o su tamaño; pero esto puede ser un error a medio plazo. La elección de la misma debe realizarse basándose en múltiples factores, entre los que se incluyen los anteriores y se añaden otros de mayor peso como el uso que se le va a dar, las arquitecturas que se van a desplegar o la infraestructura que van a tener.
Para evitar este error, la herramienta Portal de Migración de EnterpriseDB evalúa la compatibilidad de una base de datos existentes con Postgres. Una vez que se tenga idea de cuáles de las bases de datos son más y menos compatibles con Postgres, es recomendable comenzar con la que parezca más sencilla. Se adquirirá experiencia y soltura, y eso ayudará para cuando llegue el momento de gestionar los casos más difíciles.
Error nº 2: No obtener ayuda
Muy a menudo vemos que las empresas luchan por implementar Postgres porque simplemente no tienen suficiente experiencia de esta tecnología dentro de su empresa. En ocasiones tienen que hacer una autoformación tediosa para descubrir cómo es la tecnología y cuáles son las mejores prácticas para Postgres. Estos son algunos de los problemas que se se han ido viendo a lo largo de estos años:
- Los diseños de arquitectura pueden ser subóptimos o inexistentes.
- Las bases de datos de Postgres no tienen suficientes recursos. La memoria de asignación insuficiente es un error común. Los valores predeterminados en Postgres son los valores lowest-barrier-to-entry y deben activarse para los sistemas de producción.
La solución a esto es fácil; si no se tiene al menos un par de personas bien formadas en Postgres que estén disponibles, es mejor buscar ayuda de expertos y profesionales de PostgreSQL. Ayudará a acelerar los procesos y a evitar errores costosos.
Error nº 1: no convertirlo en una prioridad
Al igual que muchas empresas quieren mejorar su infraestructura, a veces se «asigna» una migración a Postgres que nunca se llega a ejecutar. Es entendible que se requieran nuevas capacidades por parte de los clientes, y que las consultoras deseen ofrecer nuevos productos y características.
Por otro lado, Postgres puede ayudar a lograr numerosos beneficios, como:
- Ahorro de costes: los gastos para administrar bases de datos Postgres son 10 veces menores que lo que cuestan otras.
- Ahorro de tiempo: a medida que las bases de datos maduran, tardan cada vez más en mantenerse. Las empresas deben preguntarse: ¿cuánto tiempo dedica mi equipo de operaciones/técnicos a mantener bases de datos antiguas? Dos semanas invertidas ahora en la implantación de Postgres puede ahorrar dos meses de esfuerzo en un año.
- Estabilidad: Postgres posee una madurez y unas fuertes características que la convierten en una opción ideal para muchas empresas. Los conjuntos de herramientas ayudan a obtener réplicas de la base de datos, capacidades para un back-up, mecanismos de conmutación por error y administración, a la par con cualquier base de datos, y que superan con creces algunas otras. El marco de código abierto se ha probado y sus actualizaciones se incluyen en cada nueva versión de EDB Advanced Server, en caso de que se necesiten recursos adicionales como la compatibilidad con Oracle o más mejoras de seguridad.
- Libérate del vendor Lock-in: La falta de priorización (real) es un problema difícil de resolver, pero no insuperable. Primero, hay que pensar en los objetivos de la empresa. ¿Está centrada en el usuario por encima de todo? Postgres puede disminuir los tiempos de migración, ayudar a garantizar la integridad de los datos, minimizar al mínimo los errores «Algo salió mal» y minimizar el tiempo de inactividad. ¿Está la empresa más centrada en el ahorro de tiempo y la eficiencia? ¿Podría migrar dos o más tipos de bases de datos a Postgres y reducir la cantidad de tipos de bases de datos que usa? ¿O tal vez tiene una base de datos, o dos, que requieren mucho tiempo para mantener?
Conclusión
Con todos los supuestos inconvenientes a los que nos podemos enfrentar a la hora de migrar a Postgres o comenzar una nueva base de datos, es normal tener dudas al principio, pero Postgres es una de las bases de datos más utilizadas del mundo y hay muchos recursos que pueden ser de utilidad. El servicio Quick Deploy de EBD es muy asequible y puede ayudar a las empresas a ejecutar una base de datos en producción con dos recursos en espera, utilizando las mejores prácticas.
Acceso al contenido original
