Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Sí, puedes buscar ubicaciones cercanas con Redis GEO desde Python asíncrono: carga puntos con GEOADD y consulta un radio o una caja con GEOSEARCH. Pero «sub-milisegundo» no es una promesa de Redis ni de un cliente Python. Es una meta que debes comprobar en tu propia instalación midiendo la consulta completa, incluida la red. La API asíncrona oficial de redis-py está en redis.asyncio; la información disponible no permite verificar qué paquete designa «wredis» ni su API o compatibilidad con GEO, así que el ejemplo usa explícitamente redis-py.

Qué hace Redis GEO y cuándo usarlo

El tipo geoespacial de Redis está pensado para almacenar miembros asociados con coordenadas y localizar los que quedan cerca de un punto. Para el caso habitual —por ejemplo, buscar estaciones próximas a una ubicación— el flujo es directo: guardar cada ubicación en un índice con GEOADD y consultar ese índice con GEOSEARCH. Redis GEO encaja bien con búsquedas sencillas de puntos por distancia; no es una garantía de latencia fija ni un motor de geometría de precisión extrema.

GEOSEARCH está disponible desde Redis 6.2.0. Su consulta define un origen, un área y, si hace falta, el orden, un límite y los campos que se quieren recuperar. La complejidad documentada es O(N + log(M)): N es el número de elementos en el área alineada con la cuadrícula y M el total de elementos del índice. Por tanto, el tamaño total del índice por sí solo no determina el coste de una consulta. La referencia de GEOSEARCH detalla la sintaxis y sus opciones.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Cómo preparar y consultar un índice de puntos

1. Define las coordenadas de forma consistente

Para ubicaciones terrestres, los valores son longitud y latitud. Redis espera el orden longitude latitude, no latitud y longitud. Confirma también que las coordenadas de entrada usan el sistema esperado por tu aplicación y que el radio y las unidades corresponden al caso de uso. Errores de orden, unidades o datos pueden parecer resultados geográficos incorrectos, aunque el comando se ejecute correctamente.

Antes de cargar datos, decide cómo manejar valores ausentes, duplicados y ubicaciones obsoletas. Un miembro representa una ubicación dentro de la clave GEO; si las ubicaciones cambian, actualiza el miembro correspondiente y define una política para retirar datos que ya no sean válidos. La lógica de deduplicación y vigencia pertenece a la aplicación: no debe confundirse con la latencia del comando.

2. Carga puntos con GEOADD

El siguiente ejemplo usa el cliente oficial redis-py y comandos Redis explícitos. Sustituye las coordenadas y nombres por datos de tu aplicación. La operación GEOADD recibe la clave, longitud, latitud y miembro; Redis documenta un coste de O(log(N)) por elemento añadido.

import asyncio
import redis.asyncio as redis

async def main():
    r = redis.Redis(host="localhost", port=6379, decode_responses=True)
    try:
        await r.execute_command(
            "GEOADD", "estaciones", -0.1276, 51.5072, "estacion-central"
        )
    finally:
        await r.aclose()

asyncio.run(main())

En producción, el cliente suele tener una vida útil más larga que una sola operación y se comparte entre tareas. Cierra el cliente cuando termina su ciclo de vida. La documentación asíncrona de redis-py muestra la API en redis.asyncio, el uso de await y las opciones para administrar el cliente y sus conexiones.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

3. Busca en un círculo o una caja

El origen de GEOSEARCH puede ser un miembro ya guardado (FROMMEMBER) o unas coordenadas (FROMLONLAT). El área puede ser un círculo (BYRADIUS) o una caja (BYBOX). Una consulta por radio expresa cercanía alrededor de un punto; una caja delimita una región rectangular. Elige la forma según la pregunta de producto: una caja no equivale a un círculo y puede incluir puntos que queden más lejos de lo que sugeriría una distancia radial.

Este ejemplo busca miembros a un radio especificado, los ordena por distancia ascendente y pide la distancia. Los argumentos de coordenadas siguen el orden longitud-latitud. Ajusta el radio, su unidad y el límite a los requisitos reales de tu aplicación.

async def nearby(r, longitude, latitude, radius, unit, limit):
    return await r.execute_command(
        "GEOSEARCH", "estaciones",
        "FROMLONLAT", longitude, latitude,
        "BYRADIUS", radius, unit,
        "ASC", "COUNT", limit,
        "WITHDIST"
    )

También puedes solicitar coordenadas con WITHCOORD o el hash geográfico con WITHHASH. Esas salidas pueden evitar consultas adicionales cuando la aplicación realmente necesita esos datos. COUNT limita la cantidad de resultados. La opción ANY permite que Redis deje de buscar cuando encuentra suficientes miembros, en vez de continuar para obtener los más cercanos ordenados; úsala solo si un conjunto suficiente de resultados es aceptable y no necesitas que el límite represente estrictamente los más próximos.

La carga y la búsqueda son operaciones distintas: GEOADD prepara el índice y GEOSEARCH lo consulta. Para medir o diagnosticar, registra cuál de ellas estás cronometrando. Redis documenta que GEODIST tiene complejidad O(1), pero obtener distancias una por una para muchos miembros puede añadir viajes de red; cuando sea apropiado, aprovecha las opciones de salida de la búsqueda en lugar de encadenar llamadas.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Usar Python async sin confundir concurrencia con velocidad

En redis-py, importa el cliente con import redis.asyncio as redis y espera cada operación con await. Esto permite que una tarea de Python ceda el control mientras espera I/O; no convierte por sí mismo una búsqueda individual en una consulta más rápida ni hace que Redis procese el comando en menos tiempo.

La instancia Redis se puede compartir entre tareas: el pool atiende la concurrencia con conexiones. En cambio, no compartas una instancia de pipeline ni un objeto Pub/Sub con estado entre tareas como si fueran clientes independientes; cada tarea debe crear su propio pipeline u objeto Pub/Sub. Si usas single_connection_client=True, las operaciones se serializan sobre una sola conexión, lo cual puede contradecir la expectativa de concurrencia. Dimensiona la capacidad del pool para la concurrencia máxima que necesitas, sin olvidar que más conexiones también consumen recursos y pueden aumentar la contención.

Un comando cancelado a mitad de ejecución puede hacer que redis-py desconecte la conexión implicada para evitar que las respuestas de comandos se desalineen. Diseña el manejo de cancelaciones y errores teniendo en cuenta que una operación interrumpida no siempre deja reutilizable esa conexión. Para pipelines, usa el ámbito y ciclo de vida que correspondan, por ejemplo un contexto asíncrono; al finalizar el uso de un cliente de vida larga, llama a await r.aclose(). La documentación del cliente explica estas reglas de ciclo de vida y concurrencia.

asyncio.gather() puede ejecutar varias operaciones independientes concurrentemente y ayudar al throughput de una aplicación bajo ciertas condiciones, pero no reduce automáticamente la latencia de una sola consulta. Puede incrementar conexiones en uso y contención. Si el objetivo es reducir el tiempo de una sola petición que realiza varias operaciones, evalúa si se pueden agrupar con un pipeline o sustituir varios viajes por un comando que devuelva la información necesaria. El pipelining reduce viajes de ida y vuelta; no cambia la semántica de la consulta ni garantiza que el procesamiento del servidor sea menor.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Qué significa realmente «sub-milisegundo»

Hay al menos dos mediciones distintas: el tiempo que Redis dedica a procesar un comando y el tiempo de ida y vuelta que observa la aplicación. La segunda puede incluir red, planificación del sistema, serialización y trabajo de la propia aplicación. La guía de Redis sobre latencia indica que el servidor suele procesar muchos comandos en menos de un microsegundo, pero eso no incluye el coste completo que paga un cliente. Redis cita como ejemplos alrededor de 200 μs para una red típica de 1 Gbit/s y hasta 30 μs con un socket Unix; son cifras condicionadas por el hardware y el sistema, no presupuestos universales para una consulta GEO.

La guía formula una advertencia útil: “The consequence is even if Redis processes most commands in sub microsecond range, a client performing many roundtrips to the server will have to pay for these network and system related latencies.” Es decir, varios viajes de ida y vuelta pueden dominar incluso cuando el procesamiento del servidor es muy rápido. Consulta Diagnosing latency issues para el contexto y las recomendaciones de diagnóstico.

Un benchmark publicado por Redis para GEOSEARCH BYBOX en un caso con 60 millones de elementos reportó latencia p50 con RTT de 605.739 ms en Redis 7.0.5 y 161.791 ms en Redis 7.0.7, en el caso identificado como geo-60M-elements-geosearch-fromlonlat-bybox. Esos valores describen ese benchmark, sus versiones y condiciones; no son mediciones de redis-py o «wredis», ni predicen el tiempo de una consulta con otro tamaño de índice, hardware o topología. El artículo de Redis sobre comandos geográficos en Redis 7 permite revisar el contexto del resultado.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Cómo medir tu propia latencia

Define primero qué resultado necesitas: latencia de una consulta aislada, percentiles bajo carga o throughput con varias tareas. Para afirmar que la consulta de tu aplicación responde por debajo de un milisegundo, mide la ruta que usa realmente la aplicación, no solo el tiempo interno del servidor. Conserva suficientes observaciones para calcular p50, p95 y p99; una media aislada puede ocultar una cola lenta.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Fija y registra el entorno. Anota las versiones exactas de Python, el cliente, Redis y el sistema operativo; indica dónde se ejecutan cliente y servidor y si se conectan por TCP o socket Unix.
  2. Describe la consulta. Registra el tamaño y la distribución del índice, si el origen es miembro o coordenadas, si el área es radio o caja, el radio o dimensiones y unidades, el orden, COUNT, ANY y las opciones de salida.
  3. Controla las condiciones. Indica número de resultados, concurrencia, calentamiento y estado de caché, así como duración y metodología de la prueba. Evita presentar una medición en frío como si describiera el comportamiento estable, o viceversa.
  4. Separa los componentes del tiempo. Explica si el cronómetro incluye serialización, ida y vuelta de red y trabajo de aplicación. Si puedes medir el tiempo de cliente y servidor por separado, conserva ambos en lugar de llamar «latencia» a una cifra sin definirla.
  5. Prueba el patrón real de carga. Mide las consultas representativas con la concurrencia prevista. Cambia una variable cada vez —por ejemplo, radio, límite o salida solicitada— y vuelve a medir percentiles, no solo una ejecución.

Si el resultado supera el objetivo, comprueba primero si se están haciendo viajes innecesarios, si se solicitan datos que la aplicación no usa o si el patrón de concurrencia satura el pool o el servidor. Luego revisa la forma y el alcance de la consulta, la red y la topología. Reducir el número de resultados puede ayudar a limitar el trabajo y la respuesta; usar ANY cambia el criterio de selección, no es un sustituto de ordenar con exactitud por distancia.

¿Qué significa wredis en este título?

El nombre «wredis» no identifica por sí solo una API que pueda usarse con seguridad en este ejemplo. No está establecido aquí qué paquete concreto se pretende, qué versión ofrece, si se mantiene ni si implementa comandos GEO. Por ello, no conviene inventar un import, una firma de función o una compatibilidad con GEOSEARCH. Antes de adaptar el patrón, confirma el proyecto exacto y consulta su documentación oficial; comprueba que la versión elegida expone comandos GEO y cómo gestiona await, conexiones, cancelaciones y cierre del pool.

El código de este artículo se basa expresamente en redis.asyncio, la interfaz asíncrona oficial de redis-py. Redis como servidor define los comandos y capacidades GEO; el cliente Python define cómo invocarlos de manera asíncrona. Son capas separadas: un cliente no puede ofrecer una operación de servidor que la versión de Redis no soporte, y que un cliente use asyncio no garantiza una latencia determinada.

Cuándo el tipo GEO deja de ser suficiente

Para puntos y búsquedas sencillas por distancia, GEO es el ajuste directo. Si la necesidad incluye polígonos, otras formas o relaciones geométricas como WITHIN, CONTAINS, INTERSECTS o DISJOINT, consulta las capacidades geoespaciales de Redis Search y su tipo GEOSHAPE. Su aproximación esférica no es apropiada cuando se exige precisión geográfica extrema. La documentación de geoespacial en Redis Search describe las formas y relaciones disponibles y sus límites.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.