Firebird: otro caso de estudio

[[poliburro]]

Empezado por rretamar

Technical details

Our largest installation of the Firebird SQL has these attributes:

• Database size: ~70 GB
• Average daily database increase: ~80 MB

http://www.firebirdsql.org/en/case-studies-catalog/masa---statistical-analysis-and-plan-optimization-solution-for-industrial-plants-53264/

mmm como que 80mb es muy poca carga transaccional para ser un caso de estudio interesante. Pero bueno supongo que para una base de datos como firebird lo es.

[juanelo]

Pues yo no sé, pero a mi me parece una cantidad importante de transacciones para la base de datos que uds. me digan.
Creo que porque al menos yo no he administrado una BD mas grande (de hecho nada cercano a esta base de datos), se me hacen números impresionantes.
Saludos.

[Casimiro Noteví]

Empezado por juanelo

se me hacen números impresionantes.

Lo son

[mamcx]

El problema de mirar numeros sin contexto.... lo es? Si fuera un numero mas grande.. es eso mejor? Si la BD es mas o menos normalizada, como esten los indices, se sube o baja todo eso.

Me fui al link y las razones basicamente son : Usamos Delphi, Conocemos FB, Facil de operar.

Pero como eso conecta con los numeros y el resto de los requerimientos no es claro.

Si yo no supiera nada de FB no veo como me ayuda un "caso de estudio" como este. No hay nada que estudiar!

P.D: Estoy criticando el estilo tipico de estos "casos de estudios", no a FB.

[[poliburro]]

Empezado por juanelo

Pues yo no sé, pero a mi me parece una cantidad importante de transacciones para la base de datos que uds. me digan.
Creo que porque al menos yo no he administrado una BD mas grande (de hecho nada cercano a esta base de datos), se me hacen números impresionantes.
Saludos.

Entiendo que por sí solos 80 MB de datos en un día parezcan mucho pero en realidad no lo son amigo en realidad es una cantidad irrisoria de datos y me explico por qué. Entre lo que lista nos dice que se generan en promedio 80mb de datos lo que nos da un promedio de 0.12 mb por minuto en un periodo transaccional de 12 horas. Nada que cualquier base de datos no soporte, vaya algo así hasta dbase lo soporta.

Empezado por Casimiro Notevi

Lo son

mmmm, supongo que para los sistemas que manejas lo son pero cuando se mira un poquito más allá te encuentras con que no es así.


Ahora bien, un entorno transaccional como el que pinta el siguiente caso de estudio sí que es sumamente interesante:

Case Study: Oracle E-Business Suite with Data Guard Across a Wide Area Network
“Data Guard 10g is a complete, reliable, DR solution for the mission critical 7TB database that supports Oracle’s global business operations. High transaction rates, 7,000 concurrent users, and 1,000 miles separating the production and disaster recovery site – not a problem for Data Guard.”

http://www.oracle.com/au/products/da...e-1-131821.pdf


Aquí más casos de estudio de Oracle.

http://www.oracle.com/technetwork/da...es-098033.html

[Casimiro Noteví]

¿Cuántos millones dices que cuesta eso?, ¿cuántas personas de oracle dices que te montan eso en tu empresa y te lo mantienen y te cobran?, ¿cuánto hardware necesitas para mover todo y cuánto cuesta?

Compara con: Vas a firebirdsql.org, ... descargas ... instalas ... a trabajar.

[ecfisa]

Hola poliburro.

Empezado por poliburro

...
Ahora bien, un entorno transaccional como el que pinta el siguiente caso de estudio sí que es sumamente interesante:

Case Study: Oracle E-Business Suite with Data Guard Across a Wide Area Network
“Data Guard 10g is a complete, reliable, DR solution for the mission critical 7TB database that supports Oracle’s global business operations. High transaction rates, 7,000 concurrent users, and 1,000 miles separating the production and disaster recovery site – not a problem for Data Guard.”

http://www.oracle.com/au/products/da...e-1-131821.pdf


Aquí más casos de estudio de Oracle.

http://www.oracle.com/technetwork/da...es-098033.html

Eso es indiscutible desde todo punto de vista .

Pero si queremos hacer una comparación mas ecuánime, también tendríamos que poner en la balanza este factor: Oracle Global List Pricing

Saludos

[mamcx]

Empezado por ecfisa

Pero si queremos hacer una comparación mas ecuánime, también tendríamos que poner en la balanza este factor: Oracle Global List Pricing

?

Si Oracle aguanta mucho mas que FB, entonces a quien lo necesite ese precio lo vale o no. Demás esta decir que Oracle es a FB lo que un Mainframe a un servidor: un mercado diferente. Seria absurdo decir que si un servidor PC tipico es mas barato que un mainframe, estúpido el que compra el mainframe (estupido es el que compra un mainframe, cuando realmente necesita un servidor, pero bueno eso es otra cosa...).

Ademas, se puede malinterpretar el que como no hay un argumento que diga: mira que FB puede tragar mas datos que Oracle, cambiemos el tema al $...

No creo que sea nada controversial reconocer que Oracle barre con FB en cuanto a funcionalidad, confiabilidad & desempeño.

Lo mismo se podría decir (en términos generales, *ojo*) de Postgres, DB2 & Sql Server. Quizas se puede argumentar que FB barre con MySql, excepto que MySql se puede montar en un array de Balanceo de cargas trivialmente, y que (tal vez?) sea mas rapido en lecturas. Creo que siempre ha sido claro cual es la posicion de FB, incluso desde quienes la hacen.

Así que en cuanto a desempeño raso, que es lo que apuntan los números de este thread? No seria nada sorprendente decir que otras BD pueden ser mejores.. De hecho el problema que le veo a este caso de estudio es que no hace un argumento muy convincente: No saca ventaja de los puntos fuertes de FB, y da mucho espacio a # que para cualquier conocedor del tema pueden ser *ok* pero no *descrestantes*.

No se ve FB muy seguido en ninguno de los sitios que hablan de temas de escalabilidad (ej: en http://highscalability.com/ no sale ni 1 vez), ni nunca he sabido de un startup que use FB... que es muy triste, si usan *gasp* MongoDb!, asi que no se escucha de casos de uso donde la gente diga: Whoa! que impresionante. Se habla, por ejemplo, que Mongo lo usan tal y cual app/sitio... tiene miles de usuarios, MongoDb debe ser *la leche encarnada*, y así es como se rego ese adefesio.

----

Ahora, no malinterpreten. Recuerden que realmente *soy todo un fan* del underdog.

El angulo de FB va mas por la facilidad de uso, zero-admin, despliegues flexibles desde embebido a cliente/servidor, confiabilidad y creo yo el punto mas fuerte, ser capaz tanto como BD tipo olap como transaccional. En todo eso FB barre a todo el mundo, y es en lo que se deben enfocar los que la promueven. No se deben sacar # que sean desfavorables (o parezcan, o no refuerzen el angulo) y en cambio se deben enfatizar donde FB es fuerte.

Asi que si hacen un caso de estudio, yo diria que este seria el formato:

- Que es firebird
- Un listado de empresas muy conocidas que lo usen (tipo: Lo usan MS, Apple, bla bla.)
- Resumen de la empresa/gente de la cual se va a enfocar el caso, cuales son sus retos
- Reiterar uno o varios de los puntos fuertes
- Contrastar contra otras soluciones en donde esos puntos les son desfavorables. Que hace a FB realmente una mejor solucion que otras? La simple familiaridad no es argumento.
- Si se presentan números? Por ejemplo yo enfocaria como sirve para OLAP/OLTP y mostrar eso contra el primero que le salga peor (ej: Si por casualidad Oracle sale mas lento, PG medio, entonces se usa Oracle).

Si realmente se esta sub-utilizando las capacidades del motor (ej: No siendo un experto en FB, tambien me pareció que los # presentados deben estar muy por debajo de lo que FB aguanta), entonces hay que poner el # que si destaque. Por ejemplo: NNN dias sin tunear, administrar la BD.

- Mostrar la confiabilidad, escasez de administración manual, etc
- Resumen

En cuanto a precio? Eso solo es un problema para los pequeños. Una startup solida y una empresa que le saque la leche a un motor se rien de los precios. Obvio no les choca algo mas barato, como a todo el mundo, pero el que sea *gratis* es una contra mas que un punto a favor A MENOS que este claro a quien se debe $$$$ por soporte. Quienquiera que realmente vaya a usar seriamente algo, le interesa sobremanera tener como $$$$ a quien lo saque de apuros.

---
Tambien desde hace mucho me parece que FB, al igual que FreePascal & Delphi sufren enormente por falta de un buen enfoque de marketing (del bueno) y de saber presentarlo.

---
Ahora eso es un caso de estudio pa una empresa/cliente. Para gente como nosotros? Hace falta algo mas. Yo he visto información muy descrestante sobre PG (por ejemplo) con números, detalles técnicos, bechmarks, etc muy bien logrados. Hay algo asi sobre FB?

No?

Entonces que tal hacer eso?

[[poliburro]]

Empezado por Casimiro Notevi

Compara con: Vas a firebirdsql.org, ... descargas ... instalas ... a trabajar.

Claro, con dbase o access también se puede hacer eso .Supongo que en los sistemas que administras no se necesita más que eso.

[Casimiro Noteví]

Empezado por poliburro

...

Desde que te has convertido en un trol en clubdelphi, estás insoportable, ni tus amigos te soportan, ¿por qué no haces de trol en tus foros?

¿Saben tus compañeros y amigos que te dedicas a hacer de trol en clubdelphi? ¿Te da vergüenza que conozcan esa faceta tuya?

Como VMP de Embarcadero, ¿saben en Embarcadero que te dedicas a hacer de trol en clubdelphi?

Interbase, como prima-hermana de firebird, y de Embarcadero, si tiras por los suelos a Firebird, estás tirando también a Interbase, ¿saben en Embarcadero, que tú como VMP de Embarcadero, opinas de esa forma de su base de datos?

Si te gusta hacer de trol, hazlo en tus foros, verás cómo se alegran tus amigos de conocer esa faceta tuya tan divertida.

[ecfisa]

Empezado por poliburro

Claro, con dbase o access también se puede hacer eso .Supongo que en los sistemas que administras no se necesita más que eso.

No, no se puede hacer eso con DBase o Access. Eso es indiscutible desde cualquier punto de vista.

Respeto tu derecho a sentir aversión por Firebird, pero la misma nubla tu criterio. Además de no ser libres, DBase o Access están muy lejos por detrás de Firebird.

Solo por que digo lo que pienso de firebird con argumentos por supuesto y no con diatribas?

Bueno, eso tampoco es totalmente cierto... Comparar Firebird con Access o DBase es una argumentación errónea y una clara diatriba contra Firebird y sus usuarios.

Saludos

[[rretamar]]

Empezado por poliburro

Claro, con dbase o access también se puede hacer eso .Supongo que en los sistemas que administras no se necesita más que eso.