✨︎ Resumen (TL;DR):
- Los filtros Bloom descartan consultas antes de llegar a la base de datos.
- Con una tasa de falsos positivos de 1 %, la documentación de
BF.RESERVEsitúa el diseño en 9.585 bits por elemento y 7 posiciones.- La capacidad prevista y la sincronización determinan si el ahorro se mantiene en producción.
Los filtros Bloom permiten que un servicio descarte búsquedas innecesarias antes de consultar una base de datos, un uso que Redis documenta como comprobación previa. Ahorran memoria al distinguir una ausencia de una posible coincidencia, pero un resultado positivo necesita confirmación cuando la aplicación exige exactitud. La base de datos sigue siendo la referencia definitiva.
Filtro Bloom es una estructura de bits que filtra consultas y responde si un elemento está ausente o posiblemente presente. Al insertar un elemento, activa varias posiciones de un arreglo de bits mediante funciones hash.
Al consultar, el resultado tiene dos lecturas:
- Un bit en cero: el filtro descarta el elemento.
- Todos los bits activados: hay una posible coincidencia y la aplicación debe continuar con la búsqueda habitual.
Un falso positivo agrega una consulta que el filtro pretendía evitar.
La memoria define la tasa de falsos positivos
El tamaño del filtro depende de cuántos elementos se esperan y de la tasa 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.
En BF.RESERVE, la documentación sitúa una tasa de 1 % en 9.585 bits por elemento y 7 posiciones. Aplicar esa fórmula a un millón de elementos da unos 1.20 MB decimales para el arreglo de bits, antes de sumar metadatos y otros gastos de implementación. Es un cálculo de dimensionamiento, no una medición de la memoria total de un servicio.
Guava aclara qué representa ese porcentaje: el 1 % se refiere a consultas de elementos que no se insertaron. No significa que 1 % de todas las respuestas positivas sea incorrecto.
Un solo hash también genera varias posiciones
En una publicación del 17 de octubre de 2026, Jim Calabro explica cómo un solo hash permite obtener varias posiciones. La técnica divide el arreglo en particiones cuyos tamaños son coprimos por pares, es decir, no comparten divisores 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.
La capacidad prevista importa en producció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, aunque ese mecanismo añade memoria y consultas.
Dimensionar el filtro por debajo del uso real traslada el costo a la operación diaria. El ahorro inicial de memoria no elimina la necesidad de planear cuántos elementos recibirá.
Un filtro Bloom no produce falsos negativos para los elementos que sí fueron insertados. Sin embargo, si un registro nuevo ya existe en la base de datos y todavía no llegó al filtro, un resultado negativo puede hacer que el sistema descarte ese dato.
Los elementos pueden compartir los mismos bits. Por eso, apagar los bits de uno para borrarlo puede ocultar otro. Para reflejar los borrados, hay que reconstruir el filtro o elegir una estructura que admita eliminación.
La concurrencia no resuelve la sincronización
El acceso simultáneo exige una implementación preparada. Guava documenta operaciones seguras entre hilos y sin bloqueos desde la versión 23.0. Eso resuelve la concurrencia interna del filtro, pero el sistema que lo integra todavía debe mantenerlo sincronizado con los datos.
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 produjo otra mejora perceptible. Medir la espera entre hilos permitió localizar el trabajo que frenaba el despliegue.
El filtro Bloom funciona como una comprobación previa, no como la fuente de verdad: elimina parte de las consultas, pero no confirma por sí mismo que un elemento exista. Su utilidad depende de dimensionarlo con la carga prevista y de mantenerlo alineado con la base de datos.
