empresas que usan firebird

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

[Casimiro Notevi]

Bueno, bueno... son muchas cosas a tener en cuenta, que habría que estudiar detalladamente en tu caso, ya sabes que cada caso es diferente y es muy difícil acertar dando soluciones generalizadas.
Para empezar, por los reportes que dices que son algo lentos, habría que saber qué hacen esos reportes, qué generador de reportes usas, etc. además de pequeños detalles (y muy importantes), por ejemplo, ¿generas vista previa?, ¿haces doble pasada? (para calcular entre otras cosas el "Página x de y"), etc.
Algunso generadores crean unos ficheros temporales en disco que necesitan mucho espacio, cuanto mayor sea el reporte a generar, es conveniente tener espacio más que de sobras y a ser posible en otro disco. Si usas la previsualización será también más lento, obviamente, tiene que generar todas las páginas. En fin, son "truquitos" que hay que ir poniendo en práctica para mejorar el rendimiento.
También depende del tipo de informe, supongamos que es una estadística de ventas del año anterior o de meses anteriores, entonces puede que sea interesante tener un pequeño servidor con el backup último y usar esa BD, en lugar de usar el servidor principal, ya que no necesita los datos actuales.
Continuando con tus preguntas:

Empezado por erickahr

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?

Esto se responde con lo que he comentado antes, puede ser interesante mantener tablas con acumulados, por lo que las consultas serían instantáneas. Esos acumulados se programan en la BD, mediante triggers, así que todo el trabajo lo haría la propia BD y nos despreocuparíamos nosotros.

Empezado por erickahr

Seria necesario distribuir la informacion en diferentes servidores incluso?

De momento no creo que sea necesario, aunque estaría bien tener un servidor de reserva, como he comentado antes, para cosas "anexas" que no recarguen al servidor principal, cuando sea necesario.

Empezado por erickahr

De plano, deberia cambiar a un motor mas potente como Oracle?

En principio, no, ten en cuenta que con oracle vas a tener que poner un servidor muy GRANDE, en tu servidor actual se quedará pequeño, así que si vas a necesitar un servidor más grande, aprovecha para instalar Firebird, seguro que te lo agradece.
Es curioso lo habitual que son comentarios del estilo: "Mi BD va lenta, voy a tener que poner un oracle y un servidor nuevo". ¡¡¡Jod...!!!, pues ponle el nuevo servidor a tu BD actual, verás como lo agradece.
Ten por seguro que tu servidor actual, (y no tengo ni idea de cual es), si montas oracle en él, es seguro que va a ir mucho, mucho más lento que firebird. Por lo que necesitarás un servidor más grande sólo para que vaya igual que el actual con firebird. Pues entonces monta firebird en uno más grande (grande=potente).

Empezado por erickahr

Deberia cambiar el SO del servidor?

Respuesta corta: SI.
Respuesta larga: Por supuesto que SI.
Bromas aparte, te garantizo que si instalas linux en tu servidor actual puedes incrementar su rendimiento, como mínimo, un 30% aunque normalmente será más.
No has dicho qué servidor tienes, pero es primordial tener uno en condiciones, igual que lo tendrías que instalar si pusieras oracle.
Servidores dedicados de 4 u 8 cores, cuanta más memoria ram será mejor, discos de 10000 ó 15000 rpm, por supuesto RAID 5 al menos, un NAS de red también en RAID5 para mantener backups, etc.
El sistema debe estar particionado para mantener la BD en una partición, ficheros temporales en otro disco (puede ser el NAS), recuerda que tanto firebird como la mayoría de gestores de informes/reportes usan ficheros temporales y es conveniente que estén en otro disco que no sea el de la BD. No en otra partición (porque sería el mismo disco), sino en otro disco diferente.
En mi trabajo, a los clientes más grandes, se les instala de esa manera, grupos de discos RAID5 la BD, otro para los temporales, otro externo para backup, etc.
Resumiendo, poner un servidor profesional, y por supuesto, Linux.
Si hay algo que une a las empresas que se han citado antes en este hilo, google, wikipedia, etc. es que todos usan sin excepción servidores linux. También sabrás que casi todos los superordenadores más potentes del mundo funcionan con linux, como no puede ser de otra forma.

Empezado por erickahr

Como manejan su informacion las grandes cadenas, como Wal*Mart, Chedraui, etc.?

No tengo información sobre ellos, pero los que he citado antes, además de amazon, casi todos los servidores webs del mundo, etc. funcionan con linux. O con alguna versión '*nix', que viene a ser lo mismo.
En España, la cadena de supermercados Mercadona, que factura más que Erosky y Carrefour juntas, usan Linux desde hace años.
Sabrás que Firebird funciona en linux, solaris, hp-ux, macosx, windows, etc. así que no tendrás ningún problema en instalarlo en cualquier ordenador, desde los más pequeños hasta los más grandes superordenadores/mainframes del mundo.
Por supuesto, instala en linux la versión classic server o la última versión superclassic.

Bueno, si después de todos esos cambios, todavía te resulta lenta... todavía hay mucho que hacer, "afinar" las consultas sql. En mi trabajo nos encontramos hace varios años con las estadísticas acumuladas de varios años que tardaban un poco más de lo recomendable. Se dedicó un tiempo a estudiarlas bien, a depurarlas, afinarlas, simplificarlas, etc. y actualmente esas estadísticas pueden ser de las consultas más rápidas de la gestión, incomprensiblemente

Cuando ya tengas tanta información que te sea imposible gestionar con firebird, a pesar de usar un servidor como un camión de grande, entonces puede ser el momento de pasar a.... ¡¡¡postgresql!!!, pero no a oracle.
¿Por qué?, pues porque con postgresql tienes más facilidades que firebird para instalar clusters de servidores y repartir la carga entre ellos, pero en fin, con un servidor "decente" actual, de entre 4 y 16 cores, instalándole unos buenos 16 a 64 GB de ram y un buen sistema de discos en raid... creo que tienes firebird para rato, sin oracle. Sólo con las licencias de oracle ya te puedes comprar un superservidor enormemente monstruoso.

En fin, todo esto es información muy generalizada, muy superficial, habría que estudiar cada apartado con detalle para "dar en el centro de la diana"

[jachguate]

Hola, tremendo y viejo hilo que se ha revivido, un saludo a todos los entrañables amigos que van participando por aquí!!

Estoy algo corto de tiempo y, aunque me gustaría, no he tenido ocasión de leer con detenimiento lo que ya se ha mencionado en respuesta a la pregunta de erickahr.

Solo decir que, como bien ha dicho ya mi estimado casimiro es algo aventurado dar respuestas genéricas y por eso, no entraré en mayores detalles. Solo mencionar que si que hay diversas técnicas que se pueden aplicar para encontrar una solución. Como buen DBA (te guste o no, estas llevando ese rol, quizás aparte del de desarrollador y otras cosas), debes aprender a pensar en función de "cuellos de botella".

Cuándo una aplicación está respondiendo más lento de lo que esperarías, usualmente es porque hay un cuello de botella... es decir, tenes cierta cantidad de información y cierta "potencia" en el hardware para procesarla... todo el sistema será tan rápido como el punto del proceso por donde más lento pase la información. Cosas a tener en cuenta son muchas, y varían de acuerdo a cómo tenes configurada la base de datos, cómo se realizan las consultas, etc. Hay que empezar por lo básico, como por ejemplo comprender al optimizador del motor y escribir las consultas de manera que los planes sean óptimos, evitar full table scans, etc.

Cosas a tener en cuenta son:

• I/O (de nada sirve tener ocho nucleos y 40 Gb. de RAM, si los discos son lentos, hay contención o serialización de operaciones a nivel de I/O (por ejemplo, por tener una sola controladora)). Lamentablemente Firebird no ofrece el grado de control que ofrecen otras bases de datos para manejar esto al antojo del DBA, pero si que puede hacerse algunas cosas.
• Procesador. Puede que tengas 16 nucleos, pero que la base de datos solo pueda sacar provecho de uno (especialmente cierto con firebird).
• RAM. En el servidor de base de datos, es bueno tener mucha RAM, y es mejor sacarle provecho. He visto casos donde el dueño del negocio se ve obligado a comprar un servidor con 8, 16 o más GB de RAM, pero cuando revisas Firebird está tirando solamente de un par de ellos. (especialmente cierto con Firebird)
• Memoria Virtual: Esto podría ser parte del punto anterior, del que se desprende otro tema importante. He podido ver en ocasiones servidores de bases de datos con X cantidad de RAM, pero la base de datos está configurada de tal manera que requeriría Y cantidad de RAM, donde Y > X, por lo tanto, el generoso sistema operativo decide hacer uso de la memoria virtual (especialmente cierto con servidores windows). Todo bien, pero lo malo de esto es que mientras el acceso a RAM es del orden de los GB/s, el acceso a disco es cientos o miles de veces más lento. Esto trae al traste la caché de la base de datos que termina por leer de disco lo que supuestamente está en memoria, con la carga adicional de tener que escribir primero al disco alguna página para hacer espacio en RAM... un desastre total.
• Sistema operativo: Quizás lo creas o no... pero el mismo firebird corriendo sobre el mismo hardware en un linux es más rápido que corriendo en un servidor windows. Cuanto más rápido, depende de muchos factores como para aventurarse a dar un número, pero en mi experiencia he llegado a ver casos en que son hasta 50% o 60% más rápidos.
• Mil factores más... no terminaría. Me detendré aquí... me encantaría seguir y me vuelan las ideas.... pero debo llevar los frijoles a mis polluelos y dejar terminadas algunas cosas antes de salir de viaje en menos de 24 horas.

Empezado por 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 .

Esto es cierto? jajaja, estaré dentro de algunas semanas en tu tierra (DF), lamentablemente poco tiempo, pero quizas podamos llevar esto del plano virtual al plano donde la chela surte sus efectos... ajjaja.

Un saludo y hasta luego.