empresas que usan firebird

[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.

[erickperez6]

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.

Tambien pido disculpas, quizas se me fue un poco la mano, yo invito la tercera ronda si no amanecieron resacados con las dos de ayer

[erickahr]

Hola compañeros, antes que nada buenas tardes (aqui en México), y yo invito la ronda de la 'curacion' porque para estas fechas ya estarán en la resaca de las rondas que mencionaron anteriormente .

De antemano comentarles que tengo poca experiencia, pero he tenido la oportunidad de trabajar con MySql, y con Firebird... la verdad me quedo con Firebird, actualmente administro una base de datos de mas de 28 gb, y tengo en ella dos tablas criticas de las cuales una cuenta con mas de 81 millones de registros y la otra con mas de 70 millones de registros (Esto tomando en cuenta que se realizan 'cortes de informacion' y conservo solo la informacion concerniente a años anteriores y el actual, es decir ahorita solo tengo informacion de 2009, 2010 y lo que va del 2011... si dejara la informacion completa, que mantengo en respaldos anteriores, podria facilmente superar los 50Gb), de momento funciona bien, pero si les comento que hay ciertos reportes que se comienzan a tardar mas en devolver respuesta, cabe mencionar que mis consultas, las realizo sobre campos indexados de tipo numerico, siempre pendiente del rendimiento de las mismas; al ritmo que esta creciendo la empresa, me doy cuenta que en relativamente poco tiempo podria tornarse caotico, asi que me veo obligado a cambiar la forma de trabajo.

Acudo a los expertos de CD para solicitarles que me iluminen acerca de que ideologia podria adoptar para optimizar el rendimiento de mi BD, tanto para el manejo transaccional, como para el manejo de reportes del nivel administrativo...

Utilizo Firebird 2.1 sobre Windows 2003 server, y los clientes corren sobre Windows xp, Vista y 7.

Mi base de datos es alimentada por mas de 200 puntos de venta en todo México, no se como vaya a funcionar cuando lleguen a 500 Puntos de venta

Lei la informacion que posteo Jachguate sobre como Youtube soluciono ciertos problemas, se que la cantidad de informacion y de consultas por dia no hay ponto de comparacion entre mi 'pequeña' base de datos y la cantidad de informacion que manejan esos gigantes como Youtube, pero me surgen muchas dudas.

• Deberia usar acumulados por semana, mes y año separados en diferentes bases de datos, para poder solicitar comparativos anuales, y al mismo tiempo mantener solo los movimientos del año en curso para distribuir la cantidad de registros?
• Seria necesario distribuir la informacion en diferentes servidores incluso?
• De plano, deberia cambiar a un motor mas potente como Oracle?
• Deberia cambiar el SO del servidor?
• Como manejan su informacion las grandes cadenas, como Wal*Mart, Chedraui, etc.?

La verdad estoy un poco confundido, espero y me puedan aconsejar o recomendar algo para poder tomar un rumbo