[Madrid-pm] consulta sobre NoSQL

[JJ Merelo]

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 <
fgonzalezp en gmail.com> 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 <rodrigolive en gmail.com> 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 <fgonzalezp en gmail.com>
>>
>>> 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
>>> Madrid-pm en pm.org
>>> http://mail.pm.org/mailman/listinfo/madrid-pm
>>>
>>
>>
>> _______________________________________________
>> Madrid-pm mailing list
>> Madrid-pm en pm.org
>> http://mail.pm.org/mailman/listinfo/madrid-pm
>>
>
>
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>



-- 
JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20130629/44b0aa9b/attachment.html>