Los filtros Bloom permiten descartar consultas innecesarias a una base de datos con muy poca memoria. Su respuesta distingue entre un elemento ausente y uno posiblemente presente: un positivo necesita confirmación cuando la aplicación exige exactitud. El ahorro consiste en evitar parte de las búsquedas, manteniendo la base de datos como referencia definitiva.
Al insertar un elemento, el filtro activa varias posiciones de un arreglo de bits mediante funciones hash. Al consultar, un cero descarta el elemento. Todos los bits activados indican una posible coincidencia.
La documentación de Redis explica su uso como comprobación previa. Por ejemplo, un servicio puede filtrar búsquedas de identificadores inexistentes antes de consultar el almacenamiento. Si el resultado es positivo, continúa con la búsqueda habitual; un falso positivo solo añade una consulta que se quería evitar.
La precisión se paga con memoria
El tamaño depende de cuántos elementos se esperan y de la probabilidad de falso positivo aceptable. Para una capacidad n y una tasa p, Redis calcula aproximadamente m = -n × ln(p) / (ln(2))² bits y redondea hacia arriba k = -ln(p) / ln(2) para elegir el número de posiciones que comprobar.
La documentación de BF.RESERVE sitúa una tasa del 1 % en 9.585 bits por elemento y siete posiciones. Aplicar esa fórmula a un millón de elementos da unos 1.20 MB decimales para el arreglo de bits, antes de metadatos y otros gastos de implementación. Es un cálculo de dimensionamiento, no una medición de memoria de un servicio.
La definición de Guava aclara el denominador: ese 1 % se refiere a consultas de elementos que no se insertaron. No significa que el 1 % de todas las respuestas positivas sea incorrecto.
Un solo hash también genera varias posiciones
Jim Calabro explica, en su publicación del 17 de octubre de 2026, cómo un solo hash permite obtener varias posiciones: divide el arreglo en particiones de tamaños coprimos por pares, sin divisores comunes distintos de uno, y calcula el residuo para cada tamaño.
Su implementación, gloom, agrupa además los accesos en bloques alineados con la caché del procesador.
Lo que debe sostener la implementación
Guava advierte que insertar muchos más elementos de los previstos satura el filtro y deteriora la probabilidad de falso positivo. Redis ofrece crecimiento mediante subfiltros, con un costo adicional de memoria y consultas. Dimensionar por debajo del uso real desplaza ese costo hacia la operación diaria.
La garantía de ausencia de falsos negativos se refiere al conjunto insertado. Si un registro nuevo todavía no llegó al filtro, un negativo puede descartar un dato que ya existe en la base. Como otros elementos pueden compartir los mismos bits, apagarlos para borrar uno puede ocultar otro. Para reflejar borrados se puede reconstruir el filtro o elegir una estructura que admita eliminación.
El acceso simultáneo requiere una implementación preparada. Guava documenta operaciones seguras entre hilos y sin bloqueos desde su versión 23.0. Eso resuelve la concurrencia interna; mantener el filtro sincronizado con los datos sigue siendo responsabilidad del sistema que lo integra.
Calabro atribuye la reducción de los despliegues de Bluesky de 90 a unos 15 minutos al reemplazo de bloqueos por operaciones atómicas. El uso posterior de un solo hash no aportó otra mejora perceptible. Medir la espera entre hilos permitió localizar el trabajo que frenaba el despliegue.
