Portada
mis comunidades
otras secciones
#2:
Impresionante y casi que no termino de creerme como puede haber tanta diferencia metiendo "un paso más" en el proceso de la información.
Claro que por el titular parece que podría estar al alcance de cualquiera que sepa PHP, pero leyendo el punto 4 como bien dice #1 se ve que no es una simple ordenación sino una serie de normas a seguir que le quita gran parte del procesamiento al gestor de bases de datos MySQL como evitar el uso "básico" de JOINs o claves ajenas... digamos que se convierte una Base de Datos relacional en una no relacional, quitándole "realismo" y mucha mucha comprensibilidad.
Para mi esta es una solución para sistemas a gran escala en los que el rendimiento se vuelve crucial y un método como este puede ahorrar millones y millones de euros, pero para sistemas a pequeña o media escala yo apostaría siempre por una mejor estructuración y diseño lógico realmente comprensible de la base de datos y de la aplicación en general =)
Claro que por el titular parece que podría estar al alcance de cualquiera que sepa PHP, pero leyendo el punto 4 como bien dice #1 se ve que no es una simple ordenación sino una serie de normas a seguir que le quita gran parte del procesamiento al gestor de bases de datos MySQL como evitar el uso "básico" de JOINs o claves ajenas... digamos que se convierte una Base de Datos relacional en una no relacional, quitándole "realismo" y mucha mucha comprensibilidad.
Para mi esta es una solución para sistemas a gran escala en los que el rendimiento se vuelve crucial y un método como este puede ahorrar millones y millones de euros, pero para sistemas a pequeña o media escala yo apostaría siempre por una mejor estructuración y diseño lógico realmente comprensible de la base de datos y de la aplicación en general =)
#23:
Ahora bien, en que proporción ha aumentado el acoplamiento y el costo de mantenimiento de la aplicación?
Muchos sabemos que a corto plazo es sencillo conseguir mejores rendimientos pero a largo plazo no es más que plantar minas. Volvamos a los tiempos en los que se programaban complejos algoritmos que sólo el autor era capaz de comprender. Creemos otra gran crisis del software. Juntos podemos hacer que la crisis no sólo sea financiera
Además, en el punto dos dice que se han simplificado mucho las búsquedas. Eso es trampa, para hacer una comparativa hay que hacerlo en igualdad de condiciones. Haciendo un sistema más "capado" hay que ser un poco zoquete para no ganar rendimiento.
También encuentro una mentira en el título. Dice que quien ordena es PHP pero el rendimiento se debe a Cassandra que está escrito en Java.
Yo uso php y me encanta pero me parece irrisorio el simple hecho de pensar que php "procesa" datos más rápido que mysql. Simplemente php no está hecho para eso. Pero Java (en el caso de cassandra) para cosas muy concretas y focalizadas pues sí me lo creo pero ya tienes que hacer un sistema exclusivo y totalmente acoplado (como dije antes).
Mi opinión es que esta gente sabrá mucho de PHP pero igual desconocen ciertos aspectos de las bases de datos (como he podido comprobar muchas veces tratando con programadores, aunque siempre hay quien me sorprende). La misma base de datos, en la misma máquina, la misma versión del programa y con la misma carga puede comportarse de manera totalmente diferente en función de quien haya optimizado su configuración.
Mysql no es un juguete y aunque puedas tenerlo con un simple aptitude install no quiere decir que lo estes usando correctamente (o a caso un fórmula 1 lo fabrican y ala, a correr? No, requiere de manos hábiles para hacerlo correr bien). Además evidentemente de tener un buen diseño de la base de datos como tablas pensadas para determinados tipos de búsquedas, una buena forma normal para evitar redundancia... A veces incluso si diseñas bien la base de datos no hace falta ni buscar los datos. Recordemos que una vista es una consulta precompilada y si a eso le sumamos los análisis estadísticos que hace el SGBD podemos hacer que muchas consultas devuelvan datos sin necesidad buscar en ellos.
Un detalle para que no penséis "Vaya mierda el sistema relacional, no sirve para nada". Estos programadores tendrán mucha habilidad programando (valga la redundancia) pero hay que tener en cuenta los fundamentos matemáticos. Sí, el sistema relacional es puramente matemático (como la encriptación y el 90% de la informática) y la única empresa que siguió tajantemente este modelo fue Oracle y mira donde está (buscad sobre Codd, el padre del sistema relacional y que era matemático)
Espero, por su bien, que se hayan basado en algo más que en el "parece que funciona mejor"
Podría tirarme el día entero pero sólo añadiré que si tanto te preocupa el rendimiento en mysql pues crea tus funciones integradas en C para mysql. O acaso se pueden hacer algoritmos más eficientes (a la vez que sucios) que con C ?
Ay, ya me quedé a gusto
Muchos sabemos que a corto plazo es sencillo conseguir mejores rendimientos pero a largo plazo no es más que plantar minas. Volvamos a los tiempos en los que se programaban complejos algoritmos que sólo el autor era capaz de comprender. Creemos otra gran crisis del software. Juntos podemos hacer que la crisis no sólo sea financiera
Además, en el punto dos dice que se han simplificado mucho las búsquedas. Eso es trampa, para hacer una comparativa hay que hacerlo en igualdad de condiciones. Haciendo un sistema más "capado" hay que ser un poco zoquete para no ganar rendimiento.
También encuentro una mentira en el título. Dice que quien ordena es PHP pero el rendimiento se debe a Cassandra que está escrito en Java.
Yo uso php y me encanta pero me parece irrisorio el simple hecho de pensar que php "procesa" datos más rápido que mysql. Simplemente php no está hecho para eso. Pero Java (en el caso de cassandra) para cosas muy concretas y focalizadas pues sí me lo creo pero ya tienes que hacer un sistema exclusivo y totalmente acoplado (como dije antes).
Mi opinión es que esta gente sabrá mucho de PHP pero igual desconocen ciertos aspectos de las bases de datos (como he podido comprobar muchas veces tratando con programadores, aunque siempre hay quien me sorprende). La misma base de datos, en la misma máquina, la misma versión del programa y con la misma carga puede comportarse de manera totalmente diferente en función de quien haya optimizado su configuración.
Mysql no es un juguete y aunque puedas tenerlo con un simple aptitude install no quiere decir que lo estes usando correctamente (o a caso un fórmula 1 lo fabrican y ala, a correr? No, requiere de manos hábiles para hacerlo correr bien). Además evidentemente de tener un buen diseño de la base de datos como tablas pensadas para determinados tipos de búsquedas, una buena forma normal para evitar redundancia... A veces incluso si diseñas bien la base de datos no hace falta ni buscar los datos. Recordemos que una vista es una consulta precompilada y si a eso le sumamos los análisis estadísticos que hace el SGBD podemos hacer que muchas consultas devuelvan datos sin necesidad buscar en ellos.
Un detalle para que no penséis "Vaya mierda el sistema relacional, no sirve para nada". Estos programadores tendrán mucha habilidad programando (valga la redundancia) pero hay que tener en cuenta los fundamentos matemáticos. Sí, el sistema relacional es puramente matemático (como la encriptación y el 90% de la informática) y la única empresa que siguió tajantemente este modelo fue Oracle y mira donde está (buscad sobre Codd, el padre del sistema relacional y que era matemático)
Espero, por su bien, que se hayan basado en algo más que en el "parece que funciona mejor"
Podría tirarme el día entero pero sólo añadiré que si tanto te preocupa el rendimiento en mysql pues crea tus funciones integradas en C para mysql. O acaso se pueden hacer algoritmos más eficientes (a la vez que sucios) que con C ?
Ay, ya me quedé a gusto
#37:
#24
Los Cassandras y similares tienen su utilidad cuando estamos hablando de miles de transacciones por segundo. Cifras que ninguna base de datos puede asumir, por muchas máquinas que tengas.
El sistema que estoy revisando ahora se traga sin queja más de 30000 transacciones por segundo con MS SQL Server 2005 en un servidor blade con una SAN, RAID 5 con discos de 15000rpm con 5 unidades lógicas. Además tanto el servidor, como la SAN son compartidos por otros sistemas.
Si cambiáramos los discos por SSD podríamos mejorar un 40% y si añadiéramos discos SSD podríamos hablar de más del 100% o lo que nos dé la gana hasta llegar al límite de la SAN.... no veo el problema de rendimiento en SGBD relacionales.
Lo que veo es gente que se va por los cerros de Úbeda cuando no saben pensar en el sistema como un todo.
Aún así ¿MySQL? para ese volumen se queda corto, MS SQL Server, Oracle, DB2 esos sí pueden con ese volumen.
Leyendo el artículo he pensado que esta gente tiene un problema diferente...o no entienden los SGBD relacionales y han hecho una mierda con MySQL, (más que probable), o bien necesitan tener los datos distribuidos globalmente y sus comunicaciones no son todo lo buenas que necesitarían para ello.
En principio apunto a la 1ª opción.
Comentaré en función de lo que mejor conozco, MS SQL Server, y sobre los puntos de la entrevista:
1º. (...)Using Cassandra they've built two clusters: one for indexes and one for record(...)
En SQL Server la práctica es separar índices y tablas (registros) en filegroups diferentes, con lo que lo que están separados. Si el índice contiene los campos de las queries más comunes, consigues el mismo efecto....amén de que lo puedes separar también fraccionando tanto la tabla como los índices en filegroups diferentes...no veo mejora en lo que han hecho comparado con lo que da SQL Server.
2º (...)Restrict what the user can do. The system is kept simpler by not allowing open ended queries. (...)
No veo nada que afecte a escoger SGBD en esto.
3º The relation tool chain has failed for real-time (...) so why bother? (...)
Este es el quid de la cuestión, que no acaban de ver cómo hacerlo y no quieren preocuparse...bueno, cuando empiecen a salir incosistencias que lo disfruten, ellos y los usuarios.
4º Scaling practices turn a relational database into a non-relational database
Los coj.... 1º normalizas, y luego desnormalizas con vistas indexadas, y aprovechando que las queries son predefinidas es útil tener índices de cobertura y procedimientos almacenados. Si lo montas bien no tienes problemas de rendimiento en ese sentido.
Los puntos 5º, 6º y 7º no los veo descabellados, pero de la entrevista no saco nada que me haga pensar que han tomado el camino correcto. Lógicamente la entrevista no entra en los detalles, así que puede ser una decisión brillante...y de todas formas el hecho de tener los 3 data centers separados puede ir en esta línea y explicar la decisión, pero me sigue oliendo a "moda" de desarrolladores que no saben de SGBD relaciones.
Los Cassandras y similares tienen su utilidad cuando estamos hablando de miles de transacciones por segundo. Cifras que ninguna base de datos puede asumir, por muchas máquinas que tengas.
El sistema que estoy revisando ahora se traga sin queja más de 30000 transacciones por segundo con MS SQL Server 2005 en un servidor blade con una SAN, RAID 5 con discos de 15000rpm con 5 unidades lógicas. Además tanto el servidor, como la SAN son compartidos por otros sistemas.
Si cambiáramos los discos por SSD podríamos mejorar un 40% y si añadiéramos discos SSD podríamos hablar de más del 100% o lo que nos dé la gana hasta llegar al límite de la SAN.... no veo el problema de rendimiento en SGBD relacionales.
Lo que veo es gente que se va por los cerros de Úbeda cuando no saben pensar en el sistema como un todo.
Aún así ¿MySQL? para ese volumen se queda corto, MS SQL Server, Oracle, DB2 esos sí pueden con ese volumen.
Leyendo el artículo he pensado que esta gente tiene un problema diferente...o no entienden los SGBD relacionales y han hecho una mierda con MySQL, (más que probable), o bien necesitan tener los datos distribuidos globalmente y sus comunicaciones no son todo lo buenas que necesitarían para ello.
En principio apunto a la 1ª opción.
Comentaré en función de lo que mejor conozco, MS SQL Server, y sobre los puntos de la entrevista:
1º. (...)Using Cassandra they've built two clusters: one for indexes and one for record(...)
En SQL Server la práctica es separar índices y tablas (registros) en filegroups diferentes, con lo que lo que están separados. Si el índice contiene los campos de las queries más comunes, consigues el mismo efecto....amén de que lo puedes separar también fraccionando tanto la tabla como los índices en filegroups diferentes...no veo mejora en lo que han hecho comparado con lo que da SQL Server.
2º (...)Restrict what the user can do. The system is kept simpler by not allowing open ended queries. (...)
No veo nada que afecte a escoger SGBD en esto.
3º The relation tool chain has failed for real-time (...) so why bother? (...)
Este es el quid de la cuestión, que no acaban de ver cómo hacerlo y no quieren preocuparse...bueno, cuando empiecen a salir incosistencias que lo disfruten, ellos y los usuarios.
4º Scaling practices turn a relational database into a non-relational database
Los coj.... 1º normalizas, y luego desnormalizas con vistas indexadas, y aprovechando que las queries son predefinidas es útil tener índices de cobertura y procedimientos almacenados. Si lo montas bien no tienes problemas de rendimiento en ese sentido.
Los puntos 5º, 6º y 7º no los veo descabellados, pero de la entrevista no saco nada que me haga pensar que han tomado el camino correcto. Lógicamente la entrevista no entra en los detalles, así que puede ser una decisión brillante...y de todas formas el hecho de tener los 3 data centers separados puede ir en esta línea y explicar la decisión, pero me sigue oliendo a "moda" de desarrolladores que no saben de SGBD relaciones.
#12:
#2 Es que usar MySQL como referencia de rendimiento es de risa, y más teniendo en cuenta JOINs, porque la tecnología más moderna que usa MySQL para optimizarlos se llama "producto cartesiano". Eso sí, para un blog y webs chorras sobra, para qué engañarnos.
Que los de Digg se dejen de Cassandra y de que si SQL no escala, y que utilicen un SGBD de verdad como PostgreSQL, Firebird o incluso (¡invocando negativos!) Oracle o MS SQL Server. En serio, hay órdenes de magnitud de diferencia entre MySQL y el resto en cuanto entran en juego consultas mínimamente complejas.
Que los de Digg se dejen de Cassandra y de que si SQL no escala, y que utilicen un SGBD de verdad como PostgreSQL, Firebird o incluso (¡invocando negativos!) Oracle o MS SQL Server. En serio, hay órdenes de magnitud de diferencia entre MySQL y el resto en cuanto entran en juego consultas mínimamente complejas.
#39:
#33 El tema es que eBay/Paypal tira de Oracle, que tiene muchas más consultas que Digg, su base de datos anda en el rango de los Petabytes (Digg, si no recuerdo mal, no llega al terabyte) y cumple ACID. Y mientras a muchos talibanes del NoSQL se les llena la boca de que "SQL no escala" o "el modelo relacional no escala".
Para los menos expertos, no penséis que un Cassandra es lo que necesitáis. Solo tiene sentido en sites con un tráfico "brutal" de transacciones simultáneas.
Exacto. Y donde la integridad de los datos, su actualización en tiempo real y la atomicidad de las transacciones tampoco es crítica. Es decir, Facebook y pocos más, donde no te importa ver un post 1 segundo antes que después, donde si se pierde un post de cada 10.000 nadie va a morir o a perder dinero, donde no importa que queden datos "sueltos", sin "relación" con otros en la BDD, donde la proximidad temporal es muy fuerte.
Las soluciones NoSQL por lo general son de muy bajo nivel (de abstracción, por si alguien se extraña) y tienen usos muy concretos con volúmenes de datos y proporciones de consultas muy peculiares, todo tan específico que realmente son cuatro peces gordos los que pueden justificar su uso. Y Digg no es uno de ellos.
Para los menos expertos, no penséis que un Cassandra es lo que necesitáis. Solo tiene sentido en sites con un tráfico "brutal" de transacciones simultáneas.
Exacto. Y donde la integridad de los datos, su actualización en tiempo real y la atomicidad de las transacciones tampoco es crítica. Es decir, Facebook y pocos más, donde no te importa ver un post 1 segundo antes que después, donde si se pierde un post de cada 10.000 nadie va a morir o a perder dinero, donde no importa que queden datos "sueltos", sin "relación" con otros en la BDD, donde la proximidad temporal es muy fuerte.
Las soluciones NoSQL por lo general son de muy bajo nivel (de abstracción, por si alguien se extraña) y tienen usos muy concretos con volúmenes de datos y proporciones de consultas muy peculiares, todo tan específico que realmente son cuatro peces gordos los que pueden justificar su uso. Y Digg no es uno de ellos.
#7:
¿Y para esto tuve que estudiar álgebra relacional? Menuda estafa...
Comentarios
Ahora bien, en que proporción ha aumentado el acoplamiento y el costo de mantenimiento de la aplicación?
Muchos sabemos que a corto plazo es sencillo conseguir mejores rendimientos pero a largo plazo no es más que plantar minas. Volvamos a los tiempos en los que se programaban complejos algoritmos que sólo el autor era capaz de comprender. Creemos otra gran crisis del software. Juntos podemos hacer que la crisis no sólo sea financiera
Además, en el punto dos dice que se han simplificado mucho las búsquedas. Eso es trampa, para hacer una comparativa hay que hacerlo en igualdad de condiciones. Haciendo un sistema más "capado" hay que ser un poco zoquete para no ganar rendimiento.
También encuentro una mentira en el título. Dice que quien ordena es PHP pero el rendimiento se debe a Cassandra que está escrito en Java.
Yo uso php y me encanta pero me parece irrisorio el simple hecho de pensar que php "procesa" datos más rápido que mysql. Simplemente php no está hecho para eso. Pero Java (en el caso de cassandra) para cosas muy concretas y focalizadas pues sí me lo creo pero ya tienes que hacer un sistema exclusivo y totalmente acoplado (como dije antes).
Mi opinión es que esta gente sabrá mucho de PHP pero igual desconocen ciertos aspectos de las bases de datos (como he podido comprobar muchas veces tratando con programadores, aunque siempre hay quien me sorprende). La misma base de datos, en la misma máquina, la misma versión del programa y con la misma carga puede comportarse de manera totalmente diferente en función de quien haya optimizado su configuración.
Mysql no es un juguete y aunque puedas tenerlo con un simple aptitude install no quiere decir que lo estes usando correctamente (o a caso un fórmula 1 lo fabrican y ala, a correr? No, requiere de manos hábiles para hacerlo correr bien). Además evidentemente de tener un buen diseño de la base de datos como tablas pensadas para determinados tipos de búsquedas, una buena forma normal para evitar redundancia... A veces incluso si diseñas bien la base de datos no hace falta ni buscar los datos. Recordemos que una vista es una consulta precompilada y si a eso le sumamos los análisis estadísticos que hace el SGBD podemos hacer que muchas consultas devuelvan datos sin necesidad buscar en ellos.
Un detalle para que no penséis "Vaya mierda el sistema relacional, no sirve para nada". Estos programadores tendrán mucha habilidad programando (valga la redundancia) pero hay que tener en cuenta los fundamentos matemáticos. Sí, el sistema relacional es puramente matemático (como la encriptación y el 90% de la informática) y la única empresa que siguió tajantemente este modelo fue Oracle y mira donde está (buscad sobre Codd, el padre del sistema relacional y que era matemático)
Espero, por su bien, que se hayan basado en algo más que en el "parece que funciona mejor"
Podría tirarme el día entero pero sólo añadiré que si tanto te preocupa el rendimiento en mysql pues crea tus funciones integradas en C para mysql. O acaso se pueden hacer algoritmos más eficientes (a la vez que sucios) que con C ?
Ay, ya me quedé a gusto
Para el #23 el concepto es que sea más eficiente a nivel de peticiones por segundo utilizando hardware de pocas prestaciones. Amazon que es una empresa bastante importante y otras utilizan cosas parecidas. El concepto no es demonizar el concepto de bases de datos relacional, sino mas crear cosas útiles para nuestros requirimientos, es decir, hacer ingenieria, no aplicar una solución generalista.
¿Y para esto tuve que estudiar álgebra relacional? Menuda estafa...
#7 Ya, tantas horas explicándonos como funciona, y ahora va a resultar que es menos eficiente que por código. Tócatelos...
#7 A mi se me plantea una duda peor aun... ¿para esto tengo que estudiar algebra relacional ahora?
"¿Por qué no utilizar una base de datos no relacional desde un principio?."
Porque, al principio, necesitas añadir funcionalidades, no pasarte el día optimizando.
Porque, al principio, no sabes qué funcionalidades van a ser más populares y más se beneficiarían de una optimización.
Porque, al principio, vas a estar cambiando cosas cada dos por tres, y como tengas que hacerlo sobre una BD NoSQL, te vas a cagar.
En resumen, porque al principio no tienes ni zorra.
Vaya campañaza a favor del PostgreSql, cómo se nota que aprieta el lobby del open source. Desde que lo compró Oracle, el MySql es una puta mierda que nadie quiere, eso sí, antes era la polla, un ejemplo a seguir, lo mejor del mundo, le daba mil patadas al MS-SqlServer y doscientas a Oracle, y ahora resulta que no vale un carajo...
#14: Pasar de MySQL a cualquier cosa es escalar. (Y PostgreSQL no es cualquier cosa)
#16 así a al azar (casi): http://sequel.heroku.com/2010/03/29/myisam-innodb-and-postgresql/
#20: Citando el artículo que enlazas:
"My conclusion is that, in general, there is no performance reason to choose MySQL over PostgreSQL when using Sequel as the database library. Replication support now remains the main technical advantage of MySQL over PostgreSQL, and with PostgreSQL 9.0, most of that advantage will be removed."
#21 Es decir, que no es mejor tampoco PostgreSQL, aunque la replicación de MySQL ahora mismo es una ventaja.
Evidentemente se habla de la librería Sequel y es un problema concreto, pero va en la linea de lo que digo: PostgreSQL tampoco es una máquina de picar carne.
#20 #21 ¿Y qué tal una aplicación que use joins, para aprovechar el llamado "modelo relacional"? Porque con Sequel va a dar un poco igual usar MySQL, PostgreSQL que SQLite o ficheros csv: Sequel mapea objetos en la base de datos y eso no son más que selects e inserts muy sencillitos sobre una una tabla normal y corriente.
Llenad 5 tablas con 100.000 filas de valores basura y haced un join de todas ellas con MySQL. Si os responde a la consulta os podéis dar con un canto en los dientes.
#30 Es mucho mejor que eso, Haz una tabla con 11 campos tipo TEXT (también vale VARCHAR(1024) por ej.), intenta llenarlos con más de 768 carácteres (bytes) cada uno
MEEEEC, mega fail, es lo que tiene la retrocompatibilidad.
#32. Esas cosas, en PostgreSQL no pasan. Por eso los los "postgresistas" nos cabreamos tanto cuando tocamos MySQL.
Hay por ahí un libro que se llama High Performance MySQL o algo así que explica un montón de técnica para optimizar índices, consultas y demás. Casi sólo con lo que dice ese libro te comes con patatas lo que sea
Y ahora que Digg funciona 'bien', quién va a mantener toda esa paranoia? el programador que lo mantenga, buen programador será.
Esta es la clave del asunto, como bien dice #1
Todo este esfuerzo requerido para hacer escalar una base de datos relacional básicamente quiere decir que vas a usar una base de datos no relacional de todas formas. Entonces ¿Por qué no utilizar una base de datos no relacional desde un principio?.
En mi opinión, han hecho la ñapa mayor del reino, como dice #9 pobre del que lo tenga que mantener, por un error en el planteamiento inicial de Digg. No es tanto un error de diseño, sino que la cosa ha crecido tanto que ahora cambiar todo es demasiado costoso, al menos bajo el punto de vista de los desarrolladores de Digg.
No nos olvidemos del nombre y trafico de las webs que se ven obligadas a hacer esto. El 99.9% le sacaria mas partido a una base de datos relacional.
Y si esta se "atasca" el 90% de los casos es por no estar lo campos indexados correctamente.
El tema es que un SGBD puede correr un poco más rápido que otro, incluso el doble o el triple, pero un Cassandra bien implementado cambia el orden de magnitud, a 10 o 100 veces más rápido.
Por eso la comparación MySQL, PostgreSQL u Oracle no tiene sentido. Uno puede ser más rápido que el otro, pero con Cassandra es mucho más rápido aún.
Los "tesnicos" creo que lo tenemos claro. Para los menos expertos, no penséis que un Cassandra es lo que necesitáis. Solo tiene sentido en sites con un tráfico "brutal" de transacciones simultáneas. Para la gran mayoría, cualquier buen SGBD es válido.
#33 Tienes razón, pero igualmente la comparación de la santísima trinidad de BBDD con Cassandra tampoco tiene sentido, pues aunque sea más rápida, su propósito es muy distinto, más específico y no tan genérico, al de la triada ¿no?
#33 El tema es que eBay/Paypal tira de Oracle, que tiene muchas más consultas que Digg, su base de datos anda en el rango de los Petabytes (Digg, si no recuerdo mal, no llega al terabyte) y cumple ACID. Y mientras a muchos talibanes del NoSQL se les llena la boca de que "SQL no escala" o "el modelo relacional no escala".
Para los menos expertos, no penséis que un Cassandra es lo que necesitáis. Solo tiene sentido en sites con un tráfico "brutal" de transacciones simultáneas.
Exacto. Y donde la integridad de los datos, su actualización en tiempo real y la atomicidad de las transacciones tampoco es crítica. Es decir, Facebook y pocos más, donde no te importa ver un post 1 segundo antes que después, donde si se pierde un post de cada 10.000 nadie va a morir o a perder dinero, donde no importa que queden datos "sueltos", sin "relación" con otros en la BDD, donde la proximidad temporal es muy fuerte.
Las soluciones NoSQL por lo general son de muy bajo nivel (de abstracción, por si alguien se extraña) y tienen usos muy concretos con volúmenes de datos y proporciones de consultas muy peculiares, todo tan específico que realmente son cuatro peces gordos los que pueden justificar su uso. Y Digg no es uno de ellos.
#39 Y mientras a muchos talibanes del NoSQL se les llena la boca de que "SQL no escala" o "el modelo relacional no escala".
Me juego una cerveza a que a los talibanes también se les atasca la recursividad, la programación en paralelo, multihilo etc...
#42 Como ya dije en el post, (ese que no te has leído hasta el final),
Lógicamente la entrevista no entra en los detalles, así que puede ser una decisión brillante...y de todas formas el hecho de tener los 3 data centers separados puede ir en esta línea y explicar la decisión,
pero lo que se comenta en ella no tiene nada que justifique la decisión que han tomado...
¿Tú crees que Digg tiene el mismo volumen de datos que Amazon? ¿Crees que una aplicación de datos de localización va a tener ese volumen de datos? ¿que no le importa que se pierda algo? Deberías leer el post #39.
De hecho lo que se quejan es de hacer esto http://www.codefutures.com/database-sharding/ y para ese volumen de datos no entiendo la queja salvo que no quieran gastar en determinado software, tengan problemas que no comentan en el artículo o simplemente vayan "a la moda".
Señor #44 si lo mio es una falacia la que hace #37 "o no entienden los SGBD relacionales y han hecho una mierda con MySQL, (más que probable)" no se como nombrarlo. Por cierto son sus argumentos que no se pueden comprobar y que no me valen, básicamente por que diga que sabe mucho. Es decir, el se convierte en la autoridad por que dice que gestiona un sistema 30000 transacciones por segundo con MS SQL Server 2005.
Lo único que he dicho y estoy de acuerdo #39 (esto va #43) que supongo que es una solución que les sirve a ellos y que puede ser generalizado para solucionar cosas parecidas.
Leeros esto http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf y http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/es//papers/bigtable-osdi06.pdf. Anda si google también implementa algo parecido.
Encontareis más o menos la filosifia de estos sistemas y el por qué.
Solo digo con el argumento "a la moda" no me parece un el mejor, porque también se puede considerar a la moda las bases de datos relacionales.
#46 Google procesa petadatos... y no importa si la respuesta a una búsqueda es ligeramente diferente según de dónde y cuándo consultes, así como si se pierde algo pequeño...espérate a que se pierda tu noticia al publicarla. ¿Te gustaría dar de alta dos veces la noticia en Menéneame?
En fin de todas formas es posible que tengan motivos que no comentan en la entrevista, el tema de hardware puede ser uno, como el de no querer usar software privativo, por el motivo que sea.
#45 A ver, un consejo, lee las cosas antes de hablar sobre ellas. En tu anterior post ya se veía que no lo leías, pero ahora dices que lo gestionas cuando lo estoy revisando, (y así lo hago notar en el post). Además es en respuesta a alguien que ha dicho que para miles de transacciones los sistemas relacionales no sirven. Simplemente le indico que pueden tranquilamente con miles de transacciones.
Es decir, está claro que no lees los posts en detalle, (la otra opción es que tengas problemas de comprensión lectora, pero supongo que es más adecuada la anterior).
Lo que indico en mi post básicamente es:
- en la entrevista no da una sola buena razón para no usar SGBD relacionales, ¡ni una!, comento cada punto que aparece en la misma con el que no estoy de acuerdo y, a pesar de eso indico, que es posible que haya buenos motivos, pero que claramente no están expuestos en la entrevista.
En cuanto a tus justificaciones, ¿aportas algo? ¿datos? ¿experiencia? ¿argumentos? No, tus únicos argumentos habían sido que "si ellos lo hacen cómo se atreve a criticarles"...como te han indicado, eso es una falacia y ahora simplemente entras a criticarme como si me arrobara de "autoridad por gestionar" ...es decir no das datos y ahora atacas a mi persona, ¿te doy envidia?...y los links que pasas en el de google más claro no puede empezar:
(...)petabytes of data(...) y ni Digg ni la empresa de geodatos usan esos volúmenes...
Los SGBD relacionales aportan cosas muy claras, como por ejemplo transacciones ACID, no son tanto moda, como algo confiable y efectivo.
Bueno, ya que estamos "criticones", es "leeos" y no "leeros", y por cierto, aprende a puntuar.
http://www.rae.es/rae/gestores/gespub000018.nsf/(voAnexos)/arch8100821B76809110C12571B80038BA4A/$File/CuestionesparaelFAQdeconsultas.htm#ap9
#47. Era yo quien decía que ningún SGBD se tragaba miles de transacciones. Quizás me quedé corto. Pongamos "cientos de miles". Aún así, ¿Seguro que puedes aguantar 30.000 transacciones/segundo? Es que me sale un tiempo medio de transacción de 33 microsegundos...¿No hay caches por en medio? ¿o técnicas que gestionen colas? ¿Datos reales, o un benchark sintético del estilo "for (i=0;i
#48 Un poco corto sí en este post estoy más de acuerdo
Tenemos esos tiempos, porque la verdad, tenemos un maquinón bien gordo, que afortunadamente áun podría ampliarse, y llevas razón en lo de mejoras lineales. Los resultados que tenemos son porque se traga varias decenas de miles de inserts / deletes /updates por segundo sin problema.
Si estoy aquí es porque a pesar de la potencia tenemos problemas, pero son de otra índole, al diseñar la aplicación hicieron algo, (que no debo decirte), que hizo que al agregar usuarios al sistema el aumento del consumo de recursos sea exponencial...no te puedo dar más datos por ser privados.
Si andáramos con datos por los petaflops, tipo Google, y además tuviéramos la aplicación distribuida por el mundo ya te digo yo que esto no habría forma racional de ampliarlo.
Se podría hacer, si no recuerdo mal hotmail está montado sobre BB.DD. relacionales, pero uffff uffff uffff no nos quedaría más remedio porque no podemos perder datos y el orden tiene importancia para nosotros....no nos vale Cassandra...¿tal vez BigTable? no he leído lo suficiente sobre ello pero tiene buena pinta.
Hombre, yo no diría que Cassandra no es buena práctica...es buena práctica cuando realmente justifica su uso, cosa que en la entrevista no se demuestra, pero sí se critica los SGBD relacionales de forma injusta y desde mi punto de vista me aparenta ser más por moda que por ser algo correcto desde el punto de vista de la arquitectura...al fin y al cabo la arquitectura se diseña para una carga determinada.
#47 no hablaba de google respecto a las busquedas, sino sobre App Engine. Si no lo conoces, digamos que es un hosting "en la nube", que te permite subir tu propia aplicacion web, pero solo puedes usar la base de datos que ellos te proporcionan (no relacional), entre otras limitaciones.
Que yo recuerde no dicen nada de duplicación de datos (a no ser que por ejemplo el usuario envie dos veces lo mismo, o se registren dos con el mismo nick a la vez, o cosas asi (hay metodos para disminuir la probabilidad), fruto de la inexistencia de resticciones mas alla de la clave primaria). De todas formas, para digg o para meneame, no supone ningun tipo de problema que una noticia saliese dos veces, o incluso, que borrasen todas las noticias mas viejas de un año y los comentarios... seguiria funcionando igual de bien y casi nadie se daria cuenta. Ahora, como eso ocurra por ejemplo, en un banco o en cualquier otro sitio donde los datos y la coherencia de estos sea fundamental, se lia parda.
#50 A ver que yo no digo que Cassandra no les sirva, lo que digo es que lo comentado en la entrevista no justifica el cambio y el comentario que hacen sobre las SGBD relacionales como no escalables no es verdad. Al menos para el volumen de datos que manejan.
#51 Pues sí, es algo soez y la verdad que fuera de tono...se me escapó lo que siento cada vez que alguien me dice que los SGBD relacionales no escalan, y me lo han dicho para sistemas liliputienses
#52 Hombre, yo utilizo peores expresiones cuando me hacen instalar aplicaciones complejas en producción sin ni siquiera un misero README (Si, directamente en producción y un viernes por la tarde, sin nadie de guardia el finde).
)
Lo que la gente de meneame le faltan excusas para pasar del debate a la trifulca, así que intentaba que viese que el tono del comentario no invalidaba el argumento que diste.
(liliputienses
#53 Eso, instalando "con un par" ¿pruebas? ¿backup? ¿plan de contingencia? ¿soporte? ¿documentación?
¡¡Eso es para nenazas!!
Lo de liliputienses es que es verdad, te encuentras con que 2 GB de datos les acojona, y una tabla con 2 M de registros les parece eterna....y te empiezan a decir, "ponemos una tabla para cada año".... vamos que NPI tienen de lo que ofrece un SGBD relacional y lo terrible es que luego te dicen "es que SQL Server no nos dio lo que necesitábamos" ...lo miras y lo 1º que ves es tablas sin índices que no respetan ni la 1ª regla de normalización..."es que es por el rendimiento"
Terminas de arreglarlo, dejas el rendimiento en milisegundos en las consultas y soporta hasta la 4ª regla de normalización y entonces se excusan "es que eso es cosa de un DBA"....y piensas "¿pero qué cojones has estudiado tú piltrafilla? ¿te regalaron el título de ing. superior?" y mientras piensas eso te hablan de Entity Framework de NHibernate, de Cassandra, de.... y piensas, "Cualquier cosa menos aprender ¿verdad?" y no es que no puedan ser útiles, pero ¿de qué te sirve NHibernate si no sabes lo que hay debajo?
#45
Apreciado #45 :
La frase de #37 "o no entienden los SGBD relacionales y han hecho una mierda con MySQL, (más que probable)" puede ser un poco soez, pero expone un argumento: Una BBDD relacional puede aguantar esa carga, y lo hace con un hecho: Las 30000 transacciones/s en su equipo.
En ciencia esta afirmacion se podria comprobar replicando su configuración y testeando con un benchmark de 30000 transacciones (con factores de corrección en función del hardware que use claro). Se que es dificil, pero las alternativa de suponer que miente o se equivoca...no serian logicas.
O puede atacar su analogia dando motivos por los que no podria escalar a partir de esas 30.000 trans/s
Y sin querer faltarle, la frase "si lo mio es una falacia la que hace #37 ... no se como nombrarlo" es un "tu quoque" de libro. Aunque la carga emocional inherente a " han hecho una mierda " enturbia un debate lógico.
#37 Que te crees que eres el único que sabes de SGBD. Y que la gente digg es inepta. Bueno yo no diría tanto. Otra cosa Cassandra viene de un sistema privativo que utiliza Amazon. Digamos que Amazon también son unos ineptos. Yo creo que la gente por aquí habla demasiado.
El #33 dice algo de verdad NoSQL no se debe utilizar para todo, por que no sirve para todo. Pero lo mismo se tiene que aplicar con base de datos relacionales, no sirven, para todo o es la mejor solución para todo. Más vale no ser taliban en estas cosas.
#42 Sin entrar en si #37 tiene razón o no, lo que haces es una falacia ad verecundiam (apelar a la autoridad/respeto ). Solo pq lo hagan digg i amazon no significa que tengan razón. #37 ha dado argumentos, rebatelos si los ves incorrectos.
El titular se presta a confusión. No compara MySQL con PHP. Compara las bases de datos SQL con las que no lo son (noSQL).
#11 -> #36
Muchas explicaciones (y muy interesantes, con el tema Cassandra vs MySQL), pero va al grano en el punto 4 del post.
Impresionante y casi que no termino de creerme como puede haber tanta diferencia metiendo "un paso más" en el proceso de la información.
Claro que por el titular parece que podría estar al alcance de cualquiera que sepa PHP, pero leyendo el punto 4 como bien dice #1 se ve que no es una simple ordenación sino una serie de normas a seguir que le quita gran parte del procesamiento al gestor de bases de datos MySQL como evitar el uso "básico" de JOINs o claves ajenas... digamos que se convierte una Base de Datos relacional en una no relacional, quitándole "realismo" y mucha mucha comprensibilidad.
Para mi esta es una solución para sistemas a gran escala en los que el rendimiento se vuelve crucial y un método como este puede ahorrar millones y millones de euros, pero para sistemas a pequeña o media escala yo apostaría siempre por una mejor estructuración y diseño lógico realmente comprensible de la base de datos y de la aplicación en general =)
#2 Totalmente de acuerdo. Para una PYME lo caro es el programador, no el hardware.
#2 Es que usar MySQL como referencia de rendimiento es de risa, y más teniendo en cuenta JOINs, porque la tecnología más moderna que usa MySQL para optimizarlos se llama "producto cartesiano". Eso sí, para un blog y webs chorras sobra, para qué engañarnos.
Que los de Digg se dejen de Cassandra y de que si SQL no escala, y que utilicen un SGBD de verdad como PostgreSQL, Firebird o incluso (¡invocando negativos!) Oracle o MS SQL Server. En serio, hay órdenes de magnitud de diferencia entre MySQL y el resto en cuanto entran en juego consultas mínimamente complejas.
#12 Es lo que tiene hacer aplicaciones gordas, con aplicaciones de juguete.
#12 Si tu solución para escalar desde MySQL es pasarse a PostgreSQL... FFFFFFUUUUUUUUUUU
Eso sí que es un porcentaje.
Como decía Pazos, lo importante es el "concepto".
Los Cassandras y similares tienen su utilidad cuando estamos hablando de miles de transacciones por segundo. Cifras que ninguna base de datos puede asumir, por muchas máquinas que tengas.
Por decirlo de alguna manera, más que ser un servidor, son una especie de nube de datos Peer to peer. Varias máquinas colaboran entre ellas para ir guardando la información, manteniendo todo lo que pueden en memoria, para acelerar lecturas futuras. Cuando no tienen un dato, buscan alguna máquina vecina que pueda tenerlo, para evitar usar los discos. Y el sistema es superescalable, se pueden añadir o quitar máquinas a voluntad.
Como resumen. Si un MySQL hace 100, un Postgres 200 y un Oracle 400, eso hace 1000.
#24
Los Cassandras y similares tienen su utilidad cuando estamos hablando de miles de transacciones por segundo. Cifras que ninguna base de datos puede asumir, por muchas máquinas que tengas.
El sistema que estoy revisando ahora se traga sin queja más de 30000 transacciones por segundo con MS SQL Server 2005 en un servidor blade con una SAN, RAID 5 con discos de 15000rpm con 5 unidades lógicas. Además tanto el servidor, como la SAN son compartidos por otros sistemas.
Si cambiáramos los discos por SSD podríamos mejorar un 40% y si añadiéramos discos SSD podríamos hablar de más del 100% o lo que nos dé la gana hasta llegar al límite de la SAN.... no veo el problema de rendimiento en SGBD relacionales.
Lo que veo es gente que se va por los cerros de Úbeda cuando no saben pensar en el sistema como un todo.
Aún así ¿MySQL? para ese volumen se queda corto, MS SQL Server, Oracle, DB2 esos sí pueden con ese volumen.
Leyendo el artículo he pensado que esta gente tiene un problema diferente...o no entienden los SGBD relacionales y han hecho una mierda con MySQL, (más que probable), o bien necesitan tener los datos distribuidos globalmente y sus comunicaciones no son todo lo buenas que necesitarían para ello.
En principio apunto a la 1ª opción.
Comentaré en función de lo que mejor conozco, MS SQL Server, y sobre los puntos de la entrevista:
1º. (...)Using Cassandra they've built two clusters: one for indexes and one for record(...)
En SQL Server la práctica es separar índices y tablas (registros) en filegroups diferentes, con lo que lo que están separados. Si el índice contiene los campos de las queries más comunes, consigues el mismo efecto....amén de que lo puedes separar también fraccionando tanto la tabla como los índices en filegroups diferentes...no veo mejora en lo que han hecho comparado con lo que da SQL Server.
2º (...)Restrict what the user can do. The system is kept simpler by not allowing open ended queries. (...)
No veo nada que afecte a escoger SGBD en esto.
3º The relation tool chain has failed for real-time (...) so why bother? (...)
Este es el quid de la cuestión, que no acaban de ver cómo hacerlo y no quieren preocuparse...bueno, cuando empiecen a salir incosistencias que lo disfruten, ellos y los usuarios.
4º Scaling practices turn a relational database into a non-relational database
Los coj.... 1º normalizas, y luego desnormalizas con vistas indexadas, y aprovechando que las queries son predefinidas es útil tener índices de cobertura y procedimientos almacenados. Si lo montas bien no tienes problemas de rendimiento en ese sentido.
Los puntos 5º, 6º y 7º no los veo descabellados, pero de la entrevista no saco nada que me haga pensar que han tomado el camino correcto. Lógicamente la entrevista no entra en los detalles, así que puede ser una decisión brillante...y de todas formas el hecho de tener los 3 data centers separados puede ir en esta línea y explicar la decisión, pero me sigue oliendo a "moda" de desarrolladores que no saben de SGBD relaciones.
Los que usamos Wordpress en hosting virtual, estamos bastante quemados con la ineficiencia de MySQL, y con la ineficiencia de los scripts. En el momento que las BB.DD. crecen los joins de tablas grandes provocan demandas gigantescas. Yo estoy buscando un proveedor de hosting virtual que admita mucha caña a MySQL, y que tenga buena atención al cliente, porque poco a poco me voy hundiendo en un pozo del cual no sé como salir. Reescribir los scripts como dice un listo, no me parece una opción realista para resolver estos temas. Si no lo hace Wordpress, no vamos a hacerlo cada uno de nosotros de forma independiente.
Me quedo loquer : y yo pensando que MySQL 5 podría ser considerado un SGBD y usándolo como tal con sus procedimientos almacenados y tal para obtener el mejor rendimiento
Alguien puede explicar un poco como es eso que ordenan con php y no con sql ?
No tengo mucha idea de sql, pero siempre ha sido mejor paginar y ordenar con sql... es más, simplemente por el hecho de paginar, si se quiere que además sea un resultado ordenado... ó se ordena antes de paginar o te traes el resultado entero y se ordena y pagina en la aplicación, pero eso esta lejos de ser rápido ó eficiente.
No lo entiendo. No es que no me lo crea, es que ardo de ganas de saber como lo han hecho
#6 http://www.google.es/search?q=php+sort+array&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:es-ES:official&client=firefox-a
http://nosql-database.org/
#5: La definicion segun la web que enlazas:
"DEFINITION: Next Generation Databases mostly address some of the points: being non-relational, distributed, open-source and horizontal scalable. The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply as: schema-free, replication support, easy API, eventually consistency, and more."
Genial. Años de avances para volver al DBase.
bueno, google tambien hace algo parecido en app engine, la base de datos es no relacional.
Las cosas como son, cada modelo tiene sus ventajas y sus desventajas. Y aplicadas a un proyecto concreto, esas ventajas y desventajas hacen que sean la mejor opción, o una cosa totalmente inviable.
Y para cosas como Digg, y por el tipo de información y la forma de procesarla que deben tener, la verdad, yo no veo demasiados inconvenientes y si ventajas a un sistema no relacional. (mayor escalabilidad, mas barato en cuanto a hardware por esto, etc).
Yo pensé que MySQL era un nuevo espacio del programa de sobremesa de la Sexta
#19 Si karadecul0, yo también lo pensé.