Lo más común en las pequeñas aplicaciones que recién se lanzan es el uso de una solución LAMP, que comporta un servidor Linux, Apache, MySQL y PHP.
En cuanto crecen hay que re-escalarlas o volver a programarlas usando una infraestructura diferente. Por eso quería dar un repaso a las soluciones para hacer crecer una gran aplicación.
Primeramente hay que escalar lo que es el servidor de ficheros web, puesto que es prácticamente impensable ir modificando un fichero por cada servidor. Como primer recurso se suele poner en marcha un filer que aloja todos los ficheros y realiza las correspondientes copias de seguridad (incluidos ficheros de MySQL, PHP y contenido estático).
Más tarde se puede implementar una solución independiente de sincronización automática entre un servidor master que aloje los ficheros y un resto de slaves que sincronize con el principal.
Luego hay que escalar el sistema de base de datos, esto suele más “doloroso”. Aunque en la mayoría de aplicaciones existen ciertos puntos a favor…
En primer lugar, la mayoría de conexiones a la base de datos suelen ser consultas (y no actualizaciones ni inserciones). Las inserciones son una mínima parte de las instrucciones enviadas a la base de datos.
Aquí podemos emplear el esquema básico de MySQL de un servidor master y de luegos unos “slaves” o servidores esclavos que tendrán una replica exacta del contenido del master, con la pega de que no podremos hacer inserciones ahí.
Si se trata de mostrar una portada, listar unos datos o ver el perfil de un usuario, en la gran mayoría de los casos no es necesario realizar inserciones con lo que se puede mantener un sólo o una serie pequeña de masters donde se insertarán los datos y luego todo un “equipo” de servidores “slave” donde se realizarán el resto de consultas, es decir, las de selección.
Para los filers se puede usar NFS, y en el caso de preferir un almacenamiento local sincronizado se puede usar entonces un proceso de Rsync programado (Cron, claro).
Volviendo a MySQL, basta con darse una vuelta por la documentación donde lo dejan bastante claro, yo lo llevo implementando para pequeños downtimes del servidor de bases de datos, que por ahora tiende a ser 0.
Ya contaré más, que seguro que algo me he dejado…
Quien haya tenido un sitio web con muchas visitas funcionando con un SGDB / frontend MySQL o MSSQL (este último no tiene remedio), se habrá dado cuenta de que con una avalancha de visitas o con un flujo grande y constante de accesos, se producen cuellos de botella en el acceso de lectura a la base de datos.
Se destacan varios puntos en común: los accesos de escritura son casi inexistentes, y los accesos de lecturas se repiten de forma múltiple ofreciendo siempre la misma respuesta durante cierto tiempo, a falta de una actualización.
Una opción que queda por ver es la de usar un servidor principal donde se realizarán las escrituras y luego una serie de servidores esclavos que vienen a ser replicas de la página web.
De ésta forma tenemos que ir escalando los servidores web y los servidores de bases de datos al mismo tiempo, puesto que si no se crearía un cuello de botella (más visitas = más conexiones a la base de datos = todo al garete).
Mas información y descarga después del salto.
Llevo trabajando (mentira, casi no me tomó tiempo) en un motor de almacenamiento Fulltext compatible con MySQL. De esta forma, por medio de fragmentos de archivos crea un índice.
En este caso podríamos usarlo de dos formas: realizando una indexación completa de MySQL o indexando fragmentos de forma independiente. En el caso de usar indexaciones independientes, es necesario asegurarse de la consistencia del índice de forma externa, o directamente (al menos, de forma de periodica) regenerar el índice desde una fuente de datos.
(more…)