Uso y abuso de bases de datos en aplicaciones web

oracleNadie concibe una aplicación web sin base de datos, y la más utilizada sin duda es MySQL. A esto ha contribuido enormemente la relación de MySQL con PHP, lenguaje que se ha impuesto por su facilidad de escritura (mal o bien pero sencillo).

mysqlEn el mundo de los CMS que tanto se han diversificado y tantos se han desarrollado y se pueden usar de forma gratuita, han popularizado el conocimiento básico de bases de datos.

Yo he trabajado sobre todo con SQLserver y MySQL, y algo con Oracle (además de algunas otras menos populares y más específicas de otros entornos no web).

Cada vez más he tenido la sensación de estar en un entorno de trabajo en el que se abusa de las bases de datos. Y las pruebas que para mí lo confirman son estas (en cualquier orden):

  • Amazon ha desarrollado su propio motor de base de datos simplificado para ofrecer servicios
  • Yahoo (por mencionar un grande) dispone (o disponía, hace tiempo que no sigo el tema) de una base de datos de lectura y otra de escritura para poder sopotar la carga sobre las mismas. Ésta es una práctica relativamente habitual.
  • WordPress, el CMS para blogs (y muchas más cosas)  más popular muere (y no es una metáfora) por la base de datos.
  • Los buenos diseñadores de estructuras de bases de datos primero normalizan (estandarizan y estructuran de acuerdo a las normas de orden y coherencia de datos) y cuando todo cumple las reglas de estructura, empiezan a desnormalizar para que el monstruo que se ha creado pueda funcionar en entornos reales y no sólo sobre el papel.

¿Disponemos de alternativas a una base de datos? ¿Cuándo podemos decir que estamos abusando de la base de datos?

Hay dos abusos diferentes, uno es el de almacenaje, y otro es el de consulta. El de almacenaje es muy claro, en cuanto la cantidad de datos sea de varios miles necesitaremos una base de datos para gestionarlos con comodidad y eficiencia. En general, aun con poca cantidad de datos una base de datos para gestión de los mismos siempre es buena opción, pero no tanto para la consulta.

¿Cuánto han agradecido los usuarios de WordPress que apareceieran plugins de caché? De lo que tratan es de reducir las consultas sobre la base de datos al mínimo. La paradoja para mí como técnico que busca la mayor eficiencia en una aplicación, es que la mayoría de las aplicaciones no disponen «de serie» de un sistema de reducción de consultas a base de datos para servir los contenidos web.

Y de esta forma, convertimos aplicaciones ligeras o moderadamente ligeras en mostruos comedores de recursos de servidor.

La alternativa para dejar de abusar de las bases de datos es el uso de archivos de texto, html y xml. El acceso al disco puede ser más o menos rápido, pero nos podemos ahorrar fácilmente el 80% de la carga de trabajo de la CPU del servidor.

Cuando desarrollamos un proyecto nuevo siempre decimos eso de «ya escalaré cuando lo necesite», pero cuando lo necesitamos es tarde y no es tan rápido escalar las consultas a una base de datos. Como mínimo desde el primer momento debemos intentar optimizar las consultas que realizamos, para que sean lo más rápidas posibles y no soliciten campos de información que no vamos a utilizar.

Esto que parece algo evidente no lo es en muchísimos casos en los que por ahorrarse unos segundos de escribir los desarrolladores meten un asterisco (*) y leen todos los campos (a veces decenas) de una tabla de base de datos cuando sólo necesitan un par de ellos.

Y lo segundo que podemos hacer es cachear las páginas o las partes de las páginas que no cambian o cambian poco, tal como se hacía en los principios de internet, donde una web dinámica era un lujo por conocimientos de programación y por recursos de servidor.

Aún podemos hacer más. Esto quizá sea algo controvertido, y lo diré a modo de pregunta porque quiero vuestras opiniones: si sólo tengo que gestionar unos centenares de datos (equivalentes a registros en base de datos), y éstos van a cambiar con mucha frecuencia y a la vez los tengo que mostrar en web, ¿por qué no usar unos sencillos archivos de texto (almacén tipo csv o json), o xml para mantener esta información ahorrando miles de consultas a base de datos? Nosotros lo hacemos.

46 respuestas a “Uso y abuso de bases de datos en aplicaciones web”

  1. El problema no es solo el rendimiento. El modelo relacional de bases de datos, no se integra naturalmente con la programación orientada a objetos. Aun sin tomar en cuenta el problema del rendimiento, siempre que te metes con SQL tienes otro dilema: el costo de desarrollo. Muchas horas -hombre son gastadas no en lógica de negocio, si no en la traducción de los datos que genera la aplicación a sentencias SQL. Una buena parte del trabajo de programación hoy en día, consiste en traducir tus datos a una sentencia SQL y hacer el manejo de estas. Otro pequeño inconveniente del modelo relacional.

  2. Creo que Google, Facebook y otros grandes usan alternativas a las clases bases de datos relacionales SQL (mySQL incluido).\r\nConsulta en la web sobre noSQL , bases de datos orientadas a objetos y cosas asi.

  3. Existen muchas bases de datos que son bastante más «light» que MySQL por ejemplo una es PostgreeSQL. Aunque en compatibilidad no hay otra alternativa a MySQL.

    Si se optimiza bien MySQL se puede tener gran rendimiento sin necesidad de sacrificar tantos recursos, además usar MySQL y bases de datos le da mucho dinámismo a la página.

  4. Ah bueno! Por eso decía!

    Pero entonces no hablemos de «alternativas» :)
    Es una solución a un problema, por llamarlo de alguna forma, de las bases de datos.

  5. uy que interesante.

    soi57 y que usaban? oracle? esperaban segundos, minutos u horas a cada query o como?

    No se por donde va Mysql para solventar el problema del limite de espacio en disco pero me temo que seguir en una estructura relacional a través de una red quizá no seria viable… o si? no se… ¿que opináis? Yo creo que las NoSql están surgiendo por ese motivo.

  6. Pero Ivan, eso es en el caso de que tengas prehecho el xml con la misma petición… que en definitiva aplica a lo que dije anteriormente, si es un sitio pequeño y estático, el xml sirve.

    No soy enemigo de usar xmls, me parecen fantásticos para guardar documentos, y ni hablar de ciertas configuraciones. Pero a lo que respecta a manejo de datos, repito, para mi es absurdo. Las bases de datos son sistemas complejos.

    Se poco de bases de datos, pero en mi modesta opinión, esto es como comparar el bloc de notas con una planilla de cálculos.

  7. Considerar hoy día que un conjunto de ficheros planos es una alternativa a una base de datos es bastante absurdo.

    Es lógico no utilizar una base de datos para una página estática con cinco o 10 páginas distintas, allí sí existiría un uso de base de datos innecesario. Pero es el único caso en el que puedo pensar que es más conveniente un grupo de ficheros que una base de datos hecha y derecha.

    Si existe un abuso, no es de las bases de datos, sino de quienes se las dan de administradores de bases de datos sin saber de optimización. Pero las bases de datos no son las culpables.

    • Creo que el problema es lo encasillado que esta el modelo relacional. El uso de bases de datos para problemas simple (matar una mosca a cañonazos). Y el creer que el uso de BD es una panacea, cuando tiene que ser una solución para algo especifico.\r\nSI vemos mas alla del modelo relacional y de SQL, hay magnificas opciones.

  8. Hombre no es cuestión de quitar la base de datos y usar xml, eso seria absurdo (yo lo he probado). A la hora de manejar la información seria complicadisimo. Es mas bien para usos estáticos de la información ya almacenada en la base de datos de una forma mas compleja o con necesidad de mas recursos. Creo yo, vamos. Si no he entendido mal las posturas. Al menos esas son las mías jejeje

  9. Trillonario tampoco tanto. Te pongo un ejemplo. 10 queries mysql relacionales en diferente tablas en archivos de 100mb cada uno para buscar por ejemplo la lista de personas que ha hecho un tweet o un comentario en un foro/imagen. Buscas los id de las personas, el nick y los datos de la persona, donde esta situado su avatar… Resultado tiempo de proceso pongamosle 1 segundo, por decir. Según muchas teorías relacionales todo debe estar separado, según mi opinión, mas bien por grupos de datos. Perfil, comentarios, etc. Yo prefiero tratar con cuantas menos tablas mejor, por simplicidad mas que nada.

    Ahora con todos esos datos que buscamos en el ejemplo los creamos un archivo en json, xml, html o html+gzip. Tiempo de acceso 0.0001 milisegundos.

    Vamos mas allá. Si usamos las funciones de php readfile en vez de include imprimimos el archivo (si fuese html) sin meterlo entero en memoria. Por tanto nos ahorramos «x» kb de ram por petición.

    Eso multiplicado por las veces que el tío hace click (hay gente que hace click 4 veces en un mismo enlace y carga varias veces la misma pagina) obtenemos que la cache amortigua el problema…

    Vale, existe Squid y sistemas de cache de php pero a menos que estén muy bien configurados se corre el riesgo en enviar información obsoleta.

    Yo creo que cuantas mas barreras pongas al consumo desenfrenado de proceso mejor. Pero claro esto es el tema de antes, para una web pequeña no te importa freír el server. Es mas, mejor para ti que terminas antes y no «te fríes tu» y los servers hoy día no valen caros como para meterte en perder posibilidades para aumentar la potencia del sistema.

  10. No se olviden de SQLite, para sistemas relativamente pequeños es lo mejor y mas rápido. Ampliando su configuración de cacheo en memoria y el «page size» les puedo asegurar que se sorprenderian.

  11. YO he estado en algún entorno en los que no es que se intente evitar el uso de bases de datos si no que se promueve hasta límites absurdos. Donde páginas cacheadas, memcaches y cualquier otra técnica son un parche y donde cualquier consulta se tiene que realizar en plan tsunami, trayéndose las tablas enteras cada vez … Así es que hay para todos los gustos

  12. Interesante tema, la fasilidad y versatilidad de una base de datos en mi caso MySql es algo que por ahora no tiene competencia. El truco esta enoptimizar optimizar y finalmente optimizar.

  13. Mmm, interesante tema. Creo que el uso de ficheros de texto es peor solución en el 99% de los casos. Como apuntan más arriba, las bases de datos no son más que ficheros de texto muy bien optimizados. Suponiendo que fueras capaz de diseñar un sistema de ficheros bien hecho, cumpliendo con ACID y demás temas (¿o vas a dejar que varios usuarios modifiquen un fichero a la vez sin controlar los locks y demás?), lo único que estarías haciendo es crear un sistema de bases de datos con tu nombre, :)

    Lo que sí sería adecuado apuntar es que en infinidad de casos no utilizamos las bases de datos como debemos, dejando, por ejemplo, las claves primarias como únicos índices, cuando podríamos utilizar otros campos, haciendo consultas inadecuadas, etc. Pero sobre si hay que usar bases de datos o no, creo que es un sí rotundo.

    • Creo que de lo que se trata en la web, en primer lugar, es que no necesitas ACID 100%. En segundo que las técnicas de acceso a datos serán optimizadas (como te explican una ventaja es no tener que estar ligando tablas) para superar el rendimiento del motor de la base de datos.\r\nAl no necesitar ACID se agilizan mucho las consultas.\r\nEs difícil definir que porcentaje lo necesita…pero si Google o Facebook lo necesitan el porcentaje no puede ser tan bajo.

  14. Gracias Jonathan no sabia eso de html5.

    angro ;)

    Creo que os estáis encarnizando un poco en «nosql si», «nosql no».

    Esta claro que cada caso, tiene su mejor opción. Por ejemplo para una web que resiste en un solo servidor o su base de datos puede alojarse en un solo servidor. La opción actual mas viable es Mysql.

    En cambio eso no quita que el cacheo se bueno y necesario y tampoco que tenga porque afectar a la búsqueda relacional.

    Ademas las NoSql no son todas key-value. Hay de todo tipo. Yo me estoy interesando bastante por Tokio Cabinet porque dice que es incluso mas rapida que Mysql y ademas puede implementar diferentes motores de bases de datos, incluso relacionales como mysql. Tiene una capa tipo memcached, sistema de archivos y demás… Es muy interesante y dará que hablar.

    Entre eso y el hiphop php de facebook la mayoría de problemas están resueltos… Eso si, discos sólidos, discos sólidos, discos sólidos jejeje

    Es también como habéis dicho algunos. Realmente para un proyectito hay sistemas como ruby on rails que simplifican la tarea muchísimo (yo no me he metido por la curva de aprendizaje) pero para cosas realmente grandes la mayoría de sistemas actuales se escapan de las posibilidades de pequeñas startups que no pueden pagar una Oracle o una mysql Cluster. Ahí si que servirán las NoSql, pero claro, quizá sólo para unos pocos… a menos que mejoren la potencia actual bajando los recursos y ofreciendo bases de datos relacionales…

  15. menos relacionales? más directas?
    Utiliza MyISAM en vez de INNOdb (http://bit.ly/cSvSHL)…

    Da un ejemplo concreto que uses archivos y te voy a mostrar que el tiempo de ejecucion es mucho mayor a uno utilizando base de datos.
    Ni vas a notar el uso de CPU.
    Sin embargo decis maximo de usuarios concurrentes… tambien hay acceso a disco que necesita ser administrado por el sistema operativo y su cpu…

  16. Es probablemente lo más importante hoy en día a nivel de desarrollo: tener un conocimiento del funcionamiento de la máquina para poder compatibilizar al máximo el funcionamiento de la web con la capacidad de la máquina. Sin ir más lejos, es aquí donde radica el éxito de Facebook: no tanto en montar algo grande como en poder escalarlo sin que el usuario se quede con la sensación de lentitud.

  17. Bien, por lo que veo nunca existe un abuso de bbdd sino una mala configuración de la misma y mala optimización de queries… pero los servidores aceptan un máximo de usuarios concurrentes. Si dimensiono mi servidor para los picos máximos de carga, previsibles, medibles y todo lo que querais, me gasto 5 veces más en recursos.

    Fijaos en los ejemplos Facebook, Yahoo, Google, Amazon, todos utilizan bbdd por supuesto, pero alternativas a las «típicas», porque utilizan estructuras de bbdd aligeradas, menos relacionales, más directas… lo que estoy proponiendo son remedios más sencillos para dentro de nuestras pequeñas dimensiones, solventar el mismo problema que estos grandes: las bbdd se comen sus recursos por falta de eficiencia ante determinas situaciones, y no será por falta de expertos o de optimización de sus sistemas y aplicaciones ¿no?

    Os agradezco a todos los comentarios :)

    • Sin duda de lo que se abusa es del \»modelo relacional con lenguaje SQL\».\r\nParece que en almacenamiento de datos se nos cierra el mundo. \r\nAsí como en lenguajes de programación hay miles de opciones, para almacenamiento y recuperación de datos las hay unas cuantas.

  18. Las base de datos no son más que algoritmos óptimos para guardar y recuperar los datos con consultas que pueden presentarse muy complejas. Por tanto, es una solución estándar para cualquiera que necesite tener este aspecto cubierto en su sistema informático.

    Lo de «abusar» de BD’s opino que es tarea del «Arquitecto» de la aplicación saber si la va a necesitar o no. Evidentemente, mantener la info en ficheros y acceder a ellos directamente es el sueño de cualquiera, pero olvídate de consultas que vayan más allá de conocer el nombre del fichero, o de añadir nuevas funcionalidades que impliquen romperte la cabeza en buscar info por esos ficheros.

    Luego están las empresas que se lo pueden permitir e implementan sus propios métodos de persistencia y consulta. OK. Tienen recursos para poder hacer I+D y ahorrarse unos segundos en las búsquedas = usuarios más contentos.

    Lo que si considero un abuso es en el uso de capas intermedias, tipo Hibernate, simplemente por facilitar la programación y reducir tiempos. Soluciones rápidas a cualquier precio. Resultado: Muchas veces para recuperar un objeto de BD se podrían ahorrar un gran número de consultas.

    Pero ya digo, la mayoría de negocios web con mysql van sobrados, otro tema es que sepan sacarle el mayor rendimiento y no cagarla abusando del «LIKE», índices donde no deben, outer joins que pueden ser inner joins, etc.

  19. Jonathan, nunca te la he quitado, de hecho en mi primer comentario apuntaba en la misma dirección que el tuyo. Simplemente comento que hay que tener otras variables en cuenta y a veces la capacidad de nuestro servidor nos puede obligar a tomar caminos distintos de los naturales.
    Un saludo

  20. Antes escribía desde mi móvil y no me he podido extender mucho.
    Creo que cada opción tiene su sitio. Si yo tengo una app web corriendo en un server con ínfimos recursos, seguramente cualquier ahorro de CPU o memoria es bienvenido y ahí es donde almacenar la info en ficheros puede tener ventaja. Ahora que si tienes un server con suficiente memoria y CPU pues la cosa cambia.
    Ignacio, Jonathan, si al final os animáis a hacer la comparativa (que no reto que suena mal) por qué no lo limitáis a que corra en un 486 con 128MB de RAM?? Ahí seguramente los resultados serían muy curiosos.

    Un saludo y encantado de comentar aquí.

  21. Nosotros usamos principalmente mysql y cacheamos, pero sin duda la solución pasa por no usar bases de datos, quizás usar xml como comentáis, pero la clave que se masifique esa forma de gestionar los datos.

    También usamos SQL server pero por obligación para el software de gestión :)

  22. No estoy de acuerdo en casi nada de lo que mencionas.
    Estoy de acuerdo en implementar sistemas de cacheo, como bien sabes en un caso se calculan y obtienen las cosas.
    Por el otro lado en el otro ya los tienes pre-calculados los datos.
    Ahí te ahorrarías varias querys por lo tanto uso de CPU.
    Por otro lado la seguridad que puede brindar un motor de base de datos, la recuperación ante fallos blandos, la velocidad y la plasticidad que te dan no te lo va a entregar ningún tipo de archivo.
    Estas volviendo 20 años atrás diciendo que se abusa las base de datos.

    Es más te reto a armar una aplicación con archivos y yo la misma corriendo sobre un simple MySQL o Postgres y podríamos compararlo.
    Una buena optimización de la base de datos, una buena optimización y entender como están las querys, una base de datos indexada y no hay con que darle!
    También podes combinarlo con soluciones tipo memcached pero siempre utilizando una base de datos por detrás.

    Para los que hablan sobre acceso en disco, monten el disco en memoria RAM si tienen la posibilidad y no van a tener mas acceso a disco y van a ver como VUELA.

    • Las grandes empresas se están apartado del modelo relacional por sus limitaciones. Sin duda se necesitan las BD o un esquema parecido. Pero hay que ver opciones diferentes (mySQL es por demás demasiado modesto). Pero para eso, los expertos.

  23. Completamente de acuerdo, es un problema «difícil» de solucionar ya que cada caso es o será diferente, pero que una vez encontrado de donde cojea la aplicación, puedes multiplicar por 1000 o más el rendimiento máximo con poca inversión en hierro (ancho de banda, sería otra cosa :P)
    En el caso que comentas de pocos (cientos) datos que cambian mucho (minutos?) y aquí voy a suponer que generas páginas iguales para todos los usuarios (blog, noticias, etc), creo que la mejor opción de compromiso entre facilidad de gestión y rendimiento seria cachear el HTML ya generado por el PHP por durante 2 o 3 minutos. Tienen que ser consultas muy complejas para que no puedas lanzar una cada 3 minutos y si el sistema de cacheo lo basas en algo decente como nginx, lighttpd, Zeus ZXTM un solo servidor te puede aguantar sin problemas 2000 o 3000 hits/segundo
    Si por cada usuario tienes contenidos diferentes, pues a cachear la BD con memcache o parecido o ir a noSQL, que aunque verdes, los que menos problemas me han dado (de momento) son Cassandra y HBase

  24. Para mi hay un punto claro y es que tanto para acceso a datos en una bbdd sql como para acceso a datos en un archivo en disco tiramos de lectura de disco, pero la bbdd tiene muchos métodos para optimizar la lectura como caché, montajes en memoria etc… por tanto siempre va a ser más rápido y óptimo usar bbdd, en mi opinión.

  25. No se puede olvidar tampoco que las consultas son muy importantes. Ahora que trabajo con millones de datos, me he tenido que estrujar el cerebro para que las consultas sean rápidas.

    A veces hay que replantearse desde el principio una consulta que en principio parece que no tiene alternativa.

    Yo soy de la opinión que se tiene menospreciada a MySQL. No olvidemos que MySQL es un motor y está optimizado al máximo para funcionar bien de una determinada manera y los que cometemos el fallo de no saber usarla somos nosotros. Hay auténticos gurús de MySQL que consiguen que una web de millones de datos sea tan rápida como una con cientos… y sin muchos recursos, simplemente optimizando sentencias, jugando con las cachés y usando los tiempos idle de la web para optimizar, reindexar y demás.

    Estoy con Iván en que hay poca información en español sobre esto. Todo lo que digamos será poco jeje

  26. Daniel, tienes razón en que no podemos sustituir una consulta compleja a base de datos con una lectura a disco, y supongo que Alberto iba también por ese camino. En ese sentido os doy la razón. Pero la realidad es que en procesos determinados procesos de actualización y consulta más simples que complejos, y si no manejamos gran cantidad de registros, el uso de ficheros planos me ha demostrado ser muchísimo más eficiente en cuanto a recursos de CPU consumidos.

    Y aunque se pueden cachear las queries, la realidad es que lo más eficiente en una aplicación web es cachear las páginas finales.

    Aprovecho para que me sugirias algún libro sobre diseño de bases de datos :)

  27. Nosotros estamos ahorrando mucho dinero en servidores a clientes que nos vienen desde un dedicado con prestaciones que no necesitan para sus cms basados en wordpress.

    La mayoría de los problemas se solucionan arreglando fallos en las bases de datos provocados por malas actualizaciones y adicionalmente aplicando el uso de bases de datos de tipo NOSql.

    En muchas ocasiones con un plugin puede que no baste para solucionar el problema, ya que para llegar a esos plugins WordPress ha tenido que ejecutar parte de su Workflow y si hay operaciones durante la misma su uso puede resultar hasta ineficiente.

    Hay plugins que te cachean estáticos a disco, eso es bueno si el sitio web no tiene mucho movimiento y no precisa de gran número de invalidamientos de cache. En caso contrario penalizaría el acceso a disco y muchos proveedores intentarían aprovechar la ocasión para venderte «un servidor más grande».

    Un saludo.

  28. Siento ser crítico pero el análisis es extremadamente poco riguroso, se comentan aspectos por encima sin profundizar y la primera vista es equivocada o por lo menos incierta.
    Actualmente hay bases de datos MySQL que soportan hasta 200k de transacciones por segundo. (rockyou.com)
    Si la configuración de tu blog tiene un cuello de botella con 50 transacciones por segundo en el blog hay cientos de formas de mejorarlo.

    ¡Paga para que una empresa de programación te lo mejore! (barriendo para casa)
    si quieres performance lo tienes que pagar. El comentario de guardarlos en ficheros csv o json, es cuanto menos curioso, cómo se guardan acaso las tablas de MySQL, acaban siendo ficheros también. Sin embargo, el acceso tiene una respuesta de uno a dos órdenes mejores que acceder directamente a ficheros de disco y sus posibilidades de caché y de alto rendimiento son mucho mayores.
    Seguiría así durante una buena charla pero no es momento ni lugar, gracias

  29. Bueno, no soy programador, pero sí me inteeresan estas noticias donde se perfilan, los movimientos técnologicos por venir.
    Eso que tu dices tiene mucha verdad, he visto webs que cargan rapidito, y otras no, pero eso sería porblema de optimización, pero no quita que las consultas por bases de datos no se puedan dejar al mínimo, y encima le ponen una capita de flash para que se vea mejor, no, eso no rinde.

    Sin embargo, este escrito me recordó a lo que leí hace un tiempo sobre las bases anti sql, para darle otra vuelta de tuerca:
    http://www.dosideas.com/base-de-datos/657-nosql-el-movimiento-en-contra-de-las-bases-de-datos.html

  30. En muchos entornos,donde mysql se queda pequeño, se ha migrado a postgresql (que tambien es soft. libre).

    Esta discusion se ha dado varias veces en slashodt, copio un comentario muy interesante:

    «Web analytics databases are getting even larger. eBay now has a 6 1/2 petabyte warehouse running on Greenplum — user data — to go with its more established 2 1/2 petabyte Teradata system. Between the two databases, the metrics are enormous — 17 trillion rows, 150 billion new rows per day, millions of queries per day, and so on. Meanwhile, Facebook has 2 1/2 petabytes managed by Hadoop, not running on a conventional DBMS at all, Yahoo has over a petabyte (on a homegrown system), and Fox/MySpace has two different multi-hundred terabyte systems (Greenplum and Aster Data nCluster). eBay and Fox are the two Greenplum customers I wrote in about last August, when they both seemed to be headed to the petabyte range in a hurry. These are basically all web log/clickstream databases, except that network event data is even more voluminous than the pure clickstream stuff.»

    Por cierto, greenplum es un fork (de pago) de postgresql.

    http://developers.slashdot.org/article.pl?sid=09/04/30/1216248&art_pos=2

  31. Alberto, precisamente lo que digo es que una base de datos NO siempre es la mejor implementación de datos guardados en disco con acceso masivo cuando se presentan contenidos web

  32. Desde luego la cache ayuda mucho, pero no está reinventando la rueda.
    No olvidemos que una base de datos al final es la mejor implementación de datos guardados en disco con acceso masivo.

  33. Creo que teniendo resuelto el apartado de actualizar el mismo fichero de forma concurrente en el servidor, desde luego yo prefiero usar un fichero XML (mejor XML y luego parsarlo a json o cualquier tipo de array que necesite el desarrollador) y enviar la carga de su proceso al cliente. Cuando lo consigues, creo que ganas en simplicidad y en rendimiento.

  34. Yo he manejado distintos tipos de bases de datos, y la que más uso es Mysql por su buena integración con PHP.

    Mi consejo rotundo es utilizar una capa de abastracción de la base de datos que te permite cambiar facilmente entre las bases de datos e incluso por que no entre distintos métodos de almacenaje como ficheros de texto plano, xml, etc. Yo sin lugar a dudas me quedo con Doctrine :-)

    Si además utilizas algún framework te aseguras que en cualquier momento puedes habilitar una caché en minutos y que las consultas a la base de datos van a estar bien organizadas en sus respectivas capas y archivos unificados y encima optimizadas automáticamente por la propia capa de abastración. Si necesitas escalar porque empieza a resentirse basta con optimizar las consultas más a fondo.

  35. Cuidado con cachear demasiado que muere el disco, literalmente. Ya no solo por entrada salida que tiene un limite sino porque termina partiéndose. Yo ya uso discos duros en estado solido por ese motivo ;)

    Ando esperando a que maduren las nuevas bases de datos de software libre para empezar con algo NoSql…

    Con respecto a la pregunta. json + NoSql = el futuro de webs masivas.

    Genial que se empiece a hablar de estas cosillas ;) En habla hispana no hay casi información.