empresas que usan firebird
He estado googleando mucho buscando una lista de empresas reconocidas o empresas no tan reconocidas que utilicen firebird en todo su esplendor (base de datos superiores a 20gb), manejando sistemas grandes de altos volumenes de transacciones diarias, etc. Pero la verdad que ni en la misma pagina oficial de firebird aparece nada, lo poco que he encontrado solo son menciones muy dispersas de algunas pocas empresas, como un diario de tasmania en australia llamado The Examiner que posee una base de datos de 16GB y una empresa rusa llamada AVARDA con una base de datos de 120gb. Pero despues de estos dos casos no encuentro nada interesante.
Esto me da a razonar que las empresas grandes y medianas no apuestan mucho a firebird, ya que con mucha facilidad podemos encontrar listas oficiales de empresas que logicamente manejan increibles volumenes de informacion con base de datos como db2 IBM, oracle, sql server, postgre y Mysql entre las mas destacadas. Alguien podria comentar al respecto a esta observacion, o si alguien conoce algunos otros articulos de casos de exito similares a los ya mencionados con firebird. Gracias. |
Según mi opinión...
Es lógico que encuentres pocas empresas "GRANDES", que utilicen este Motor de Base de Datos, esto es debido a que las EMPRESAS GRANDES, utilizan motores más potentes como ORACLE.... o Sistemas ERP como SAP... Salu2:p:D |
He trabajado con un grupo de empresas local que utiliza firebird, en total quizás unos 20 o 30 Gb. de información, con unos 400-500 usuarios colgados de él, aunque la carga está distribuida entre varias bases de datos y varios servidores (decisiones que se tomaron antes de mi integración al equipo y que francamente desconozco los motivos).
Prácticamente todas las transacciones de estas empresas llegan a fb, exceptuando un producto externo que compraron hace un par de años, que se basa en SQL Server, pero que representa un 1% del volumen total. Lamentablemente, no estoy autorizado de revelar nombres ni mas detalles de la operación, pero te aseguro que, según se, hasta el momento la cosa va bien. Hasta luego. ;) |
Si te esperas unos mesesitos verás una base de datos Firebird en todo su "esplendor" en una empresa mediana de Ciudad de México, actualmente tiene medio GB y corre como el rayo y sin asomo de tropiezo alguno. Una vez terminada la aplicación y en producción, no dudo que llegue a ser de varios GB en menos de un año por el volumen de información manejado.
Ojo, yo no colocaría a MySQL como algo que se compare con Firebird. Sinceramente no creo que tenga mucho que hacer en el grupo de "las grandes". Desde luego Oracle está en primer lugar (es algo así como el Michael Jordan de las bases datos), y luego un pequeño grupo de compañeros del "dream team" entre los que está SQL Server (a pesar de sus malas interfaces e incómodas dependencias con el sistema operativo). Quizá Firebird esté un poco más abajo de los "gigantes", pero para mi gusto más cerca de una base de datos "adulta" que de MySQL (con todo respeto). También recuerda que cada base de datos que se consolida es porque encontró un nicho donde resultó más aceptable y eficaz. En el caso de MySQL, ya todos sabemos por qué camino llegó (desarrollos Web que no requerían gran sofisticación de bases de datos). Desde luego que Firebird es de las menos usadas, pero tú ya has visto cómo a veces algunos productos "poco populares" resultan ser de las mejores elecciones para un comprador informado. ;) Todo depende de en qué proyecto vayas a usar la base de datos, aunque cierto es que Firebird cubre un abanico muy amplio. :) En concreto, y siendo justos con la verdad, son pocas las empresas que usan Firebird en comparación con las bases de datos más "populares". Saludos. Al González. |
Cita:
|
Cita:
|
Cita:
|
Cita:
¿No crees que eso es algo, como decirlo...falso? :confused: Hay multitud de empresas usando MySQL, en la gran mayoría de los casos para sostener la información de sus portales Web, pero ¿gigantescas? :confused: Saludos. ;) Al. |
Cita:
|
Cita:
De lo que si estoy enterado es que yahoo la utiliza para su parte de publicidad. Algo asi recuerdo |
Cita:
http://es.wikipedia.org/wiki/MySQL#Usuarios_destacados http://www.mysql.com/customers/ http://en.wikipedia.org/wiki/MySQL#M...e_Year_winners |
¡Hola!
Cita:
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. :confused: En fin. |
Cita:
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. ;) |
Cita:
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 Cita:
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. |
Cita:
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. Cita:
Cita:
Mis fuentes dicen algo distinto: Cita:
Cita:
Cita:
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. |
Cita:
Tranquilos muchachos, :). mejor vayamos a la taberna por una ronda de chelas. |
Cita:
|
Cita:
Saludos. Al. |
Cita:
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" |
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 :D pd: cantinero ... una ronda de firebird para todos, yo invito ;) |
Cita:
Un abrazo. Al. |
Cita:
|
Firebird Rulez!!!
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 :D:D:D.
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.
La verdad estoy un poco confundido, espero y me puedan aconsejar o recomendar algo para poder tomar un rumbo |
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: Cita:
Cita:
Cita:
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). Cita:
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. Cita:
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" :) |
Yo mucho no puedo aportar... Casi se mandó un buen discurso proveniente de sus años de experiencia y eso vale.
Si algunos informes son mas lentos, quizá sea como te han dicho disponer de un servidor con una DB a modo de sólo lectura con los últimos backups para consultar en vez de que sea sobre la DB operativa. Esto podría alijerar la carga, aunque tiene la contra el factor económico y que se deberá llevar a cabo un mejor control de los backups. Otra de las posibilidades, que podrían ayudar a mejorar el rendimiento sobre las consultas para generar informes es aplicar un poco de desnormalización. Es decir, romper un poco las reglas normales y disponer de datos ya preprocesados, calculados, o estimados. Quizá se consiga un aumento del tamaño de la base de datos, pero al menos con estas tablas desnormalizadas, bien pensadas y estudiadas, con sus respectivos índices, etc. Generar un informe que requiera de por dar un ejemplo extremo, 10 joins, 5 group by, 7 order by, 20 coalesce, y 10 Max()s quizá pueda reducirse, siendo optimistas a la mitad. Una solución mágica seguro no hay. Tirar de un lado, invetibalemente tendrá alguna desventaja y repercusión en otro punto. Es el Yin-Yang... ni lo uno, ni lo otro, ni mutuamente excluyentes, ni mutuamente dependientes... es esa sensación rara de que al final damos vueltas en círculos :D ¿Quieres tirar por el lado de mejorar la base de datos? Te rompe los esquemas y a adaptar de nuevo el sistema para absorver los cambios. ¿Quieres adquirir más poder? Tienes que sacar la billetera... Me hiciste acordar ahora de otra frase: Rapido, Bueno, Barato. Elija 2 cualquiera. ;) Saludos, |
Daré por sentado que cuando te refieres a informe, te refieres a una CONSULTA SQL con sus JOIN'S y GROUP BY's, ORDER BY's, etc. a como ha dicho Delphi.
Desde mi punto de vista recomendaría: Lo primero, tomando lo dicho por casimiro, es "debuguear" las consultas y ver en que partes puedes optimizarlas. Segundo: Tomando la consideración de Delphius, puedes reducir el uso de JOIN's o GROUP BY's desnormalizando los datos. Por ejemplo, si unes dos tablas para solamente obtener el nombre completo del cliente, puedes evitarte hacer la unión simplemente guardando el nombre del cliente en la tabla de Ventas, por poner un ejemplo. Tercero: Anteriormente dicho por Casi, instala Linux. Cuarto: Aumenta la RAM a la mayor cantidad que puedas y utiliza un disco interno dedicado con la interfaz de conexión más rápida disponible. (Este es el más fácil de los cuatro pero no es una solución a largo plazo). Ahora, no sé si no he entendido el punto o qué, pero veo con recelo eso de partir la DB. No entiendo que rendimiento puedas obtener si partes la DB para luego consultar las distintas partes. Sino me equivoco, desde la versión 2.5 de Firebird puedes hacer conexiones a otras base de datos desde los procedimientos almacenados. Nunca he probado esta funcionalidad, pero estoy casi seguro que tiene su penalidad en el tiempo que se tarta en hacer la conexión. Sin embargo, el tiempo que se tarda en hacer la conexión puede ser relativamente muy enferior al tiempo de espera para generar un informe con todos los datos almacenados en una misma DB. En este caso puedes tomar provecho de esta funcionalidad. Pero esto sería algo que tienes que hacer con mucho cuidado para obtener el máximo rendimiento posible. Desde mi punto de vista primero probaría las cuatro recomendaciones anteriores. Cambiar el motor de base de datos es trabajo. Tienes que estar muy justificado del por qué hacer el cambio. A cómo te han dicho, Oracle no sería recomendable. Mejor utiliza PostgreSQL que trae replicación nativa. Ya Casimiro te explicó el por qué. Por último, estoy seguro que no manejas el nivel de transacciones que tiene Amazon o Youtube. Pero ya que preguntas, tengo entendido que estas empresas utilizan una arquitectura de base de datos llamada "NOSQL". Son motores que están optimizados para escribir y leer rápido. Exceptuando lo básico, en ellos no existe el lenguaje SQL. No es la gran cosa. Simplemente se reducen a obligarte a hacer desnormalización de datos a cómo te ha dicho Delphius y yo lo recojo en el segundo punto. Si quieres la mayor potencia, tienes que dar a cambio el lenguaje SQL. Por último, quiero cerrar diciéndote que Firebird es uno de los motores SQL más rápidos que puedes encontrar. Muy superior a PostgreSQL y Oracle. Su diseño sencillo lo hace uno de los motores más ágiles. Debes de dejar la idea que otro motor te brindará mejor rendimiento, porque créelo, será casi imposible. Saludos. |
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:
Cita:
Un saludo y hasta luego. ;) |
Hola, amigo jachguate, es cierto que windows usa la memoria virtual (fichero en el disco duro) para "ampliar" aunque tenga mucha RAM instalada, incluso le sobre, pero eso es un problema de windows, como has dicho.
En linux, no es así, linux usa toda la memoria ram disponible y sólo cuando ya no le queda más remedio, entonces usará la memoria virtual, por lo que siempre está sacando el máximo rendimiento a la ram instalada, y cuanto más tenga, mejor. En los apartados de memoria y cpus, no estoy nada de acuerdo contigo, mejor dicho, o te has confundido o no te he entendido, pero aquí dices: Cita:
Pero no es así en linux con las versiones classicserver ni superclassic, firebird hace uso de todas las cpus instaladas, perfectamente, transparente al usuario, y además lo hace muy bien, aprovechando cada cpu, según su nivel de utilización, si está muy ocupada entonces lanza la consulta por otra cpu. Lo tengo más que probado en mis clientes, observando con 'top' los procesos del servidor según van trabajando los usuarios, y cómo firebird va haciendo peticiones a cpus más ociosas para repartir el trabajo entre todas las cpus. Además no sólo lo digo yo, lo dice la propia documentación de firebird: Cita:
Cita:
El único problema es ahí los discos duros, pero ya digo que hay que montar los más rápidos que se pueda permitir económicamente. En un par de clientes también tenemos instalado red de fibra óptica, por lo que los "cuellos de botella" que mencionas se quedan prácticamente en la eficiencia de las SQLs que hayamos hecho nosotros :) En cuanto a la memoria, la verdad es que firebird consume muy poco, otra gran ventaja, pero sí necesita un poco por cada conexión abierta, obviamente, no recuerdo la cantidad, pero también es poco, el lunes lo puedo confirmar preguntando a un cliente, pero juraría haber visto en algunas ocasiones más de 6 Gb de ram usadas, eso sí, con varias decenas de conexiones activas. En fin, que al igual que afirmas que con servidores linux la diferencia de rendimiento con windows es bastante grande, también creo que esos "limitantes" que has puesto de cpus y ram, se dan sólo en windows, donde se usa la versión superserver. Y no tiene nada que ver con las versiones classic de firebird, menos todavía en linux. |
Cita:
Cita:
Lo que yo dije es: Cita:
Procesador. Puede que tengas 16 nucleos, pero que (por estar mal configurada o por haber elegido la edición incorrecta) la base de datos solo pueda sacar provecho de uno (especialmente cierto con firebird). Y nunca quise decir que Firebird no pudiese sacar provecho de todos los núcleos o procesadores instalados. Cuando comparas Firebird con otros motores, sin embargo, no puede dejar de reconocerse que aún tiene limitaciones (la falta de una caché compartida, pro ejemplo), y que no será hasta la versión 3 que esto mejore realmente. Esto tiene que ver también con el punto anterior. Cita:
Cita:
Cita:
Cita:
Yo diría que:
Un saludo, amigo Casimiro y a todos! |
Seguramente no te entendí bien, mejor ahora, quedará también más claro para otros posibles usuarios :)
Buen viaje :) |
Asi sea
Hola, buen dia a todos compañeros foreros, y antes que nada muchisimas gracias a todos, y especialmente en orden de respuesta.
He leido detenidamente cada punto de sus recomendaciones, de sus consejos, y bueno creo que el primer punto de "Things to do" es montarme un servidor linux, inceramente estoy muy verde en linux, pretendo usar Fedora, aunque ya antes he tenido problemitas con otras distros para levantar el Samba, y tengo ciertas dudas, pero por lo leido vale bastate la pena el cambio, y lo haremos. Como datos adicionales, solo para no dejar cosas en el aire, manejamos un servidor dedicado para los DNS y administracion de los usuarios, permisos y demas; y otro servidor exclusivamente para la BD, el cual no corre aplicaciones, es dedicado, no administra nada, cuenta con 4 cores, se generan Backups diarios a la 1 de la madrugada (cuando el servidor no tiene conexiones activas), y se almacenan en un disco externo de 4TB. Como bien dice Chris con la cuestion de los reportes creo que me explique mal, si me refero al momento de hacer la consulta, ya que una vez con los datos necesarios el RAVE me funciona perfecto, y si, hay algunos reportes 'pesados' en los cuales cambiaré la ideologia y en lugar de sacarlos con Joins, Groups, y demás, se mandarán a una tabla de acumulados para sacar la informacion con un select mas sencillo, aunque en este punto me entra otra pequeña duda...
Cita:
Y bueno por último y no por eso menos importante Jachguate, pues tu dime como por que fecha andas en esta tierra Azteca, y claro que nos ponemos de acuerdo y si alguien más anda por el rumbo, armamos una 'Taberna' en el plano real :D:D:D. Me temo que andaré por aca dando lata mas adelante, porque esto apenas comienza... Saludos y nuevamente Gracias. |
Cita:
|
Cita:
El servidor firebird se comunica por el puerto 3050 y él se encarga de hacer las peticiones a la base de datos y de dar las respuestas. Pero nadie, ningún usuario tiene por qué tener acceso a nada del servidor, no hay que compartir nada. Mejor que los usuarios ni sepan dónde está el servidor, usas un alias y listo. Cuando vayas a instalarlo si tienes cualquier duda, pregunta, aunque es un tema que se ha tratado en diversas ocasiones y encontrarás información amplia si usas las búsquedas de clubdelphi. |
Hola, no tengo tanta experiencia en este tema como ustedes pero me enfrento a una situación muy similar y lo que yo puedo aportar es que una consulta SQL específicamente con esas cantidades de registros inevitablemente van hacer lentas por mas optimizadas que se encuentren y la unica opcion seria las tablas de los acumulados, pero ahi es de donde viene otro problema, los TRIGGERS
Cita:
me parece perfecta la idea de poder tener 2 base de datos - una para detalle o para los millones de registros - otra para los acumulados (en donde el proceso de mantenimiento se pueda hacer mucho mas rapido y mas frecuente) pero que pasa con las transacciones????? se puede tener una trasaccion para 2 bases de datos???? Saludos GM |
Claro, buscar antes de preguntar, y si me imagino que debe ser un tema recurente... pues manos a la obra, y muchas gracias nuevamente Casimiro Notevi y CD
|
Cita:
Con un backup/restore la BD queda como nueva :) Con ese servidor que tienes verás como el rendimiento que consigues será bastante importante. |
Cita:
Cita:
Cita:
Podes configurar el motor de diferentes maneras para graduar la manera y frecuencia de la recolección de este espacio, de manera que sea el óptimo para tu caso particular. Lee el artículo dabase housekeeping, que te dará una panorámica del tema. Cita:
|
El tema de la "basura", no suele ser problema, en un uso normal ni siquiera se notará. Por eso digo que no es problema, o al menos nunca me he encontrado que sea un problema en ningún caso.
También es cierto que además de los backups diarios, cada semana (cómo mínimo) tenemos programado un backup/restore de la BD (habitualmente los sábados por la noche o domingos, según el cliente), por lo que queda "limpia" para empezar a trabajar de nuevo con ella. |
Cita:
En una aplicación que ha seguido recomendaciones como realizar transacciones cortas, con el menor niveles de aislamiento necesario, no tendría por qué ser problema, pero... he visto casos!! ufff... |
Cita:
|
La franja horaria es GMT +2. Ahora son las 22:55:17. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi