...esteee perdon, pero esto lo estan conversando en terminos "academicos", no?
El 4 de enero de 2010 15:05, Antonio Ognio <[email protected]> escribió: > 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 > -- http://picasaweb.google.com/iap2001/nicolas http://www.openoffice.org.pe http://iap2001.blogspot.com http://iap2001.wordpress.com No imprimas si no es necesario. Protejamos el Medio Ambiente
_______________________________________________ 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
