¿Cómo consultar una API web remota contra una base de datos MySQL local durante un pico de tráfico?

Question

Estamos implementando un código en nuestra página de inicio que depende de una búsqueda de geoip para cada vistor único y tenemos la opción de consultar un servicio web de geodatos (Maxmind) o descargar la base de datos y consultarla localmente. El servidor es actualmente una instancia de Linode de 512 MB y solo recibe alrededor de 1500 únicos por día, sin embargo, nos preocupa lo que sucederá durante un pico de tráfico.

Está claro para mí que la búsqueda local sería más rápida, pero seguramente bajo carga golpear la base de datos sería mucho más RAM/CPU que procesar una solicitud http adicional. Obviamente, la actualización de la memoria de los servidores se logra fácilmente si ir localmente es la mejor ruta. Me imagino que a través de una cierta cantidad de conexiones por segundo, es más probable que el servidor no esté disponible consultando su base de datos local que una API web (asumiendo por supuesto que los servidores de API web pueden manejar las solicitudes http).

Cualquier contribución sobre qué solución sería la solución más robusta a largo plazo para manejar la ocasional inundación del tráfico sin denegación de servicio sería muy apreciada.

EDITAR: Solo para intentar cuantificar esto un poco más, digamos que el servidor necesitaría poder manejar hasta 200 conexiones por segundo. Cada conexión requiere una única consulta DB o una solicitud http.

Answer 1

Dada 200 visitas por segundo, definitivamente desea ir a una base de datos local. Dudo que un sitio web de un tercero que proporcione un servicio de este tipo desee manejar tantas solicitudes, pero incluso si lo hicieran, es probable que sea mucho más lento que el acceso a la base de datos local.

Por supuesto, desea aumentar la memoria significativamente en el servidor local. Tenga en cuenta que la memoria es extremadamente barata hoy en día. Por ejemplo, hace aproximadamente 1 1/2 años construí una caja Linux con 32 gigas de RAM, y la última CPU por menos de $ 1000.

200 visitas por segundo pueden requerir una base de datos agrupada y varios servidores. También puede considerar usar un almacén de valores clave para esto, que puede manejar potencialmente miles de visitas por segundo.

Answer 2

Su proveedor cobra su servicio web mediante la consulta. De acuerdo con las tarifas anunciadas en su sitio web, a 200 q/s, pagaría ... $ 72 por hora. ¡Puedes obtener docenas de servidores dedicados a monstruos para este tipo de dinero!

Answer 3

En mi trabajo, utilizamos una versión local de la base de datos Maxmind, que es un archivo .dat, y consultamos ese archivo constantemente (alrededor de 500 mil veces al día o más) sin ningún problema. A continuación, almacenamos en caché la información en una sesión para que no tengamos que consultar esa información para el mismo usuario una y otra vez. También tenemos una herramienta publicitaria que utiliza la base de datos Maxmind y luego busca anuncios que se muestran dentro de un radio de 10, 25 o 50 millas de ese usuario.

No recomendaría usar la API para demasiadas solicitudes o simplemente pueden interrumpirte sin previo aviso y ahora no tienes información de Geo. Además, si sus servidores caen, nuevamente no tiene información de Geo.

Answer 4

La mejor forma de averiguarlo es realizar una prueba de carga y comprobar por ti mismo qué funciona mejor. Pero mi intuición es que 200 consultas por segundo no son demasiado y pueden manejarse fácilmente de la forma que prefiera.

Me inclino por usar un servidor local con una base de datos gis porque el local es más barato (sin costos por consulta) y un solo servidor es más fácil de actualizar. Además, puede escalar si es necesario agregando un segundo servidor o configurando un servidor de terceros.

me encontré con algunos números reales de la prueba para esta configuración aquí: http://blog.jcole.us/2007/11/24/on-efficiently-geo-referencing-ips-with-maxmind-geoip-and-mysql-gis/ Esta es la configuración de red en cuatro clientes consultar un único servidor. Para un único cliente, informa 2000 consultas/segundo y latencias por debajo de 1 ms. Tenga en cuenta que utiliza las funciones gis integradas en mysql para alcanzar estos números. Además, esto fue en 2007, por lo que el rendimiento debería ser incluso mejor ahora.

Haga que su código sea modular y configurable. Esto depende del lenguaje de programación, por supuesto, pero crea una interfaz LookupService para que puedas crear diferentes implementaciones si es necesario sin cambiar el resto del código. Si la implementación llama a un servicio web, haga que el punto final sea fácilmente configurable. Si su servicio utiliza el mismo URI scheme and response json as maxmind, puede cambiar a voluntad desde su propio servidor local a maxmind y viceversa.