Uso y abuso de bases de datos en aplicaciones web
Nadie 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).
En 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
No salgas de casa sin memcached :)
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…
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.
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.
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.
Hay CMS que no necesitan de base de datos, por ejemplo: Simple CMS http://get-simple.info/…
Lo recomiendo encarecidamente para pequeños proyectos.
Saludos.
Una cosita tambien interesante, no por nada HTML5 trae Web Storage con un sistema basado en un esquema de base de datos.
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
Barbaro!… Gracias por darme la razón nuevamente diciendo que pruebe con un 486 porque es de 1989 y volvimos 21 años atrás!
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í.
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 :)
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.
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
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.
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
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 :)
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.
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
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
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
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
Por todo eso que comentas, empiezan a tomar auge software como Cassandra[1], CouchDB[2] o MongoDB[3] que yo creo que en no mucho tiempo, van a ser el futuro de las bases de datos en entornos web (en entornos empresariales, costará mucho despegar a Oracle).
[1] – http://incubator.apache.org/cassandra/
[2] – http://couchdb.apache.org/
[3] – http://www.mongodb.org/
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.
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.
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.
Para el que quiera alternativas formales a las bases de datos SQL aquí tiene un listado: http://nosql-database.org