Leyendo el libro de Tom Kyte "Expert Oracle Database Architecture, Segunda Edición", me pareció excelente el prefacio escrito por Ken Jacobs en el cual escribe sobre cómo una palabra usada en 1914 por Thomas J. Watson para transmitirles una idea a los trabajadores en IBM, no importando su puesto, teniendo cuidado en la toma de desiciones además de hacer el trabajo con inteligencia.
Jacobs hace énfasis sobre la "experiencia convencional" que existe en la comunidad Oracle sobre como optimizar para un mejor rendimiento o la mejor manera de usar varias características de Oracle. Esta experiencia que algunas veces se vuelve folclore o incluso mito y que tanto desarrolladores como administradores de bases de datos aplican ciegamente o van más allá pero sin razonamiento alguno.
Un ejemplo de lo anterior es la idea de "si uno es bueno, más -muchos más- son mejor". La idea es popular, pero no siempre cierta. La interfaz de arreglo de Oracle, por ejemplo, que permite a los desarrolladores insertar o extraer varios registros con una sola llamada reduciendo asi el número de mensajes de red entre la aplicación y la base de datos lo cual es bueno. Pero si lo analizas, hay un punto en el que el rendimiento decrece. Es mucho mejor transportar 100 registros a la vez que 1,000 ya que para este último caso el método ya no es eficiente, especialmente por requerimientos de memoria.
Otro ejemplo es cuando se enfoca en aspectos equivocados del diseño o configuración del sistema, en lugar de aquellos en los que se puede mejorar el rendimiento (o, si es el caso, confiabilidad, disponibilidad o seguridad). Considera la experiencia convencional de optimizar el sistema para maximizar el 'buffer hit ratio'. Para algunas aplicaciones, es verdad que maximizar la oportunidad de que el sistema encuentre los datos en memoria aumentará el rendimiento. Sin embargo, en la mayoría de sistemas lo mejor es enfocarse en los cuellos de botella (lo que en el argot de Oracle se conocen como "wait states"), en lugar de centrarse en indicadores específicos. Atacarlas desde el diseño asegurará que el sistema tenga un buen desempeño.
A veces, buenas prácticas que se basaban, en parte, en un grado de certeza ya no aplican cuando los hechos cambian. Considera el viejo adagio, "poner índices y datos en distintos tablespaces para un mejor rendimiento". Hay administradores de base de datos que defienden a capa y espada esta idea sin tomar en consideración cambios en la velocidad de los discos y su capacidad, o lo relacionado con cargas de trabajo. Al evaluar esta "regla", se debería pensar en el hecho de que Oracle carga en memoria los bloques de base de datos usados recientemente y con frecuencia (a menudo bloques que pertenecen a un índice), y en el hecho de que hace uso de estos bloques de manera secuencial, no simultánea, para cualquier petición. Esto implica que las operaciones de I/O tanto para índices como para datos deberían repartirse entre todos los usuarios simultáneos y repartirse en todos los discos de los que se pueda disponer. Puedes elegir separar índices y datos por razones administrativas o por preferencia personal, pero no por rendimiento. Lo importante de esto es basar las decisiones en hechos, bastantes hechos.
No importa que tan veloces sean nuestras computadoras o que tan sofisticada pueda llegar a ser la base de datos, e independientemente del poder de nuestras herramientas de programación, simplemente no hay sustituto para la inteligencia humana acompañada con una "disciplina pensante". Si bien es importante aprender las complejidades de las tecnologías que usamos en nuestras aplicaciones, es aún más importante saber como pensar en darles el uso apropiado.
El libro de Tom no solo enseña sobre características de Oracle y como usarlas, también refleja muchos de estos pensamientos sencillos:
Aunado a esto, yo agregaría además los consejos de Steven Feuerstein que publiqué hace unos posts atrás. Si bien es cierto que lo ideal siempre es tener el tiempo y el equipo para hacer todas las pruebas que se necesitan la realidad es que pocas veces se tienen, muchas veces quizá por la falta de tiempo muchos se quedan con la idea de que lo que vieron que a otros les funcionó también funcionará para ellos y posiblemente así sea, sin embargo, con tantas combinaciones en cuanto a Oracle como base de datos, sistemas operativos y hardware, se podría tomar como base ese conocimiento pero queda de uno el probar que efectivamente será la solución del problema.
Una vez que tienes como solucionar el problema es importante ver también las implicaciones hacia los demás ya que en lugar de solucionarlo podrías estarlo solo cambiando de lugar.
Jacobs hace énfasis sobre la "experiencia convencional" que existe en la comunidad Oracle sobre como optimizar para un mejor rendimiento o la mejor manera de usar varias características de Oracle. Esta experiencia que algunas veces se vuelve folclore o incluso mito y que tanto desarrolladores como administradores de bases de datos aplican ciegamente o van más allá pero sin razonamiento alguno.
Un ejemplo de lo anterior es la idea de "si uno es bueno, más -muchos más- son mejor". La idea es popular, pero no siempre cierta. La interfaz de arreglo de Oracle, por ejemplo, que permite a los desarrolladores insertar o extraer varios registros con una sola llamada reduciendo asi el número de mensajes de red entre la aplicación y la base de datos lo cual es bueno. Pero si lo analizas, hay un punto en el que el rendimiento decrece. Es mucho mejor transportar 100 registros a la vez que 1,000 ya que para este último caso el método ya no es eficiente, especialmente por requerimientos de memoria.
Otro ejemplo es cuando se enfoca en aspectos equivocados del diseño o configuración del sistema, en lugar de aquellos en los que se puede mejorar el rendimiento (o, si es el caso, confiabilidad, disponibilidad o seguridad). Considera la experiencia convencional de optimizar el sistema para maximizar el 'buffer hit ratio'. Para algunas aplicaciones, es verdad que maximizar la oportunidad de que el sistema encuentre los datos en memoria aumentará el rendimiento. Sin embargo, en la mayoría de sistemas lo mejor es enfocarse en los cuellos de botella (lo que en el argot de Oracle se conocen como "wait states"), en lugar de centrarse en indicadores específicos. Atacarlas desde el diseño asegurará que el sistema tenga un buen desempeño.
A veces, buenas prácticas que se basaban, en parte, en un grado de certeza ya no aplican cuando los hechos cambian. Considera el viejo adagio, "poner índices y datos en distintos tablespaces para un mejor rendimiento". Hay administradores de base de datos que defienden a capa y espada esta idea sin tomar en consideración cambios en la velocidad de los discos y su capacidad, o lo relacionado con cargas de trabajo. Al evaluar esta "regla", se debería pensar en el hecho de que Oracle carga en memoria los bloques de base de datos usados recientemente y con frecuencia (a menudo bloques que pertenecen a un índice), y en el hecho de que hace uso de estos bloques de manera secuencial, no simultánea, para cualquier petición. Esto implica que las operaciones de I/O tanto para índices como para datos deberían repartirse entre todos los usuarios simultáneos y repartirse en todos los discos de los que se pueda disponer. Puedes elegir separar índices y datos por razones administrativas o por preferencia personal, pero no por rendimiento. Lo importante de esto es basar las decisiones en hechos, bastantes hechos.
No importa que tan veloces sean nuestras computadoras o que tan sofisticada pueda llegar a ser la base de datos, e independientemente del poder de nuestras herramientas de programación, simplemente no hay sustituto para la inteligencia humana acompañada con una "disciplina pensante". Si bien es importante aprender las complejidades de las tecnologías que usamos en nuestras aplicaciones, es aún más importante saber como pensar en darles el uso apropiado.
El libro de Tom no solo enseña sobre características de Oracle y como usarlas, también refleja muchos de estos pensamientos sencillos:
- No creas en mitos. Razona por tí mismo.
- No te vayas con la experiencia convencional. ¡A menudo las cosas que todo mundo sabe simplemente están mal!
- Desconfia de los rumores u opiniones. Prueba las cosas tu mismo y fundamenta tus decisiones en ejemplos hechos.
- Divide el problema en preguntas simples y arma las respuestas a cada paso en una solución elegante y eficiente.
- No ejecutes cosas en tus programas cuando la base de datos las puede hacer mejor y más rápido.
- Investiga sobre el tema y se escéptico de políticas injustificadas en la empresa para estándares técnicos.
- Tómate el tiempo para PENSAR.
Aunado a esto, yo agregaría además los consejos de Steven Feuerstein que publiqué hace unos posts atrás. Si bien es cierto que lo ideal siempre es tener el tiempo y el equipo para hacer todas las pruebas que se necesitan la realidad es que pocas veces se tienen, muchas veces quizá por la falta de tiempo muchos se quedan con la idea de que lo que vieron que a otros les funcionó también funcionará para ellos y posiblemente así sea, sin embargo, con tantas combinaciones en cuanto a Oracle como base de datos, sistemas operativos y hardware, se podría tomar como base ese conocimiento pero queda de uno el probar que efectivamente será la solución del problema.
Una vez que tienes como solucionar el problema es importante ver también las implicaciones hacia los demás ya que en lugar de solucionarlo podrías estarlo solo cambiando de lugar.
Comments for this post
