2009-02-02 12 views
22

Hemos grabado miles de páginas de artículos de periódicos. El periódico, el número, la fecha, el número de página y el texto OCRed de cada página se han incluido en una base de datos mySQL.Motor de búsqueda similar a Google en PHP/mySQL

Ahora queremos construir un motor de búsqueda similar a Google en PHP para encontrar las páginas dadas una consulta. Tiene que ser rápido y no tomar más de un segundo para cualquier búsqueda.

¿Cómo deberíamos hacerlo?

+3

Lo que hace que Google sea diferente de los motores de búsqueda de texto plano es que estudia las relaciones entre las páginas. ¿Cómo relacionarías tus páginas entre sí? Enlaces? Palabras clave/frases? Si no tienes ningún tipo de relación, estarás mejor con una búsqueda de texto. –

+1

Nuestra base de datos de 50,000 artículos toma mySQL aproximadamente 20 segundos para hacer una búsqueda de texto plano. Nuestras páginas de periódicos OCRed son un conjunto de datos mucho más grande. Necesitamos métodos más rápidos de indexación y recuperación similares a Google para buscar en nuestros periódicos en menos de un segundo. – lkessler

+0

los motores de búsqueda no usan bases de datos SQL porque ralentizan la búsqueda. Puedes usar Lucene o codificar tu propio motor de búsqueda. php no es un lenguaje adecuado para desarrollar un motor de búsqueda. – alienCoder

Respuesta

14

También puedes probar SphinxSearch. Craigslist usa sphinx y puede conectarse tanto a mysql como a postgresql.

+0

hola, he creado un montón de páginas web, quiero buscar cualquier palabra dentro de mis páginas ... entonces, ¿todas son útiles para mí? gracias – pcs

+0

No sabía que Craigslist usa Sphinx –

10

Hay algunos motores de búsqueda interesantes para que eche un vistazo a. No sé a qué te refieres con "Google me gusta", así que voy a ignorar esa parte.

  • Eche un vistazo al motor Lucene. El original es de alto rendimiento, pero escrito en Java. Hay un port of Lucene to PHP (ya mencionado en otro lugar) pero es demasiado lento.
  • Eche un vistazo al Xapian Project. Es rápido. Está escrito en C++, por lo que lo más probable es que tenga que compilarlo para su (s) servidor (es) de destino, pero tiene enlaces PHP.
2

Su escenario sugiere, que le gustaría rodar el suyo; buenos puntos de partida para un motor de búsqueda pueden citarse:

Si desea utilizar una solución fuera de la plataforma:

+0

Wow. ¿Por qué escribir el tuyo? Realmente no veo qué pasa con la situación del OP que hace que valga la pena volver a implementar lo que recientemente se ha convertido en una característica de los productos básicos. –

+2

El OP dijo "Ahora queremos construir" – Artelius

1

Es posible que desee comprobar Sphider. En mi experiencia, es bastante rápido y realiza la indexación de forma automática. También es de código abierto para que pueda tomar el código y modificarlo para sus necesidades.

2

¿Por qué no prueba algo como Google Search Appliance o Google Enterprise? Tendrá un costo asociado, pero luego le evitará volver a inventar la rueda y le dará una búsqueda "google like".

+0

Preferiríamos quedarnos con PHP y mySQL porque la base de datos tiene propósitos cruzados y debe integrarse con el resto de nuestro sitio web. – lkessler

10

Si la búsqueda de texto completo de MySQL demora 20 segundos por consulta, o la configura mal o se ejecuta en un hardware de poca potencia - algunos sitios grandes de están utilizando con éxito la búsqueda simple de MyISAM.

Mi voto va por Solr, sin embargo. Se basa en Lucene, por lo que obtienes toda la riqueza y el rendimiento del mejor producto de su clase, pero con una API RESTful, por lo que es muy fácil from PHP. Incluso hay un dW article.

+1

Estoy de acuerdo. Ve con SOLR todo el camino. Integrado PHP y SOLR muchas veces y vale la pena el tiempo. –

+0

Sí 20 segundos para la búsqueda de texto completo de MySQL indica que algo está roto. El tiempo de renderización de la página SQL + debe ser de aproximadamente 0,01 a 0,05 segundos en total para el texto completo en> 250,000 filas incluso en un sistema muy bajo (solo núcleo, 512 MB de RAM), incluso haciendo múltiples declaraciones LIKE para cada palabra clave en un DB con aproximadamente 250,000 no deberían tomar más de un segundo. Suena muy probablemente que las columnas simplemente no están indexadas todas. Para <250,00 filas que recorren todos los resultados coincidentes en PHP para clasificarlos de forma inteligente aún debe ser inferior al segundo. –

+0

hola, he creado un montón de páginas web, quiero buscar cualquier palabra dentro de mis páginas ... ¿así que, todas son respuestas útiles para mí? Gracias – pcs

4

Puede poner todos los archivos en Google Docs, luego raspar los resultados en su propio sitio web.

Mi preocupación es que la precisión de OCR sigue siendo un problema, por lo que una consideración para un requisito de búsqueda es la capacidad de realizar búsquedas "difusas". Significado difuso cuando el OCR reconoce incorrectamente la palabra "sombrero" para "caliente", el motor de búsqueda será lo suficientemente inteligente como para devolver resultados que son similares pero no exactos. En Oracle, hay una función llamada UTL_MATCH que compara la similitud entre dos cadenas: http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/u_match.htm#ARPLS352

Una función como esta sería útil.

0

SQLite tiene bastante bueno texto completo capacidad de búsqueda (mirar hacia arriba FTS sqlite 3/4 - su sorprendentemente bueno)

si quieres sencilla un PHP bricolaje enfoque de indexación utilizando de una gran cantidad de archivos pequeños divididos por un hash de los términos indexados puede funcionar muy bien y la búsqueda puede ser muy rápida incluso en php si te ocupas de diseñarlo. (la idea es hacer una búsqueda en un término solo necesita buscar un archivo muy pequeño que contenga términos que coincidan con el hash y registrar identificaciones; puede usar segmentos bitarray para representar identificadores de registros si desea guardar espacio en HD) .. pero hacer la indexación de cada palabra para el texto completo sería lento en php ... esa parte realmente debería hacerse en c

para búsquedas "borrosas", tal vez consulte el uso de hashes de metaphone.

de herramientas texto completo pre-construidos echa un vistazo a los siguientes: FTS sqlite (3/4! SQLite tiene muy buena capacidad de búsqueda de texto completo), Sphinx, kinoSearch (kinoSearch es un poco como Lucene, pero el back-end es c con una agradable envoltura de perl fácil - también hay cLucene pero creo que todavía es pre-alpha)

Java Lucene (o cualquier cosa basada en Java) probablemente necesite una gran cantidad de ram para separarla para ejecutar una JVM - tan probablemente no tan bueno si tiene un presupuesto

Cuestiones relacionadas