48 min
Podcast Z #7: Proyecto X - Filtros BLOOM Podcast Z
-
- Tecnología
Estructura para comprobar pertenencia a un conjunto, de forma probabilística. https://podcast.jcea.es/podcastz/7
Notas:
01:00: Filtros Bloom. Tecnología interesante y desconocida.
01:30: El número de huellas ha ido creciendo, y la estructura de datos que usamos, "set()", tiene un coste
en memoria proporcional al número de elementos. Estábamos usando 1.5GB en 32 bits, y 3GB en 64 bits.
04:30: Las huellas eran 40 millones de números (y creciendo) de 32 bits. Son 150MB en disco, pero 1.5/3 gigabytes al
cargarlos en un "set()".
05:40: Idea simple para reducir los 1.5/3GB a 512MB: como trabajamos con números de 32bits, podemos tener una
matriz de 232 bits y ponerlos a cero o a uno según ese valor esté en la lista o no. Esto son 512MB.
07:15: Como tenemos una matriz de 232 bits, pero solo un 1% estará a UNO, los 512MB resultantes
se pueden comprimir muy bien, típicamente al 11% (unos 55MB), aptos para ser transmitidos por Internet.
08:40: La matriz así generada no tiene falsos positivos ni falsos negativos, pero como los datos de entrada son
una lista de 32 bits, que es una "reducción" de la fuente real original, esa lista ya induce falsos positivos. Es decir,
diferentes valores en el origen que generan el mismo número de 32 bits.
10:10: Para el cliente, reducir el consumo de memoria a 512MB sigue siendo insuficiente. Su objetivo es llegar
a ocupar solo 64-128MB. Lo consigo reducir a 32MB, usando un filtro Bloom.
11:00: Si en vez de introducir falsos positivos en la reducción de 128bits a 32 bits, podemos utilizar los 128bits
originales y usar una estructura de datos con falsos positivos, una estructura "probabilística".
13:50: Explicación de cómo funciona un filtro Bloom
y su tasa de falsos positivos.
14:55: "Te lo voy a explicar a ti, a ver si explicándotelo me aclaro" :-).
17:10: Explicando el concepto de "colisiones" y por qué son inevitables. Falsos positivos.
23:00: Controlamos la tasa de falsos positivos añadiendo más o menos bits y controlando el número de bits puestos
a UNO por cada valor original (y el número de bits que deben ser UNO para tener un "hit").
25:30: Ahora en cada búsqueda tenemos un 2% de falsos positivos en vez del 1% inicial, pero hacemos dos búsquedas,
así que la tasa de falsos positivos es del 2% del 2%, o 4 de cada 10.000 (aproximadamente).
30:30: Filtro Bloom. Hay un número óptimo de búsquedas.
Las ecuaciones están en la Wikipedia.
35:45: Un filtro Bloom no se puede comprimir, su entropía
es máxima.
37:00: ¿Cómo "desdoblamos" los valores?. Es decir, que a partir de un valor de entrada, podemos poner varios bits
a UNO, de forma no correlada.
40:30: En la bibliografía de la Wikipedia se estudian algoritmos y el impacto de rendimiento que supone que los bits
puestos a UNO no sean completamente no correlados. Por ejemplo:
Kirsch, Adam; Mitzenmacher, Michael (2006), "Less Hashing, Same Performance: Building a Better Bloom Filter", in Azar, Yossi;
Erlebach, Thomas, Algorithms - ESA 2006, 14th Annual European Symposium, 4168, Springer-Verlag, Lecture Notes in
Computer Science 4168, pp. 456-467, doi:10.1007/11841036
43:20: Estamos abusando de las matemáticas del filtro Bloom,
así que antes de distribuir el filtro hacemos una
simulación con él en el servidor.
45:30: Un filtro Bloom tiene falsos positivos,
pero NO tiene falsos negativos.
Estructura para comprobar pertenencia a un conjunto, de forma probabilística. https://podcast.jcea.es/podcastz/7
Notas:
01:00: Filtros Bloom. Tecnología interesante y desconocida.
01:30: El número de huellas ha ido creciendo, y la estructura de datos que usamos, "set()", tiene un coste
en memoria proporcional al número de elementos. Estábamos usando 1.5GB en 32 bits, y 3GB en 64 bits.
04:30: Las huellas eran 40 millones de números (y creciendo) de 32 bits. Son 150MB en disco, pero 1.5/3 gigabytes al
cargarlos en un "set()".
05:40: Idea simple para reducir los 1.5/3GB a 512MB: como trabajamos con números de 32bits, podemos tener una
matriz de 232 bits y ponerlos a cero o a uno según ese valor esté en la lista o no. Esto son 512MB.
07:15: Como tenemos una matriz de 232 bits, pero solo un 1% estará a UNO, los 512MB resultantes
se pueden comprimir muy bien, típicamente al 11% (unos 55MB), aptos para ser transmitidos por Internet.
08:40: La matriz así generada no tiene falsos positivos ni falsos negativos, pero como los datos de entrada son
una lista de 32 bits, que es una "reducción" de la fuente real original, esa lista ya induce falsos positivos. Es decir,
diferentes valores en el origen que generan el mismo número de 32 bits.
10:10: Para el cliente, reducir el consumo de memoria a 512MB sigue siendo insuficiente. Su objetivo es llegar
a ocupar solo 64-128MB. Lo consigo reducir a 32MB, usando un filtro Bloom.
11:00: Si en vez de introducir falsos positivos en la reducción de 128bits a 32 bits, podemos utilizar los 128bits
originales y usar una estructura de datos con falsos positivos, una estructura "probabilística".
13:50: Explicación de cómo funciona un filtro Bloom
y su tasa de falsos positivos.
14:55: "Te lo voy a explicar a ti, a ver si explicándotelo me aclaro" :-).
17:10: Explicando el concepto de "colisiones" y por qué son inevitables. Falsos positivos.
23:00: Controlamos la tasa de falsos positivos añadiendo más o menos bits y controlando el número de bits puestos
a UNO por cada valor original (y el número de bits que deben ser UNO para tener un "hit").
25:30: Ahora en cada búsqueda tenemos un 2% de falsos positivos en vez del 1% inicial, pero hacemos dos búsquedas,
así que la tasa de falsos positivos es del 2% del 2%, o 4 de cada 10.000 (aproximadamente).
30:30: Filtro Bloom. Hay un número óptimo de búsquedas.
Las ecuaciones están en la Wikipedia.
35:45: Un filtro Bloom no se puede comprimir, su entropía
es máxima.
37:00: ¿Cómo "desdoblamos" los valores?. Es decir, que a partir de un valor de entrada, podemos poner varios bits
a UNO, de forma no correlada.
40:30: En la bibliografía de la Wikipedia se estudian algoritmos y el impacto de rendimiento que supone que los bits
puestos a UNO no sean completamente no correlados. Por ejemplo:
Kirsch, Adam; Mitzenmacher, Michael (2006), "Less Hashing, Same Performance: Building a Better Bloom Filter", in Azar, Yossi;
Erlebach, Thomas, Algorithms - ESA 2006, 14th Annual European Symposium, 4168, Springer-Verlag, Lecture Notes in
Computer Science 4168, pp. 456-467, doi:10.1007/11841036
43:20: Estamos abusando de las matemáticas del filtro Bloom,
así que antes de distribuir el filtro hacemos una
simulación con él en el servidor.
45:30: Un filtro Bloom tiene falsos positivos,
pero NO tiene falsos negativos.
48 min