{"id":9,"date":"2009-08-23T15:02:00","date_gmt":"2009-08-23T13:02:00","guid":{"rendered":"http:\/\/beta.expertosenti.com\/2009\/08\/%c2%bfdonde-guardo-los-contenidos-generados-por-los-usuarios\/"},"modified":"2017-04-24T16:48:51","modified_gmt":"2017-04-24T14:48:51","slug":"donde-guardo-los-contenidos-generados-por-los-usuarios","status":"publish","type":"post","link":"https:\/\/www.xpnti.net\/es\/donde-guardo-los-contenidos-generados-por-los-usuarios\/","title":{"rendered":"\u00bfD\u00f3nde guardo los contenidos generados por los usuarios?"},"content":{"rendered":"

El otro d\u00eda estaba discutiendo con un cliente del sector del Social Media (mucho Web 2.0) sobre d\u00f3nde era mejor guardar los contenidos que suban los usuarios, si en disco, en base de datos o en el cloud (Amazon S3<\/a>, Nirvanix<\/a>, Rackspace Cloud Files<\/a>, etc…).
No hay una respuesta de cu\u00e1l es mejor o pero en cualquier caso, pero si restringimos la casu\u00edstica a un site con contenido generado por usuario (ugc o user-generated content) y con m\u00e1s de un servidor que sirva nuestro contenido (ya sea por rendimiento o por disponibilidad) tenemos un perdedor, guardarlo directamente a disco. \u00bfY por qu\u00e9?<\/p>\n

    \n
  1. Si tenemos m\u00e1s de un nodo nos debemos asegurar que todos los nodos puedan ver el mismo contenido. Sino, cuando un usuario acabe de actualizar su foto del perfil, sus amigos ver\u00e1n un error 404 de fichero no encontrado, excepto si han ido a parar al mismo servidor.<\/li>\n
  2. Si ponemos un sistema de replicaci\u00f3n multimaster (rsyncs cruzados, por ejemplo) podemos tener colisiones de nombres (dos usuarios han subido el fichero foto.jpg en nodos diferentes y el rsync nos lo ha sobrescrito) o tener problemas puntuales que afectaran a los usuarios dando mala imagen,desde que se sube un fichero hasta que est\u00e1 replicado (cada X minutos) estaremos entregando errores 404<\/li>\n
  3. Pues pongamos un almacenamiento compartido,por ejemplo NFS<\/a>, aparte de los problemas de escalabilidad en entornos con mucha escritura (es bastante mejorable la gesti\u00f3n de bloqueos en NFS), mejor que desambiguemos el nombre del fichero a un id \u00fanico o bien a\u00f1adiendo el nombre del servidor que lo escriba (foto.server1.jpg).<\/li>\n
  4. Vale, NFS es malo, pues qu\u00e9 tal un OCFS2<\/a> o GFS<\/a>, pues aunque son sistemas que dan un rendimiento muy superior al NFS, tienen el mismo problema con las escrituras, demasiadas escrituras con demasiados nodos, los tienden a afectar demasiado. Tanto NFS\/CIFS<\/a> como GFS\/OCFS2, son perfectos para entornos con poco ratio de escrituras (ecommerce, noticias, blogs, etc)<\/li>\n
  5. Tambi\u00e9n, parte del problema de tener un entorno para ficheros, ya teniendo un entorno de base de datos (es raro el site actual si base de datos detr\u00e1s), es que nos tenemos que preocupar de tener un entorno de alta disponibilidad, backup, etc adicional.<\/li>\n<\/ol>\n

    As\u00ed que nos quedan dos entornos externos que de alguna forma los podemos ver como accesos a nivel de aplicaci\u00f3n y menos a nivel de sistema. De esta forma tenemos m\u00e1s opciones para adaptar el comportamiento a lo que nos interesa.
    En el caso de guardar los datos en base de datos<\/span>, tenemos pros y contras:
    Pros<\/span><\/span><\/p>\n

      \n
    1. Seguro que no tenemos problemas de colisiones<\/li>\n
    2. Nos permite guardar metadatos para poder mejorar la gesti\u00f3n del espacio<\/li>\n
    3. Nos aprovechamos de todas la mejoras existentes para el accesos en base de datos (memcache, librerias, APIs, etc)<\/li>\n
    4. Facilidad para backups, replicaciones, gesti\u00f3n, alta disponibilidad, etc…<\/li>\n<\/ol>\n

      Contras<\/span><\/span><\/p>\n

        \n
      1. Lectura lenta comparada con acceso a disco<\/li>\n
      2. Capacidad de disco necesaria<\/li>\n<\/ol>\n

        Pero podemos solucionar los contras de forma bastante simple:<\/p>\n

          \n
        1. Utilizar el disco del servidor Web como cache de los ficheros m\u00e1s demandados y si disponemos de suficiente ram, aprovechar herramientas como Memcached<\/a>, Ehcache<\/a> o Velocity<\/a><\/li>\n
        2. Utilizar shards para separar contenidos y permitir escalar. Tal y como he escrito en el post anterior<\/a><\/li>\n<\/ol>\n

          Y por \u00faltimo nuestro amigo cloud. En base a los precios y servicios actuales, los servicios se posicionan en la gama media de sites, si nuestro site tiene muchos datos o mueve mucho tr\u00e1fico, seguramente nos salga m\u00e1s a cuenta hospedarlos nosotros, y si por el contrario movemos muy poco tr\u00e1fico, es muy probable que nuestro proveedor de hosting nos d\u00e9 suficiente espacio y ancho de banda para alojarlo nosotros mismos. Esto si, sin perder de vista que luego tenemos que hacer la gesti\u00f3n de capacidad y poder aguantar los picos que esperemos y los que no \ud83d\ude42
          As\u00ed que a parte de controlar los costes, debemos tener en cuenta:<\/p>\n