Algunas ideas:

• El método list() con limit: 1 devolvería el primer elemento en un rango de lista, lo que podría facilitar el "escaneado" de la tabla. list() solo devuelve claves, no valores, pero también devuelve metadatos; si su valor se ajusta a los metadatos, puede ponerlo allí y list() lo devolverá. Desafortunadamente, list() no le permite especificar un rango, solo un prefijo, por lo que puede ser un poco complicado formular consultas. Además, las operaciones list() son más caras que get() tanto en términos de facturación como de rendimiento.

• Otro diseño posible podría ser agrupar sus datos por subred, por ejemplo, almacenar una clave para cada /24 , donde el valor contiene todos los rangos que están debajo de ese /24 (estoy usando /24 como ejemplo, pero un tamaño más grande podría tiene sentido dependiendo del conjunto de datos). Luego, solo tiene que hacer una búsqueda de una dirección IP en particular, buscando la subred que la rodea. Como optimización adicional, si es común ver rangos de IP que son mucho más grandes que un solo /24 , podría, por ejemplo, almacenarlos como /16 s, y luego en cada búsqueda necesitaría verificar tanto el /24 como /16 teclas. O, tal vez, hay pocos rangos "grandes" suficientes para que pueda incrustarlos directamente en su secuencia de comandos de Worker y evitar la necesidad de realizar una búsqueda. Como beneficio adicional, este enfoque probablemente utilizaría mejor el caché, si está buscando direcciones IP de clientes. Los clientes en la misma subred tenderían a estar en la misma ubicación y alcanzarían el mismo color de Cloudflare, por lo que si todos se asignan a la misma clave en su espacio de nombres KV, entonces los datos tenderían a estar tibios en caché en ese color.