Base de datos MySQL... u otra?
Horst H. von Brand escribió: Rodrigo Fuentealba [EMAIL PROTECTED] wrote: El 16/02/08, Aldrin Martoq [EMAIL PROTECTED] escribió: He visto bases de datos MSQL volar consumiendo muchos registros (no se cuantos, digamos el año completo de datos desde SAP de un tema específico de una empresa _grande_) en tan solo segundos. SQL Server no es para nada una mala base de datos. Por otro lado (y me lo recordaste cuando mencionaste a SAP), MySQL con todos los registros de un mes de SAP se cayó varias veces en distintos sistemas operativos cuando estuve haciendo algunas asesorias en una forestal, y PostgreSQL tomó poquísimos segundos en resolver las mismas consultas. (Ya he comentado esto anteriormente en la lista). Con los mismos indices, etc? Eso puede afectar el rendimiento en forma notable. El optimizador de MySQL es de lejos mucho más simple que el de Postgres. En cuanto empiezas a hacer consultas elaboradas, simplemente toma los caminos más elementales (nested loops en lugar de hacer sort+merge join por ejemplo). Ahora, de que se MySQL _caiga_ no estoy seguro cuál será la explicación. Quizás falta de memoria. Ciertamente el ser multithread puede causarle problemas si un thread pisa áreas memoria de otros threads (cosa que no puede suceder en Postgres por evitar threads), pero hasta donde yo sabía la robustez ha mejorado últimamente. -- Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257 I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. (L. Torvalds) From [EMAIL PROTECTED] Mon Feb 18 18:04:33 2008 From: [EMAIL PROTECTED] (Miguel Oyarzo O.) Date: Mon Feb 18 18:07:56 2008 Subject: ifdown ppp0 Message-ID: [EMAIL PROTECTED] Estimados Instale recientemente una FC5 (no tenia a mano mas que esos CDs). Actualice kernel y varias cosas con yum (hasta donde se puede). el enlace con ppp se levanta sin problemas (ifup ppp0) pero ifdown ppp0 pareciera no tener efecto cuando el PC alcanza unas 700 conexiones simultaneas (corro algo de sofware p2p alli). No tengo errores en /var/log/messages luego de ifdown ppp0. network restart tampoco parece tener efecto sobre ppp0 (solo reinicia las interfaces ethernet sin problemas) Tambien he visto que pppd prefiere levantar una conexion con interfaz ppp1 y no matar ppp0 cuando se pierde la conexion. Todo trabaja normal cuando la maquina tiene pocas conexiones, pero despues de un par de horas (al llegar al numero de sockets indicado) se ve este extraño caso (el paquete ppp.386 es el que viene en la distro) Cual es la relacion entre el numero de conexiones y el killproc que deberia matar a pppd ? Alguna idea? Saludos, Miguel Oyarzo O. Austro Internet S.A. Punta Arenas
Base de datos MySQL... u otra?
El 17/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: 2008/2/16 Rodrigo Fuentealba [EMAIL PROTECTED]: El 16/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: 2008/2/15 Rodrigo Fuentealba [EMAIL PROTECTED]: El 15/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: Dudo *mucho* que el índice del buscador de google esté almacenado en un RDBMS. MySQL /no/ es un RDBMS. No seas odioso. Ya leimos eso un montón de veces. Fue un lapsus nada más... Pero (a) yo puse RDBMS para ahorrarme la lata de escribir Base de datos SQL o algo por el estilo DBMS podría funcionar; o SGBD, SABD, SMBD si quieres. De donde se desprende que el 99% del tiempo, la gente usa el término RDBMS en un sentido no demasiado estricto. No me extraña; pero bueno; por cierto, pues no le cojo la gracia. Y no hablo del buscador (que siempre fue BigTable + GFS) sino del índice de servicios de Google. Ah. De ahí la confusión entonces. Suele pasar. En cualquier caso, volviendo al tema original, ni Google, ni Wikipedia, ni todos esos sitios con necesidades absurdas de rendimiento usan un Base de datos SQL o algo por el estilo Ninguno ha dado la talla en rapidez a tal punto; los DBMS de la clase PostgreSQL, SQL Server, MySQL y otros son para sistemas no tan grandes, en los que importa mucho la integridad. Si se quiere mejorar la performance en sitios que son grandes pero que no son masivamente utilizados (como Yahoo! Bookmarks), es mejor no usar claves foráneas y planificar muy bien las consultas. Y ojalá mandar al autoincrement y similares a la punta del cerro, pues causan problemas. Germán Poó dio un buen par de detalles de esto. http://listas.inf.utfsm.cl/pipermail/linux/2007-July/038322.html Los sistemas del tipo redes sociales utilizan demasiado la caché, sin utilizar mucho las bases de datos, pues les interesa justamente que sea rápido y no preciso (algo fundamental en un DBMS donde se hacen varios cientos de miles de transacciones bancarias). Por ejemplo, los Google Groups dan cuenta de varios errores. Si ven la lista de threads, en los detalles dice 9 mensajes; pero cuando van a leer el thread, se dan cuenta de que sólo existen 8. Last.fm tampoco está exento de estos fallos: la primera semana que estuve suscrito salió en mi lista que yo había escuchado un disco de Sin Bandera, cuando yo lo único que escucho es metal y música clásica (y no hay otros MP3 en mi disco duro que los que yo escucho, y me niego a que haya). Como referencia, acá un tipo colleccionó links a un montón de material on topics related to designing of high throughput, scalable, highly available websites: http://www.royans.net/arch/library/ Excelente! tendré harta lectura para el fin de semana. -- Rodrigo Fuentealba
Base de datos MySQL... u otra?
El 16/02/08, Aldrin Martoq [EMAIL PROTECTED] escribió: On Feb 14, 2008 10:52 AM, Nelson [EMAIL PROTECTED] wrote: Hola, necesito migrar una base SQL SERVER a otro motor (necesidades de Performance) He visto bases de datos MSQL volar consumiendo muchos registros (no se cuantos, digamos el año completo de datos desde SAP de un tema específico de una empresa _grande_) en tan solo segundos. SQL Server no es para nada una mala base de datos. Por otro lado (y me lo recordaste cuando mencionaste a SAP), MySQL con todos los registros de un mes de SAP se cayó varias veces en distintos sistemas operativos cuando estuve haciendo algunas asesorias en una forestal, y PostgreSQL tomó poquísimos segundos en resolver las mismas consultas. (Ya he comentado esto anteriormente en la lista). [...] El sistema en si sería de solo consulta, pero tengo que importar 10 años de antiguedad, mas los mensuales La pregunta es: será que se bancará manejar tanto volumen de datos MySQL o no? De las respuestas que hemos recibidos, todos cuentan maravillas de uso en: google, facebook, y otras empresas grandes; pero por lo visto nadie a trabajado con tantos Gigas por acá y por lo tanto nadie te puede contar la parte negra del asunto. No con MySQL. Pero de lo que he visto sobre cómo se usa MySQL en Wikipedia (vi el modelo y lo analicé varias veces); es un modelo en el que las relaciones se implementan a nivel de software, no a nivel de bases de datos (vuelta a lo que decía siempre: MySQL /no/ es un RDBMS); realmente no se hacen tantas consultas a la base de datos (comparadas con el número de visitas), solamente inserciones, comparaciones y luego regeneración de la página que está en caché. Y por lo tanto, MySQL se preocupa de crecer, crecer, crecer y mantener un índice de texto; nada difícil de implementar en COBOL (que sería mucho más rápido, además). Apoyando esto, en varias implementaciones de sistemas de control de documentos gigantescas en que se usa MySQL para llevar un índice del estado (una empresa de ingeniería en que hay 24 Terabytes de documentos entre Word, Excel, AutoCAD y otros), la tabla de revisiones no alcanza realmente a los 200 Mb, es decir, algo despreciable. Pero la propaganda fue this software has MySQL: the most popular database engine.. Sí, Hasefroch también es popular, ¿y qué?. Y en general, mi experiencia con MySQL es que para muchas consultas a una sola tabla es muy rápido, pero su nivel de inconsistencias me hace pensar en que: MySQL es un software que te da respuestas erróneas, pero en el mínimo de tiempo posible. Ahora, la cosa cambia con PostgreSQL: yo a lo sumo he manejado bases de datos de texto que tienen de 100 a 120 Gb en esta base de datos (nada parecido a los 250 Gb que mencionabas). Tuve una muy buena experiencia con lo que hizo TSearch2 en esa oportunidad. Los pocos problemas de lentitud que tuve se solucionaron haciendo buenos índices de acuerdo a las consultas que hacía (una planificación muy a conciencia, me tomó una semana y media) y no a las tincadas de que por este dato se indexa mejor como suele hacerse. También tuve algunos problemas con el respaldo (tamaña base de datos es difícil de respaldar), y en general ninguna consulta se demoraba más allá de 3 minutos. Eso sí, y antes de recomendarte algo: SQL Server no es para nada de malo (sobretodo MSSQL2005, que yo personalmente lo prefiero a MySQL). Todo depende de las consultas y realmente de lo que quieras obtener de la base de datos; es posible que haya una falta de configuración nada más, y eso no te lo podrían responder por acá pues sería OT. tan solo algunas consultas que has preparado para contestar ciertas preguntas. Eso es, en base, OLAP. De ser así, a vuelo de pájaro se me ocurre que si generas mas tablas con datos premasticados (posiblemente durante la carga con un DTS) y con los índices correctos sería la solución a tu problema, independiente de la base de datos. Interesante sería saber qué versión de SQL Server estás usando también. -- Rodrigo Fuentealba
Base de datos MySQL... u otra?
El 16/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: 2008/2/15 Rodrigo Fuentealba [EMAIL PROTECTED]: El 15/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: Dudo *mucho* que el índice del buscador de google esté almacenado en un RDBMS. MySQL /no/ es un RDBMS. Y no hablo del buscador (que siempre fue BigTable + GFS) sino del índice de servicios de Google. BTW, tienes razón, Google BigTable ya no usa a MySQL para sus índices. De donde sacas que alguna vez lo haya hecho? De haber leido mucho sobre la integración de los servicios de Google. Muchos de los servicios (como Adwords, Adsense y ahora iGoogle) funcionan en MySQL, pero son generados a través de la información del usuario que hoy en día se guarda en BigTable. Hay un nexo muy cercano entre ellos. Varios desarrolladores hacen mención a eso y al trabajo que Google hace por mejorar la escalabilidad de MySQL. -- Rodrigo Fuentealba Cartes Desarrollador de Sistemas - Consultor UNIX - Database Administrator
Base de datos MySQL... u otra?
??? Enviado desde mi BlackBerry de Movistar -Original Message- From: Rodrigo Fuentealba [EMAIL PROTECTED] Date: Sat, 16 Feb 2008 17:19:38 To:Discusion de Linux en Castellano linux@listas.inf.utfsm.cl Subject: Re: Base de datos MySQL... u otra? El 16/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: 2008/2/15 Rodrigo Fuentealba [EMAIL PROTECTED]: El 15/02/08, Leonardo Soto M. [EMAIL PROTECTED] escribió: Dudo *mucho* que el índice del buscador de google esté almacenado en un RDBMS. MySQL /no/ es un RDBMS. Y no hablo del buscador (que siempre fue BigTable + GFS) sino del índice de servicios de Google. BTW, tienes razón, Google BigTable ya no usa a MySQL para sus índices. De donde sacas que alguna vez lo haya hecho? De haber leido mucho sobre la integración de los servicios de Google. Muchos de los servicios (como Adwords, Adsense y ahora iGoogle) funcionan en MySQL, pero son generados a través de la información del usuario que hoy en día se guarda en BigTable. Hay un nexo muy cercano entre ellos. Varios desarrolladores hacen mención a eso y al trabajo que Google hace por mejorar la escalabilidad de MySQL. -- Rodrigo Fuentealba Cartes Desarrollador de Sistemas - Consultor UNIX - Database Administrator
Base de datos MySQL... u otra?
Rodrigo Fuentealba [EMAIL PROTECTED] wrote: El 16/02/08, Aldrin Martoq [EMAIL PROTECTED] escribió: On Feb 14, 2008 10:52 AM, Nelson [EMAIL PROTECTED] wrote: Hola, necesito migrar una base SQL SERVER a otro motor (necesidades de Performance) He visto bases de datos MSQL volar consumiendo muchos registros (no se cuantos, digamos el año completo de datos desde SAP de un tema especÃfico de una empresa _grande_) en tan solo segundos. SQL Server no es para nada una mala base de datos. Por otro lado (y me lo recordaste cuando mencionaste a SAP), MySQL con todos los registros de un mes de SAP se cayó varias veces en distintos sistemas operativos cuando estuve haciendo algunas asesorias en una forestal, y PostgreSQL tomó poquÃsimos segundos en resolver las mismas consultas. (Ya he comentado esto anteriormente en la lista). Con los mismos indices, etc? Eso puede afectar el rendimiento en forma notable. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From [EMAIL PROTECTED] Sat Feb 16 20:30:35 2008 From: [EMAIL PROTECTED] (Juan Manuel Doren) Date: Sat Feb 16 20:33:59 2008 Subject: A proposito de mySQL Message-ID: [EMAIL PROTECTED] a proposito de mySQL ¿Alguien ha replicado con existo una base grande ( 60 GB ) con mySQL? ¿Alguien lo ha probado como cluster? ¿experiencias que compartir? El 16/02/08, Horst H. von Brand [EMAIL PROTECTED] escribió: Rodrigo Fuentealba [EMAIL PROTECTED] wrote: El 16/02/08, Aldrin Martoq [EMAIL PROTECTED] escribió: On Feb 14, 2008 10:52 AM, Nelson [EMAIL PROTECTED] wrote: Hola, necesito migrar una base SQL SERVER a otro motor (necesidades de Performance) He visto bases de datos MSQL volar consumiendo muchos registros (no se cuantos, digamos el año completo de datos desde SAP de un tema específico de una empresa _grande_) en tan solo segundos. SQL Server no es para nada una mala base de datos. Por otro lado (y me lo recordaste cuando mencionaste a SAP), MySQL con todos los registros de un mes de SAP se cayó varias veces en distintos sistemas operativos cuando estuve haciendo algunas asesorias en una forestal, y PostgreSQL tomó poquísimos segundos en resolver las mismas consultas. (Ya he comentado esto anteriormente en la lista). Con los mismos indices, etc? Eso puede afectar el rendimiento en forma notable. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 -- Juan Manuel Doren Santiago, Chile
Base de datos MySQL... u otra?
2008/2/14, Ricardo Utreras Estrella [EMAIL PROTECTED]: Carlos (casep) Sepulveda escribió: On 14/02/2008, Alvaro Herrera [EMAIL PROTECTED] wrote: Nelson escribió: ¿Qué tan preciados son estos datos? Importante pregunta. La parte del solo lectura no me cuadra, cuales seran los procedimientos de carga de datos? Se entiende de que LAS CONSULTAS seran de solo lectura. Quizas estara armando un sistema para consultar datos resumidos y obtener estadisticas?. .. ey! me huele a olap :p Las consultas siempre son de solo lectura; lo más probable es que se refiera a que en la base de datos no habrá inserciones de manera dinámica, sino algo más estático (por ejemplo, corriendo un batch que obtenga los datos desde un CSV una vez al mes). ROTFL! Sorry, no tengo mi diccionario urbano a la mano. Roll On The Floor Laughing (riendo de guata en el piso) -- Rodrigo Fuentealba Cartes Desarrollador de Sistemas - Consultor UNIX - Database Administrator
Base de datos MySQL... u otra?
El 14/02/08, Nelson [EMAIL PROTECTED] escribió: La base de datos es un 99% texto, menos los indices, algunos campos de fecha y no mucho mas... las consultas generalmente están rankiadas por fechas o grupo de items. No mucho. Es una base tipo OLAP. Como son datos de consulta, en realidad son preciados pero como pueden sacarlo de otra fuente de datos en caso de ser necesario... tampoco son TAN IMPORTANTES... o sea, si sus clientes acceden a datos muy lentos o no pueden acceder por un tiempo, no es de vida o muerte ni mucho menos. Ok; pero siempre es mejor tener los datos frescos, ¿verdad? Pero siempre la idea es hacer algo y que funcione lo mejor posible, por eso la pregunta, si conocen alguna base con 200, 250GB de dato en MySQL y que esta ande considerablemente bien, o se aconseja usar otra cosa. Conozco un par de bases de datos que con 200 Gb andan bien en MySQL; una de ellas es Wikipedia, la otra es la base de índices de Google. Si las relaciones son importantes, pues yo diría que SQL Server no está bien configurado: ¿qué versión es?, ¿tienes las herramientas de OLAP que te entrega Microsoft? ¿Qué tan grandes son las tuplas?, ¿Cómo es la configuración del pool de consulta? -- Rodrigo Fuentealba Cartes Desarrollador de Sistemas - Consultor UNIX - Database Administrator
Base de datos MySQL... u otra?
Rodrigo Fuentealba escribió: 2008/2/14, Ricardo Utreras Estrella [EMAIL PROTECTED]: Se entiende de que LAS CONSULTAS seran de solo lectura. Las consultas siempre son de solo lectura; Generalmente traducimos query por consulta, de modo que hablar de consultas que no son de solo lectura no es, desde ese punto de vista, una contradiccion. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ La victoria es para quien se atreve a estar solo From [EMAIL PROTECTED] Fri Feb 15 16:11:54 2008 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Fri Feb 15 16:15:17 2008 Subject: DNS In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Horst H. von Brand escribió: Miguel Oyarzo O. [EMAIL PROTECTED] wrote: llevo anios leyendo caracteres extranios siendo que se podrian leer mensajes 100% nuestro idioma, tal como lo indica el nombre de la lista: Discusion de Linux en Castellano Tambien preferiria poder manejar acentos y demas, pero no solo incide mi configuración aca, la de Mailman y la del servidor de correo de listas.inf.utfsm.cl, sino la de /todos/ los participantes. Pura alharaca no más. Los sistemas de correo hace rato que están preparados para dejar pasar correctamente los acentos. Fui a mirar el archivo web de la lista, porque no tenía el correo que inició el comentario de Miguel, y me fijé que los acentos están correctamente (*). De hecho, los acentos de mucha gente en esta lista se ven correctamente -- tanto los que usan UTF8 como los que usan iso-8859-1. (Hago notar que a Horst se le escapó un acento en la palabra «configuración» y se ve perfectamente ...) (*) Fue ahí que me di cuenta lo de la lista checa en nuestro archivo Gmane. Por cierto, Lars el de Gmane me respondió diciéndome que estaba viendo cómo corregir el problema. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ La naturaleza, tan frágil, tan expuesta a la muerte... y tan viva From [EMAIL PROTECTED] Fri Feb 15 16:12:52 2008 From: [EMAIL PROTECTED] (Rodrigo Franco) Date: Fri Feb 15 16:44:00 2008 Subject: samba como PDC Message-ID: [EMAIL PROTECTED] H -- Rodrigo Franco Moreno From [EMAIL PROTECTED] Fri Feb 15 16:40:30 2008 From: [EMAIL PROTECTED] (Rodrigo Franco) Date: Fri Feb 15 17:12:06 2008 Subject: samba como PDC Message-ID: [EMAIL PROTECTED] Hola lista: en mi trabajo estoy configurando un servidor Linux Samba como PDC con samba-3.0.28-0.fc8 paquete que trae Fedora Core 8, ahora mi problema es el siguiente, al momento de logear en el dominio todo bien pero cuando se comparte una carpeta en un equipo x de la red para poder entrar a ver la carpeta compartida me pide que coloque el nombre de usuario y contraseña esto es un poco molesto y quisiera saltarme ese paso y entrar derechamente al equipo a ver el la carpeta me leido varios manuales y hecho varias pruebas pero estas no resultan alguno de Uds sabe si es que hay que poner algo en el smb.conf para lograr hacer esto. les muestro como esta configurado mi archivo smb.conf. # Samba config file created using SWAT # from 127.0.0.1 (127.0.0.1) # Date: 2008/02/14 17:29:05 [global] workgroup = ARAUCO server string = Servidor Samba version %v en (%h) ; interfaces = eth0, 145.10.0.0/16 security = user username level = 3 socket options = TCP_NODELAY IPTOS_LOWDELAY logon path = domain logons = Yes os level = 64 preferred master = Yes domain master = Yes wins support = Yes ; valid users = %g hosts allow = 145.10. [homes] comment = Directorio compartido Samba read only = No [printers] path = /usr/tmp/ guest ok = Yes hosts allow = min print space = 2000 printable = Yes browseable = No -- Rodrigo Franco Moreno From [EMAIL PROTECTED] Fri Feb 15 17:40:02 2008 From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Cristian_Mu=F1oz?=) Date: Fri Feb 15 17:49:49 2008 Subject: Bloqueo Msn solo con iptables Message-ID: [EMAIL PROTECTED] Estimados, existe la manera de poder bloquear msn para todos los equipo de una red? (192.168.1.0). He estado leyendo y al parecer solo se puede con iptables + squid, pero lo que quiero es saber si es posible solo con el cortafuegos. Saludos, -- Cristián Muñoz Rosenfeld Técnico universitario en Software Universidad de Viña del Mar Estudiante de Ingeniería Informática INACAP From [EMAIL PROTECTED] Fri Feb 15 17:05:53 2008 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Fri Feb 15 18:01:01 2008 Subject: Base de datos MySQL... u otra? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Nelson wrote: [...] si conocen alguna base con 200, 250GB de dato en MySQL y que esta ande considerablemente bien, Flickr maneja 12 TB de metadata de sus usuarios en tablas InnoDB de MySQL. http://www.highscalability.com/flickr
Base de datos MySQL... u otra?
El Jueves 14 Febrero 2008, Nelson escribió: Hola, necesito migrar una base SQL SERVER a otro motor (necesidades de Performance) De entrada pense en MySql, pero el tema es el siguiente. La base tiene un movimiento mensual aproximado de 20.000.000 de registros, los cuales vienen mensualmente de otro sistema en archivos de texto. El sistema en si sería de solo consulta, pero tengo que importar 10 años de antiguedad, mas los mensuales La pregunta es: será que se bancará manejar tanto volumen de datos MySQL o no? De ya muchas gracias por las respuestas! Saludos Nelson.- Para todo lo demas... Existe PostgreSQL.
Base de datos MySQL... u otra?
Carlos (casep) Sepulveda escribió: On 14/02/2008, Alvaro Herrera [EMAIL PROTECTED] wrote: Nelson escribió: ¿Qué tan preciados son estos datos? Importante pregunta. La parte del solo lectura no me cuadra, cuales seran los procedimientos de carga de datos? Se entiende de que LAS CONSULTAS seran de solo lectura. Quizas estara armando un sistema para consultar datos resumidos y obtener estadisticas?. .. ey! me huele a olap :p -- Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257 Renaming ReiserFS to NinaFS is such an amazingly stupid suggestion, in so many ways, that it ought to qualify for some kind of award. Or perhaps we should name an award after it: the NinaFS award for outstanding crassness. (edmundo, http://lwn.net/Articles/203846/) ROTFL! Sorry, no tengo mi diccionario urbano a la mano. -- Saluda atte., Ricardo Utreras Estrella From [EMAIL PROTECTED] Thu Feb 14 14:55:27 2008 From: [EMAIL PROTECTED] (Nelson) Date: Thu Feb 14 14:58:52 2008 Subject: Base de datos MySQL... u otra? Message-ID: [EMAIL PROTECTED] La base de datos es un 99% texto, menos los indices, algunos campos de fecha y no mucho mas... las consultas generalmente están rankiadas por fechas o grupo de items. Es una base tipo OLAP. Como son datos de consulta, en realidad son preciados pero como pueden sacarlo de otra fuente de datos en caso de ser necesario... tampoco son TAN IMPORTANTES... o sea, si sus clientes acceden a datos muy lentos o no pueden acceder por un tiempo, no es de vida o muerte ni mucho menos. Pero siempre la idea es hacer algo y que funcione lo mejor posible, por eso la pregunta, si conocen alguna base con 200, 250GB de dato en MySQL y que esta ande considerablemente bien, o se aconseja usar otra cosa. ¿Qué clase de base de datos es? ¿Solamente texto? ¿Números? ¿Datos financieros? ¿Genoma? ¿Historial médico? ¿Qué clase de consultas vas a hacerle? Es decir, ¿es del tipo OLTP o más bien OLAP? ¿Qué tan preciados son estos datos? Saludos Nelson.- From [EMAIL PROTECTED] Thu Feb 14 15:42:51 2008 From: [EMAIL PROTECTED] (Daniel Serpell) Date: Thu Feb 14 15:53:08 2008 Subject: ATTN: lista mal configurada en gmane In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Hola! El Wed, Feb 13, 2008 at 01:47:01PM -0300, Alvaro Herrera escribio: [...] Puede verse en el archivo: http://news.gmane.org/gmane.linux.region.chile que hay un montón de posts en checo ... El problema es más sutil: alguien inscribió en gmane la dirección de [EMAIL PROTECTED] en el mismo grupo... por esto, ambas listas quedan juntas en el archivo. Le acabo de mandar un correo a Gmane contando la situación. Daniel.
