Persistencia
Para AOL Server todos los
balcones están en memoria caché
| | | |  | | | •••
AOL Server corre como
proceso UNIX único.
Puede servir miles de
páginas sin que el
servidor tenga que
arrancar programas
nuevos
| | | | | NUESTRA TECNOLOGÍA
DE TÉCNICO A TÉCNICO
:::: AOL Server
Históricamente los programadores con talento se han mantenido ignorantes de las capacidades de los sistemas de gestión de bases de datos. Incluso cuando una aplicación parece ser un objetivo natural para un sistema como PostgreSQL, un programador resolverá el asunto con una base de datos de texto plano. Usualmente funcionará bien para el problema, tal como se concibió originalmente, pero las consecuencias a largo plazo de solución tan apresurada serán dolorosas. AOL Server fue diseñado desde el principio para conectarse a los gestores de datos más populares: los sistemas relacionales de bases de datos (RDBMS). En el mundo CGI el servidor web arranca un nuevo programa cada vez que llega una nueva petición desde un navegador. El guión CGI abre entonces una conexión al RDBMS, una conexión que generalmente requiere que UNIX empiece otro programa (fork). Si recibe 20 peticiones por segundo bajo este esquema, su ordenador está lanzando 40 nuevos programas cada segundo.
:::: Arquitectura de conexiones reservadas
AOL Server, por el contrario, corre como un proceso UNIX único. Puede servir las 20 páginas por segundo sin que el servidor tenga que arrancar programas nuevos. Si estas páginas necesitan conectarse a PostgreSQL, simplemente solicitan a AOL Server que les deja usar las conexiones abiertas de la reserva (pool) configurable. Reservar conexiones a la base de datos es una consecuencia de la arquitectura multihebra de AOL Server y una habilidad de primer nivel.
Con un servidor de reserva de procesos como Apache nada nos impide, asimismo, enlazarnos con la bibliotecas C de PostgreSQL. El servidor Apache puede funcionar también como un cliente PostgreSQL. ¿Cuál es, entonces, la diferencia principal?. Veamos. Existen sitios, muchos, que pueden servir, por ejemplo 700.000 peticiones por día, alrededor de 120 usuarios simultáneos. Pues bien, con Apache se necesitarían 120 procesos Apache, cada uno de los cuales abriría dos conexiones a PostgreSQL: total 360 procesos en total y con AOL Server, manteniendo abiertas ocho conexiones a PostgreSQL, abriríamos nueve procesos UNIX (1 AOL Server, 8 PostgreSQL).
:::: Cachear ficheros
Otro dividendo de la arquitectura de proceso único de AOL Server es que podemos hacer 'caché' de consultas o datos en la memoria virtual de AOL Server. Por ejemplo, consideremos el reloj de Salud Personal de Bill Gates. Recoge hasta dos peticiones por segundo en momentos punta. Se apoya en la invocación de procesos CGI de servidores remotos. Es fácil imaginar que al Sr. Gates no le guste ser bombardeado con peticiones constantes. La solución ideal para su reloj personal sería 'cachear' la página en la memoria virtual de AOL Server. Es algo, es cierto, que podríamos hacer con un servidor de reserva de procesos como Apache pero acabaríamos gradualmente con 120 copias distintas de los mismos datos.
:::: Programación de AOL Server
Existen tres formas de programar AOL Server:
•
•
•
| Código C corriendo dentro de AOL Server (el API C)
Guiones CGI corriendo fuera de AOL Server
Guiones Tcl corriendo dentro de AOL Server
| | | No hablaremos de los dos primeros métodos. El código C corriendo en un servidor es demasiado peligroso para el desarrollo diario de páginas. El API C es útil para gente que construye módulos y drivers de base de datos. Tampoco hablaremos de CGI, pues su uso es idéntico al de cualquier otro servidor web. Por las razones mencionadas anteriormente, la mayoría de los programadores de AOL Server utilizamos el API Tcl.
Los programadores web inexpertos se sienten confundidos, a veces, por la simplicidad de Tcl, pensando que están siendo limitados en el desarrollo de los sitios web. No perciben que ninguno de los desafíos técnicos recae sobre la creación del código de una página. El desafío consiste en darse cuenta que el servicio web es en sí mismo un objeto y el objeto tiene un estado, habitualmente almacenado en una base de datos relacional. El objeto tiene métodos (los URLs) y argumentos para esos métodos (la entrada de los formularios que apuntan al URL). Los desafíos de ingeniería del desarrollo web son: •
•
•
| Crear el modelo de datos correcto para el estado del objeto
Crear y mantener la estructura correcta de URLs
Definir la semántica de cada URLs
| | | Tcl es bueno manejando cadenas, lo que está muy bien, ya que el único tipo que podemos leer en PostgreSQL es una cadena y el único tipo de datos que podemos leer o escribir a una conexión web es una cadena. Tcl es extremadamente seguro. Nunca hemos encontrado un error en el intérprete Tcl o, atención, hemos bloqueado el servidor AOL Server con un error de programación. Los que manejan servidores grandes y no utilizan esta tecnología sabrán de que hablamos.
El intérprete de Tcl, es una de sus propiedades, está disponible en tiempo de ejecución lo que hace sencillo añadir al lenguaje utilidades como la del cacheo ya mencionadas y crear programas que creen otros programas y almacenarlos en la base de datos para ejecutarlos cuando sirvamos páginas (persistencia).
:::: PostgreSQL
Decir simplemente que nuestra base de datos dispone de los mismos atributos que Oracle, DB2, Informix o SQL Server. Su rendimiento ha sido muy contrastado en los últimos años en sistemas de producción muy exigentes y sofisticados y como toda base de datos de alto nivel, cumple con el estándar ACID: •
•
•
| Atomicidad
Consistencia
Aislamiento
Durabilidad | | | No olvidar que PostgreSQL tiene, además, características más avanzadas que cualquier sistema comercial RDBMS y para nuestra alegría, lo que es muy importante y nada casual, podemos ejecutar código Tcl dentro del servidor. La concurrencia es uno de los puntos fuertes de PostgreSQL con relación a sus competidores. En PostgrSQL los que leen nunca tienen que esperar por los que escriben y viceversa. Imagine que un editor en un sitio grande comienza una consulta a las 12:00 haciendo un resumen de uso por usuario. PostgreSQL podría necesitar una hora para recorrer los 200 Gb de datos de control y que tenemos un sistema multiCPU, donde los discos giran sin parar y que utilizamos un CPU completa hasta las 13:30. Además suponga que el usuario #356712 viene a las 12:30 y cambia su correo-e, actualizando una fila en la tabla de usuarios. Si el sistema de control llega a esta fila a las 12:45, PostgreSQL se dará cuenta que la fila ha sido modificada después que comenzara la consulta. Bajo la 'I' de ACID, a PostgreSQL se le exige que aísle al editor de la actualización del usuario. PostgreSQL lo resuelve utilizando el segmento 'rollback' (histórico) y generando datos de la fila del usuario #356712 como si fueran las 12:00, cuando arrancó la consulta.
¿Cómo se comporta otro RDBMS, por ejemplo, Microsoft SQL Server, ante una consulta parecida?. La mayoría de los gestores de bases de datos utilizan el sistema de 'semáforos' para el control de concurrencia. Cuando lees bloqueas la información que vas a leer y nadie puede escribir hasta que la liberas. Cuando escribes haces lo mismo y nadie puede leer o escribir hasta que lo liberas. El hilo (thread) en el servidor web permanecerá bloqueado esperando a que se libere el bloqueo de lectura. ¿Cuánto habrá que esperar?. Una hora completa con un icono de Explorer dando vueltas, ¿les suena?
La razón por la que los RDBMS parecen ser tan competitivos viene dada porque en una prueba de procesamiento de transacciones, todas las transacciones son muy breves y pueden ser gestionadas en menos de un segundo. La realidad es otra.
Otra cosa importante con PostgreSQL es que podemos ejecutar programas de procedimiento dentro del servidor RDBMS. Suponga que queremos ver todas las filas en una tabla de 1.000 millones de filas que cumplan una expresión regular determinada. El problema se eleva a dimensiones terroríficas cuando nos damos cuenta de que no existe un operador REGEXP en el estándar SQL. ¡Tendríamos que 'tirar' de 1.000 millones de filas a través de la red dentro de AOL Server Tcl y descartar aquellos que no cumplan el REGEXP de Tcl!
Si utilizamos PostgreSQL, no hay nada que temer ya que incluye soporte interno de Java y podemos escribir un pequeño programa para buscar en la base de datos local, sin mover datos a través de la red. Decir por último que PostgreSQL soporta además de Tcl y Java, Perl, Python, etc.
| | | |
| | |
| | TECNOLOGÍAS ABIERTAS | | | Linux
| | | AOL Server
| | | PostgreSQL
| | | Tcl multihebra, xml, html, CSS. JavaScripts | | | Kernel Institucional | | | | | Linux: sistema operativo en código fuente libre.
AOL Server: servidor web abierto de alto rendimiento. PostgreSQL: basede datos multiproceso en código fuente libre.
Tcl: lenguaje de programación multihebra.
HTML, XML, CSS, JavaScripts: lenguajes de marcas
Kernel Institucional: núcleo de integración
OpenAcs
| | CÓDIGO ABIERTO | | | | | Soluciones de soguar que se suministran con el código fuente (lenguaje humano y compresible). El código cerrado sujeto a derechos de propiedad se suministra cerrado, en lenguaje binario, ceros y unos, sólo legible por las máquinas. El código abierto permite a la comunidad de desarrolladores hacer mejoras, incorporar soluciones y ensanchar la base social de programadores y desarrolladores en beneficio de su calidad y difusión. | | | | | | | | | | |
| |
