No sé si necesitarás una BD NoSQL. Si usaa IO::YAML puedes escribir directamente estructuras de datos y luego leerlas. Yo he manejado ficheros de varios cientos de megas con ella y no me ha dado ningún problema. Más allá sí te vendrá bien el NoSQL, pero siempre que puedas usar alguna cosa razonable para indexar; la búsqueda fuera de las claves no es trivial. Si esto es lo que tienes que hacer, yo he usado CouchDB y va bastante bien, es rápida y puedes programarla en JavaScript, pero la que es la caña es Redis, super rápida (aunque no persistente).
Saludos El 28 de junio de 2013 23:37, Fernando González Pinilla < [email protected]> escribió: > hmm tiene muy buena pinta, pero es demasiado para lo que quiero además no > me apetece pringarme a manejar SQL. Creo que finalmente voy a usar hashes y > arrays en DBM::deep que parece ser bastante rápido y, sobretodo sencillo, > no me sobra tiempo precisamente como para complicarme la vida > > Muchas gracias igualmente :D > > > El 27 de junio de 2013 10:45, Rodrigo <[email protected]> escribió: > > Hola Fernando, te recomiendo MongoDB. La instalación es fácil, el esquema >> de datos es flexible, la bbdd está pensada para almacenar gran cantidad de >> datos (por eso se llama "mongo", de humongous, o mogollón). Mongo tiene las >> capped collections, que son "tablas" pensadas precisamente para logs, y que >> se purgan solas. Ahora también soporta búsquedas de texto. El driver de >> Perl es bastante agradable de usar para un no-programador, te permite >> almacenar los hashes y arrays de toda la vida. Caveats: pues asegúrate que >> la bbdd va a estar instalada en las plataformas soportadas (intel... Linux, >> OSX, Windows, Solaris) y que el SO sea de 64 bits, porque los de 32 bits >> tienen la bbdd limitada a 2GB. >> >> Para algo más pequeño yo consideraría también SQLite. Si la usas con un >> módulo como DBIx::NoSQL (no lo he usado en producción nunca) tienes la >> flexibilidad de no necesitar un esquema de tabla. A veces es mejor apostar >> por lo relacional, nunca sabes la importancia que puede llegar a tener tu >> aplicación en el futuro, sobretodo si se trata de un planificador de >> procesos batch, y lo relacional puede venir bien a la hora de incorporarse >> en otra bbdd más grande, integrarse con otros modelos de datos, o >> simplemente delegar el mantenimiento a otras personas. >> >> En todo caso, yo evitaría Data::Dumper a fichero o a columna de tabla, te >> vas a pillar los dedos el momento que necesites hacer cualquier consulta y >> tengas que "inflar" objeto a objeto.... >> >> un saludo >> >> 2013/6/26 Fernando González Pinilla <[email protected]> >> >>> Buenas a todos, >>> >>> soy un sysadmin no programador que escribo por primera vez y me siento >>> un poco "HOYGAN", así que sed buenos conmigo. >>> >>> estoy haciendo una especie de planificador de procesos batch en perl que >>> debe guardar registros de los resultados de cada ejecución (código de >>> retorno, salida por stdin y stdout, fecha, etc). El caso es que me gustaría >>> guardar todo esto en un log medianamente serio al que poner hacer consultar >>> facilonas pero que no se pueden resolver fácilmente con un grep por ser >>> multilínea. >>> >>> Tampoco me gustaría andar metiendo todo eso en una base de datos >>> relacional por no complicar el asunto. Lo que necesito es algo que se pueda >>> guardar en formato texto pero que tenga determinados campos indexados para >>> búsquedas rápidas. >>> >>> He pensado en exportar todo con Data::Dumper o hacer una BerkeleyDB. >>> ¿Qué me recomendáis? >>> >>> Gracias de antebraso :-) >>> >>> Saludos >>> >>> _______________________________________________ >>> Madrid-pm mailing list >>> [email protected] >>> http://mail.pm.org/mailman/listinfo/madrid-pm >>> >> >> >> _______________________________________________ >> Madrid-pm mailing list >> [email protected] >> http://mail.pm.org/mailman/listinfo/madrid-pm >> > > > _______________________________________________ > Madrid-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/madrid-pm > -- JJ
_______________________________________________ Madrid-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/madrid-pm
