[pyar] Me recomiendan un diccionario?

[Angel Java Lopez]

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

Digo, por que no querer separar en bloques? La semantica sigue siende
sencilla



2014-02-28 7:45 GMT-03:00 Angel Java Lopez <ajlopez2000 en gmail.com>:

>
> 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/b92e5d30/attachment.html>