empresas que usan firebird

[[Al González]]

¡Hola!

Empezado por erickperez6

Yo no me invento nada, no es falso, la verdad es que si hay muchas empresas que tienen base de datos gigantescas trabajando en mysql, solo googleate un poquito y te daras cuenta, aqui te doy dos enlaces para que le digas a ellos que es falso, no a mi. Quizas ellos sean unos mentirosos y tu tengas razon, ...

¿Y dónde dice que sean bases de datos "gigantescas"? ¿Cómo sabes cuál es el tamaño de esas bases de datos?

Por otra parte, ya se ha comentado antes que Google y otros grandes sitios utilizan MySQL para algunas operaciones de almacenaje, pero no para sus motores de búsqueda, ya que en eso requieren mayor potencia.

En cuanto a las caritas de risa, desconozco si son una especie de burla o de verdad algo te pareció gracioso.

En fin.

[jachguate]

Empezado por Al González

¿Y dónde dice que sean bases de datos "gigantescas"? ¿Cómo sabes cuál es el tamaño de esas bases de datos?

Hola Al.

No dudo que pueda haber bases de datos bastante grandes, aunque no haya información sobre ello.
El caso de AdWords, es un buen ejemplo. Google tiene millones de clientes AdWord/AdSense... y no imagino la cantidad de consultas por segundo que esté recibiendo para colocar la publicidad en cada impresión de página web que ocurre de cada uno de estos sitios.

Pero... ¿es una única base de datos o muchas bases de datos con información replicada o segmentada de alguna manera?. no lo dudo.
También muchos de estos sitios (la wikipedia, slashdot, por ejemplo), usan caches que son usados para no tener que consultar la base de datos por cada hit que ocurre. Entonces, aunque un sitio sirva 200 millones de páginas al día, eso ni significa 200 millones de páginas generadas directamente desde la base de datos.

Creo que también queda claro que la arena de mysql son, principalmente, las aplicaciones web: simples, sin mayores requerimientos transaccionales, y con una complejidad mas bien mediana. Eso si, con muchos millones de páginas servidas por día.

Leí una vez un comparativo, lamentablemente no recuerdo donde, que estimaba que firebird escalaría mejor que mysql con muchos usuarios concurrentes. Lo hacía en base a los resultados de una serie de pruebas. Como digo, lamentablemente no recuerdo donde vi eso.

Hasta luego.

[erickperez6]

¿Y dónde dice que sean bases de datos "gigantescas"? ¿Cómo sabes cuál es el tamaño de esas bases de datos?

Parece que no leiste bien o no interpretas lo que dicen los enlaces que puse adjuntos:

• flickr, Using MySQL to manage millions of photos and users
• NetQOS, embeds MySQL to manage the world's largest networks including Chevron, American Express and Boeing.
• Friendster, in 2005 more than 85 million dynamic page views per day, able to support more than 1.5 billion MySQL queries per day
• Wikipedia, in early 2005 more than 200 million queries and 1.2 million updates per day with peak loads of 11,000 queries per second

No es necesario ser muy inteligente para saber que todos estos casos superan los GB facilmente, quizas el dato exacto de que sean 20gb, 40gb, etc... solo es cuestion de indagar un poquito mas en las fuentes y en la pagina oficial de mysql y los numeritos aparecen. Pero el punto es que evidentemente son base de datos "gigantescas". Pero por lo que veo eres una persona que aunque te busque las fuentes no entraras en razon, y contra eso yo no puedo luchar.

Pero en fin, creo que muchas personas subestiman demasiado a mysql o son muy enemigos de la misma o quizas es que estan un poco desinformados y no sabian que se utilizaba para sistemas criticos y alta albergadura, nos guste o no nos guste es asi. Pudieran usar firebird, por que no? quizas el redimiento fuera superior, eso no lo dudaria... pero no lo usan.

Ya que te gustan los numeritos Al González, aqui puedes ver un articulo con cifras de base de datos que superan los 30gb en mysql de friendfinder.com

http://www.mysql.com/news-and-events...endfinder.html

Tambien el sistema de youtube esta montando en mysql (les preguntamos que tamaño tiene por si las dudas? los videos son almacenados en la DB)

http://video.google.com/videoplay?do...64351441328559
http://blip.tv/file/537790

Por otra parte, ya se ha comentado antes que Google y otros grandes sitios utilizan MySQL para algunas operaciones de almacenaje

Sobre lo de google, en los enlace que puse dice claramente que se utilizan algunas herramientas importante, en ningun lado dice que es el gestor de busqueda.

Por cierto, el gestor de busqueda de google creo que esta montado en BD2 de IBM, si consigo la fuente se los confirmare, no recuerdo donde fue que lei el articulo hace un tiempo.

[jachguate]

Empezado por erickperez6

No es necesario ser muy inteligente para saber que todos estos casos superan los GB facilmente, quizas el dato exacto de que sean 20gb, 40gb, etc... solo es cuestion de indagar un poquito mas en las fuentes y en la pagina oficial de mysql y los numeritos aparecen. Pero el punto es que evidentemente son base de datos "gigantescas". Pero por lo que veo eres una persona que aunque te busque las fuentes no entraras en razon, y contra eso yo no puedo luchar.

Hola.

NO veo la razón de atacar personalmente a Al. Estas dejando ver que no es una persona inteligente, pero francamente no creo que eso sea cierto ni que vos tengas suficientes argumentos para afirmar tal cosa.

Empezado por erickperez6

no sabian que se utilizaba para sistemas criticos y alta albergadura

francamente, me pregunto que quisiste decir con esto..

Empezado por erickperez6

Tambien el sistema de youtube esta montando en mysql (les preguntamos que tamaño tiene por si las dudas? los videos son almacenados en la DB)

¿de donde sacas la información para afirmar tal cosa?
Mis fuentes dicen algo distinto:

YouTube uses MySQL to store metadata....
To scale out the database, they first used MySQL replication. Like everyone else that goes down this path, they eventually reach a point where replicating the writes to all the DBs, uses up all the capacity of the slaves. They also hit a issue with threading and replication, which they worked around with a very clever “cache primer thread” working a second or so ahead of the replication thread, prefetching the data it would need.

As the replicate-one-DB approach faltered, they resorted to various desperate measures, such as splitting the video watching in to a separate set of replicas, intentionally allowing the non-video-serving parts of YouTube to perform badly so as to focus on serving videos.

Their initial MySQL DB server configuration had 10 disks in a RAID10. This does not work very well, because the DB/OS can’t take advantage of the multiple disks in parallel. They moved to a set of RAID1s, appended together. In my experience, this is better, but still not great. An approach that usually works even better is to intentionally split different data on to different RAIDs: for example, a RAID for the OS / application, a RAID for the DB logs, one or more RAIDs for the DB table ...

In spite of all these effort, they reached a point where replication of one large DB was no longer able to keep up. Like everyone else, they figured out that the solution database partitioning in to “shards”. This spread reads and writes in to many different databases (on different servers) that are not all running each other’s writes. The result is a large performance boost, better cache locality, etc. YouTube reduced their total DB hardware by 30% in the process.

It is important to divide users across shards by a controllable lookup mechanism, not only by a hash of the username/ID/whatever, so that you can rebalance shards incrementally.

Ves que no ha sido sin dolor cómo han llegado a una solución que les funcione... y como se puede leer en el artículo completo, por supuesto usan caches para bajar la carga en la base de datos. De hecho, usan memcached, que en las primeras dos líneas de su página dice:

memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

fuente

Empezado por erickperez6

Por cierto, el gestor de busqueda de google creo que esta montado en BD2 de IBM, si consigo la fuente se los confirmare, no recuerdo donde fue que lei el articulo hace un tiempo.

Nada mas errado que esto. No usan ninguna base de datos comercial, ni relacional... tienen su propia solución al asunto, como era de esperarse. Por cierto, youtube también usa BigTable.

Francamente, creo que Al y los demás miembros de este club merecen una disculpa por el ataque personal.

También es de esperar que, en próximas oportunidades, confirmes tus suposiciones antes de hacer afirmaciones en estos foros, y con mayor razón si las afirmaciones son en tono ofensivo.

[[poliburro]]

Empezado por jachguate

Hola.


También es de esperar que, en próximas oportunidades, confirmes tus suposiciones antes de hacer afirmaciones en estos foros, y con mayor razón si las afirmaciones son en tono ofensivo.

Tranquilos muchachos, . mejor vayamos a la taberna por una ronda de chelas.

[jachguate]

Empezado por poliburro

Tranquilos muchachos, . mejor vayamos a la taberna por una ronda de chelas.

Claro!! Ya viste las meseras del día de san valentín...

[[Al González]]

Empezado por poliburro

Tranquilos muchachos, . mejor vayamos a la taberna por una ronda de chelas.

Sale, creo que será mejor. Estaba empezando a considerar los argumentos de nuestro amigo, hasta que comenzó a mezclarlos con sarcasmo, ironía y faltas de respeto. Es una pena, la parte constructiva de su texto se veía interesante.

Saludos.

Al.

[Casimiro Notevi]

Empezado por jachguate

Leí una vez un comparativo, lamentablemente no recuerdo donde, que estimaba que firebird escalaría mejor que mysql con muchos usuarios concurrentes. Lo hacía en base a los resultados de una serie de pruebas. Como digo, lamentablemente no recuerdo donde vi eso.
Hasta luego.

Tampoco recuerdo dónde estaba esa comparativa, aunque sí que guardo los gráficos estadísticos, son estos:





Es de hace unos años, pero son los mismos años para todos ellos.

p.d.: Los números de la izquierda son las conexiones, "normales" y "persistentes"

[[Crandel]]

El problema del uso de las bases de datos, es que la mayoria de los programadores desconocen realmente cual es mejor o peor, y lo realmente importante es cuales son las ventajas de una sobre otras y como se adaptan a nuestras necesidades.

No existen muchos imformes claros con este tipo de comparativas.

Por otro lado muchas empresas no publicitan que herramientas utilizan para desarrollar sus aplicaciones.

Como ejemplo hace muy poco me entero que Mercury Interactive (que ahora forma parte de HP) desarrolla sus aplicaciones con Delphi. Una empresa que en el ultimo año genero ganancias (ojo, dije "ganancias" no ventas) por aprox 100 millones de dolares (no recuerdo el numero exacto, creo era un par de decenas mas).

Otro ejemplo es mi empresa actual, donde se eligio MySQL como servidor de base de datos, realmente por desconocimiento de otras posibilidades y empujado por su popularidad.

Todas la aplicaciones que anteriormente desarrolle (donde pude elegir) utilice firebird, aunque ninguna tienen decenas de GB, funcionan hace varios años sin ningun tipo de problema.

Por otro lado creo que como usuarios, estamos siempre buscando "la mejor" herramienta, mientras en la mayoria de los casos varias se adaptan perfectamente a nuestras necesidades.

En resumen, de los motores de DB, manejo en buen grado tres, MS SQL Server, MySQL y firebird; y aun que todas funcionan muy bien ... me sigo quedando con Firebird

pd: cantinero ... una ronda de firebird para todos, yo invito

[[Al González]]

Empezado por Crandel

...pd: cantinero ... una ronda de firebird para todos, yo invito

Bueno, aunque no estamos en La Taberna todavía, invito yo la segunda ronda y la mejor bebida que tengas Emilio para Erick, a quien le pido una disculpa por cualquier agravio que le haya causado con mis intervenciones.

Un abrazo.

Al.