[pyar] Me recomiendan un diccionario?

[Angel Java Lopez]

Con respecto a

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 que no hacer entonces:

 - d = {} # esto lo hago al principio
 - d[k] = v # despues hago esto 20M veces <--- SOLO 20 MILLONES
 - algo(d[k]) # y despues hago esto 20M veces
 - d = {} # esto lo hago la segunda vez
 - d[k] = v # despues hago esto 20M veces con el resto de las claves
 - algo(d[k]) # y despues hago esto 20M veces

?

Angel "Java" Lopez
@ajlopez

2014-02-27 19:10 GMT-03:00 Daniel Moisset <dmoisset en machinalis.com>:

> 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
>>
>
>
> _______________________________________________
> 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/20140228/4083de07/attachment-0001.html>