[pyar] Me recomiendan un diccionario?

[Daniel Moisset]

no, no necesito acceso concurrente. es un solo proceso, one shot que guarda
los datos, los lee, los tira. Es algo que funcionalmente un dict() de
python me alcanza, pero tengo un pico de uso de RAM que quiero evitar, si
se puede (sobre todo porque en una compu de 32 bits el limite de tamaño por
proceso hace que no funcione)

Gracias a todos por las sugerencias. mcuhas las conocia, unas pocas no; no
me interesa tanto el catalogo como evaluaciones de pros y cons

Algunas cosas:

Hasta 5-10 minutos me banco la perdida de performance. No quiero ensuciar
el codigo con optimizaciones (separar en bloques, hacer sharding, remapear
los datos, etc). Quiero algo donde pueda cambiar uno a uno las lineas
 - d = {} # esto lo hago al principio
 - d[k] = v # despues hago esto 40M veces
 - algo(d[k]) # y despues hago esto 20M veces

por mapeos uno a uno de la biblioteca que use, y que tenga la misma
semántica.

- hacerlo con un dict (en una maquina que se la banque) me tarda 1.5
minutos meterle todo adentro (no tengo el codigo que usa los datos como
para medir, pero sospecho que va a ser blazing fast).
- probe con redis, usando set directamente, y usando hset (para hmset tengo
que separar por bloques, no mantengo simplicidad). No termine, pero
haciendo una cuenta, va a tardar como 45 minutos, no me sirve. sospecho que
el overhead de comunicacion lo mata. voy a descartar por eso memcached
- voy a seguir probando con sqlite, bdb (a bdb le tengo fe, la he usado
antes para algo similar, pero quería algo mas "moderno") y CodernityDB [si
logro entender la doc de la API], y les cuento

D.




2014-02-27 18:52 GMT-03:00 Julian Agustin Cardonnet <jcardonnet en gmail.com>:

> El 27 de febrero de 2014, 17:46, Daniel Moisset <dmoisset en machinalis.com>escribió:
>
> Hola,
>>    ando necesitando algo que, por un ratito me guarde varias asignaciones
>> clave valor y despues poder consultarlo por clave, para obtener el valor
>> asociado.
>>
>> O sea, necesito un dict().
>>
>> Mi problema es que:
>>  - tengo que guardar >40 millones de asociaciones, donde cadena+valor son
>> en promedio 50 bytes de utf8
>>  - tengo que hacer ~20 millones de consultas
>>
>> Con lo cual un dict() me anda en una maquina con de 64-bits con buena
>> RAM, y prefiría que los requerimientos sean un poco mas modestos
>>
>> Mi patron de uso es bien simplon. Primero genero todos los datos y los
>> cargo, despues hago todas las consultas, despues tiro el "diccionario" a la
>> basura (no me interesa persistirlo ni nada).
>>
>> Se me ocurren infinitas (muchas) formas de hacerlo. Puedo usar un sqlite,
>> un mongo, una berkeleydb, y muchas mas. La pregunta es:
>>
>> ¿que usarian ustedes que tenga una buena combinación de performance y
>> simpleza? [dentro del use-case que mencioné]
>>
>
> Algo que no aclaras es si necesitas acceso concurrente a key/value store.
> Si es asi (corrijanme si mando fruta) con BDs serverless al estilo SQLite
> vas a tener problemas (no se con DBD).
> En ese caso podes probar con Kyoto Cabinet [1] para la DB y meterle Kyoto
> Tycoon como server para manejar el acceso concurrente.
> Este es el chivo de la pagina:
> "Kyoto Cabinet runs very fast. For example, elapsed time to store one
> million records is 0.9 seconds for hash database, and 1.1 seconds for B+
> tree database. Moreover, the size of database is very small. For example,
> overhead for a record is 16 bytes for hash database, and 4 bytes for B+
> tree database. Furthermore, scalability of Kyoto Cabinet is great. The
> database size can be up to 8EB (9.22e18 bytes)."
>
> [1] http://fallabs.com/kyotocabinet/
>
> Saludos,
> Julian
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140227/a4b4adae/attachment.html>