Firebird: otro caso de estudio

[[rretamar]]

Technical details

Our largest installation of the Firebird SQL has these attributes:

• Database size: ~70 GB
• Average daily database increase: ~80 MB
• Connection with economic systems (SAP, …)
• Connection with attendance systems
• Terminals connected in manufacture:
  • Number of terminals with text-mode emulation: 32
  • Number of graphical terminals: 8
• Number of terminals in quality control centre: 12
• Number of online connections with database: 43
• Average number of transactions per second: ~3.4
• Average number of transactions per day: ~290 thousand
• Server: MS Windows Server 2008 R2 64 bit
• Database engine: Firebird 2.5.2-64 in SuperClassic mode with UDF usage
• Operating time: 24 x 7

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

[Casimiro Notevi]

[TiammatMX]

Empezado por rretamar

...[*]Average daily database increase: ~80 MB...

¡¡¡¿¿¿PERDÓN???!!! ¡Increíble!

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

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 Notevi]

¿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

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

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.

[[poliburro]]

Empezado por Casimiro Notevi

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.

¿Trol? ¿Solo por que digo lo que pienso de firebird con argumentos por supuesto y no con diatribas? No casimiro, no caigo en eso. Jamás a diferencia de ti he dicho algo sobre firebird sin sostenerlo con información que respalda lo que digo, que tú nunca estes de acuerdo no me hace trol ni mucho menos.

Respecto a si lo saben, no lo se, puedes preguntarles. A mi lo que me apasiona es Delphi no firebird ni interbase.


ahh y respecto a que en DA no digo lo que pienso sobre Firebird pues mira:
http://www.delphiaccess.com/forum/no...ares-del-mundo

[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

[Casimiro Notevi]

Empezado por poliburro

¿Trol? ¿Solo por que digo lo que pienso de firebird con argumentos por supuesto y no con diatribas? No casimiro, no caigo en eso. Jamás a diferencia de ti he dicho algo sobre firebird sin sostenerlo con información que respalda lo que digo, que tú nunca estes de acuerdo no me hace trol ni mucho menos.

Sí, trol, eres un trol, en este hilo y en casi todos en los que has participado desde hace tiempo. No te hagas el inocente, que no sabes disimularlo.

[[poliburro]]

Empezado por ecfisa

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.


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

Entiendo lo que dices compañero y es muy cierto lo que dices, creo que en ello he errado y si por eso los he ofendido sinceramente te pido una disculpa. Ahora bien si me lo permites me explicaré por qué la comparación. Desde hace mucho he visto que firebird es usado en entornos cliente servidor solventando algunas de sus deficiencias con código delphi lo cual le quita de entrada la característcia de robustes que muchos como postgresql, oracle o mssql server poseen. ¿qué deficiencias? como la comunicación en firebird entre distintas bases de datos en un entorno multidb o la comunicación entre distintas instancias de firebird. Para que puedas leer dos tablas desde distintas instancias de firebird solo puedes hacerlo si bien he leido con código delphi. ¿Qué acarrea eso? que incrustes código sql en las aplicaciones y esa es precisamente una terrible prática heredada de los tiempos de dbase cuando no se podía colocar código sql en la base de datos. De ello la comparación que hago y que entiendo consideran como un insulto. De ello me disculpo contigo.

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

?

No?

Entonces que tal hacer eso?

Absolutamente de acuerdo contigo. Valdría la pena desarrollar un caso de estudio así pero para ello creo que se necesitaría alguien que sea experto en ese motor y que garantice sacarle el máximo jugo a las características que tiene. Sería grandioso ver un estudio de ese calibre para evaluar desde una mejor posición lo que firebird puede o no hacer, especialmente para quienes como yo lo vemos con malos ojos, tal vez inmerecido, pero así lo vemos.

[Casimiro Notevi]

Firebird: otro caso de estudio

Evidentemente, esos no son "casos de estudio", se ve que son personas que trabajan en ciertas empresas y que han puesto una pequeña definición de su sistema informático.
Pero no por ello hay que desvirtuar el hilo sobre lo bueno o no tan bueno que pueda ser firebird, mongo o cualquier otra base de datos.

Si tienen algo que comentar, comenten, pero por favor, trols abstenerse.

En la jerga de Internet, un troll o trol describe a una persona que publica mensajes provocadores, irrelevantes o fuera de tema en una comunidad en línea, como un foro de discusión, sala de chat o blog, con la principal intención de molestar o provocar una respuesta emocional en los usuarios y lectores, con fines diversos y de diversión o, de otra manera, alterar la conversación normal en un tema de discusión, logrando que los mismos usuarios se enfaden y se enfrenten entre sí. El trol puede crear mensajes con diferente tipo de contenido como groserías, ofensas, mentiras difíciles de detectar, con la intención de confundir y ocasionar sentimientos encontrados en los demás.

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