El día 4 de enero de 2010 13:05, Daniel Pizarro <[email protected]> escribió: > Entiendo que la solución de un WebService centralizado para verificar el > operador, es al que más entusiasma por aquí, sin embargo hay que tener en > cuenta lo siguiente:
¿Que otras soluciones hay? > - Debe ser una BD orientada a este tipo de queries (jerarquica vs > relacional), administrada y "hosteada" por el MTC u OSIPTEL. Los operadores > no van a prestar sus sistemas de BD para ello. Esto es muy probable, pero ya que los suscriptores no cambian de operador todos los dias tiene todo el sentido del mundo utilizar un sistema similar al DNS en donde se consulta un "caché" y no a la base de datos centralizada salvo que el TTL ya se venciera o no se tuviera el registro localmente. > - La BD tendrá todos los numeros de clientes celulares (20 millones > actualmente) y creciendo. Nuevamente, salvo que este ignorando consideraciones importantes esta no me parece la forma mas inteligente de resolver el problema. Yo he propuesto un "algoritmo" que paso a "refinar" y que me gustaría que comenten si les parece viable: Búsqueda en la DB local b) Si se encuentra, nos fijamos en el TTL c) Si no ha vencido devolvemos el resultado con el operador que tenemos en la DB local d) Si ya ha vencido consultamos la DB remota e) Si no se encuentra en la DB local, consultamos en la DB remota Búsqueda en la DB remota a) Si se encuentra, recuperamos la info del operador y la almacenamos en la DB local registrando fecha y hora de actualización b) Si no se encuentra, aplicamos reglas "antiguas" según patrón o "series" conocidas de operadores y actualizamos la DB local Un TTL razonable parece ser de 84600 segundos (60*60*24) osea de todo un día. > - Numero de queries simultaneos correspondientes a los siguientes > "clientes": > - Modulos LCR de las centrales privada (asterisk,etc...) > - Tarifadores (sw/hw) de las cabinas de INternet, de las PBX de las > empresas, etc. > - Proveedores VoIP. Con este algoritmo, la DB remota/centralizada solo debería tener los números que han cambiado de operador, que en lugar de 20 millones no creo que lleguen ni a 100000 el primer año y tampoco debería recibir más hits que uno, por cliente, por dia lo que podría reducir tranquilamente en uno o dos órdenes de magnitud la cantidad de consultas versus el otro esquema. ¿Les parece que tengo razón o estoy dejando de considerar detalles importantes? > - Velocidad de respuesta de la consulta.. En telefonía quedar esperando "en > blanco" más de pocos segundos no es una opción. Esto es muy cierto, por lo que se me ocurren las siguientes alternativas: a) Descargar en las noches unas "actualizaciones" desde la DB central como un proceso batch y así actualizar la DB local que si debería ser muy rápida b) Hacer la consulta luego de realizar la llamada o el intento de llamada, de esa manera, quizás la primera vez salga la llamada mas cara pero las veces siguientes ya no. No me parece la mejor solución pero se podría manejar como política asociada a un timeout. ¿Que opinan? Antonio _______________________________________________ Lista de correo Linux-plug Temática: Discusión general sobre Linux Peruvian Linux User Group (http://www.linux.org.pe) Participa suscribiéndote y escribiendo a: [email protected] Para darte de alta, de baja o hacer ajustes a tu suscripción visita: http://listas.linux.org.pe/mailman/listinfo/linux-plug IMPORTANTE: Reglas y recomendaciones http://www.linux.org.pe/listas/reglas.php http://www.linux.org.pe/listas/comportamiento.php http://www.linux.org.pe/listas/recomendaciones.php
