Desde hace unos minutos está en funcionamiento «público» el nuevo buscador del Menéame basado en Zend Lucene. Así se soluciona –o eso esperamos– una de las cosas más criticadas por los usuarios habituales. El buscador anterior funcionaba con las búsquedas full text del MySQL y tenía sus «cosillas». ¿Es ahora un poco menos saco? 🙂
Escribí una pequeña ayuda en el wiki. Ya iremos solucionando todos los problemillas, el Zend Lucene también tiene sus glitches (además de numerosos, asustan al usuario desprevenido).
menéame 
Pingback: meneame.net
Hay que reconocer que el ofuscador anterior era un saco, aunque bien usado cumplía decentemente 🙂
La pequeña ayuda en el wiki está muy bien, aunque me pregunto quienes seran esos ricardo y benjamí que salen tanto xD
Bravo! 🙂
A ver que recepción tiene entre los demás usuarios.
Vaya, como mola. Y lo bien que funciona. Aunque verás que en cuanto crezca mucho va a petar, pero todavía –pienso– le queda y es que con tal de que sea precisco vale. Y si no, siempre nos quedará
ParisSphinx.Salud…
Yo soy partidario de usar Sphinx (http://sphinxsearch.com) cuando se usa una base de datos MySQL ( o Posgresql) ya que lucene abarca un ámbito mucho más amplio en generación de buscadores pero se queda un poco atrás en MySQL.
Ya iremos solucionando todos los problemillas, el Zend Lucene también tiene sus glitches (además de numerosos, asustan al usuario desprevenido).
¿Como cuáles? Hace siglos que uso Lucene en Java y algún que otro port suyo a otros lenguajes (PyLucene y Ferret, por ejemplo) y aún no le he visto ningún fallo grave, es sólo cuestión de tener claras sus limitaciones (y saber cómo atajarlas).
Jose Pelo,
lo que no me ha gustado del Sphinx (estaba a punto de usarlo) es que aunque tienes los «deltas» debes regenerar la bbdd diariamente. Para el menéame eso es mucho. De todas formas lo probaré, proque me he quemado un poco con el Zend Lucene.
Esteve.
quizás la mayoría de los problemas son del Zend Lucene y no del original. Pero el hecho que no sea cliente-servidor ya tiene una desventaja enorme: carga todos los resultados parciales en memoria y chupa un mogollón para cada script (también CPU),
También tiene otros errores importantes:
– Siempre hace un chmod del fichero de lock, por lo que no puedes ejecutar desde otro usuario aunque todos los ficheros sean de lectura/escritura. Es un muy mal rollo, para ejecutar como www-data en la Debian tenía que hacer primero un «sudo -s» y luego como root hacer «sudo www-data php5 script.php»
– El consumo de memoria es muy improtante, tienes que definir límites a la cantidad de resultados, pero resulta que lo hace antes del scoring o de busar por los otros términos, por lo que las búsqueda en estos caso es horrible.
– El consumo de memoria no sólo depende del número de resultados máximo que le pongas, si pones frases muy larga (o entre «») el consumo se dispara una barbaridad.
– Se hace un lío si no tienes locales con UTF-8 definidos, te obliga a definir uno para usar aunque tengas todo en UTF-8.
– No funcionan los comodines ni búsqueda por rangos en la versión 1.0
– La versión del SVN (la que será 1.1) peta de mala manera por problemas de concurrencia con el fichero de lock.
Y varios más que me volvieron loco…
quizás la mayoría de los problemas son del Zend Lucene y no del original. Pero el hecho que no sea cliente-servidor ya tiene una desventaja enorme: carga todos los resultados parciales en memoria y chupa un mogollón para cada script (también CPU),
Tiene su ventaja, porque te permite crearte tu propio servidor si quieres, por si no te convence incrustar la librería en tu programa. Una ventaja del Lucene original es que puedes meter en cualquier aplicación y voilà, ya tienes full-text search. De todas maneras, en el mundo Java tienes Solr y en Python, por ejemplo NXLucene, que son servidores creados a partir de Lucene y PyLucene respectivamente.
– El consumo de memoria es muy improtante, tienes que definir límites a la cantidad de resultados, pero resulta que lo hace antes del scoring o de busar por los otros términos, por lo que las búsqueda en estos caso es horrible.
– El consumo de memoria no sólo depende del número de resultados máximo que le pongas, si pones frases muy larga (o entre “”) el consumo se dispara una barbaridad.
¿Qué tipo de directorio tienes puesto? ¿FS o RAM?
– No funcionan los comodines ni búsqueda por rangos en la versión 1.0
Eso es claramente un fallo de Zend.
En general, parece que el framework de Zend Lucene está un poco en pañales, los fallos que has comentado no están ni en Lucene, CLucene, Ferret o PyLucene (que son lo que he tocado).
Podrías usar la versión de Java o la de Python, la gente de la Wikipedia usa la versión Java y el Mediawiki está hecho en PHP. Si no te quieres complicar la vida, puedes usar los servidores de búsqueda que te he comentado (NXLucene y Solr), conectándolos con Menéame a través del webservice que exponen.
El artículo en el wiki está muy bien y el buscador me gusta, el de antes si sabias usarlo cumplía pero al usuario de a pie si no le pones las cosas en los morros no las ve.
Los comandos de busqueda los usaremos los cuatro de siempre, el resto pasarán de ellos porque no los conozca.
Quizá sea buena idea crear un formulario para un buscador avanzado, donde marcando casillas el usuario puede acotar la busqueda igual que con los comandos.
Yo dejaría la interfaz como está y al buscar justo antes de los resultados pondría
algo como
«¿No has encontrado lo que buscabas? Prueba a usar nuestro buscador avanzado»
y un enlace que te lleve a este buscador
Me ha gustado el funcionamiento del nuevo buscador aunado a la documentación, parece que evitará ese conflicto de duplicadas porque los resultados ofrecidos no mostraban la noticia que se iba a menear.
la verdad que yo también lo he usado con mucho exito, pero creo que tenerlo en la misma maquina que el servidor de bbdd es demasiado. Para que vaya bien es recomendable que tenga bastante memoria libre donde cachear los vectores de cada palabra de forma que no tenga que acceder practicamente a disco. Ademas, si usas el RAMdirectory, te maneja el indice en memoria con lo cual es mucho mas rapido, pero necesitas dedicarle al menos el doble del tamaño del indice en la memoria.
Yo me inclinaria por utilizar solr. No es mas que una capa de abstraccion y webservices montada encima de lucene. Basta con definir el esquema de tu indice y puedes ponerte a añadir documentos y buscarlos. Ademas tienes una aplicación web para ver el estado del indice, y una serie de utilidades extra que no tiene lucene. (por ejemplo la ordenacion de floats, que es util si quieres filtrar por latitud y longitud.
Tienes razón en eso. La actualización automática de los índices es el tema que más nos tiene pendientes del proyecto sphinxsearch a aquellos que lo usamos. Si bien es verdad que en muchos casos es solucionado con sistemas de main+delta en otros hace complicada su actualización.
Aun así en muchos proyectos han apostado por sphinx a pesar de ese problema, por su capacidad de indizar y buscar contenidos en bases de datos realmente grandes (boardreader, mininova, thepiratebay) a una velocidad muy alta.
Un saludo
Pingback: Estimados Larry y Sergei « Ricardo Galli, de software libre
http://meneame.net/search/c%26
Repito lo mismo que en los comentarios de http://meneame.net/story/sonidos-del-espacio-1 . El nuevo buscador deja mucho que desear. No voy a entrar en consideraciones técnicas. Lo digo como usuario que pronto cumplirá un año en esto de Menéame. Espero que el funcionamiento del buscador mejore o que se vuelva al antiguo. A la experiencia me remito. El actual no me hace ninguna gracia ni me merece confianza. Repito a los comentarios de la noticia me remito. Saludos!!
Estoy de acuerdo con ashacz en que estaría muy bien tener un formulario con el que acotar las búsquedas como con los prefijos. Aunque yo creo que lo mostraría desde el primer momento y no como un «buscador avanzado».
O sea, una vez realizada una búsqueda, mostrar algo asín: http://xs322.xs.to/xs322/07505/mnm-buscador.png
Y si algo así no es buena idea, como mínimo mostrar los prefijos o enlazar al wiki en los resultados de búsqueda de menéame.