Historias
Slashboxes
Comentarios
 
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • por Observer (13195) el Lunes, 18 Abril de 2011, 12:37h (#1274285)
    ( http://www.fsf.org/ | Última bitácora: Domingo, 09 Mayo de 2004, 05:32h )
    El hecho de que hayan reducido el tiempo de respuesta de 800ms a 250ms y reduciendo el uso de CPU a la mitad no ha tenido absolutamente nada que ver, verdad? lo hacen porque asi pueden contratar a mas gente. claro.

    Tambien han migrado de mysql a lucene, gran parte de la reducción del tiempo de busqueda puede ser por eso simplemente.
    Una consulta mal hecha a la bd puede dar como resultado que de 50ms pases a tardar 500ms.
    --
    Si no obtienes respuesta sera porque no la mereces.
    [ Padre ]
    Puntos de inicio:    1  punto
    Modificador por Bonus-Karma   +1  

    Total marcador:   2  
  • Re:antes de crucificar a Rails

    (Puntos:2, Interesante)
    por sammael (16347) el Lunes, 18 Abril de 2011, 13:14h (#1274290)
    ( http://barrapunto.com/ | Última bitácora: Lunes, 24 Febrero de 2014, 10:03h )
    Hombre, es posible, sin ver exactamente que es lo que hacian y como lo han cambiado, no se puede asegurar.

    Estoy dando por hecho que estaban usando las funciones de busqueda full-text de MySQL, no la busqueda SQL normal y corriente. Como tambien he dicho, la busquda full-text en MySQL funciona muy bien y hacen cosas muy interesantes (Stemming, proceso de lenguaje natural...), pero es lenta en cuanto tienes un par de millones de registros. Nosotros tenemos unos 200 millones de registros solo para las busquedas relacionadas (usamos Lucene), no me puedo imaginar el numero de registros con los que trabaja twitter.

    Por otro lado, la busqueda full-text no es tan sensible a un error del que escribio la query como el SQL, donde una consulta mal hecha afecta mucho al resultado. He visto queries de mas de 15 minutos reducidas a un par de segundos simplemente reordenando los campos del where, pero no creo que esa sea la situacion aqui.

    Tambien creo que cuando han migrado a Lucene, han seguido usando los mismos campos para crear los indices (me puedo equivocar aqui, por supuesto, pero lo veo dificil, ellos saben que es lo que necesitan buscar y donde).

    Si solo hubiera sido eso, les hubiera sido mucho mas sencillo usar Solr y dejar el back-end en ruby: Modifican un poco las llamadas para que no vayan a MySQL sino por http y asunto arreglado.

    Por cierto, eso quizas explicaria la reduccion del tiempo de busqueda, pero no el uso de CPU. Hasta donde he visto, el consumo de CPU es mas o menos similar y depende muchisimo de que estes haciendo. Una bajada del 50% del consumo de CPU es una burrada y no hay forma de explicarlo solo con Lucene.
    --

    Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
    [ Padre ]