Existen varias opciones de complemento para crear un motor de búsqueda en su aplicación Ruby on Rails. ¿Cuál de estos es el mejor?¿Cuál es la mejor opción para buscar en Ruby on Rails?
Thinking Sphinx tiene una sintaxis más concisa para definir qué campos y qué modelos están indexados.
Tanto UltraSphinx como Thinking Sphinx (recientemente) tienen una función ultra-cool que tiene en cuenta la proximidad geográfica de los objetos.
UltraSphinx tiene problemas molestos con la forma en que carga los modelos (no carga toda la pila de Rails, por lo que puede obtener errores extraños y difíciles de diagnosticar, que se manejan al agregar declaraciones explícitas require).
Utilizamos Thinking Sphinx en proyectos nuevos y UltraSphinx en proyectos que utilizan contenido geográfico.
he utilizado Pensando Esfinge y parece bastante bueno, pero no he tenido el tiempo para evaluar todas las opciones.
Recomiendo Thinking Sphinx. Es la opción más rápida en mi opinión.
He utilizado Ferret y funcionó bien para mis propósitos, pero no he evaluado las otras opciones.
Solo he usado el combo Ferret/acts_as_ferret (decisión heredada) en un proyecto de cliente. Recomiendo mirar primero las otras opciones de.
aaf es muy frágil y puede hacer que su aplicación Rails se detenga al chirriar si comete un error en la configuración o si, por alguna razón, golpea un error en aaf.
En tal caso, en lugar de tener simplemente la funcionalidad de búsqueda, cualquier acción del controlador que toque un modelo indexado fallará por completo y generará una excepción. ¿Cuál es baaad, hmkay?
Una opción que no he probado es el basado en C++ Xapian
utilizo el acts_as_xapian plugin. He seguido este tutorial:
http://locomotivation.com/2008/07/23/simple-ruby-on-rails-full-text-search-using-xapian
funciona muy bien.
Una opción sólida utilizada por uno de mis amigos es Solr, un motor de búsqueda que utiliza el Lucene basado en Java original.Para usarlo con Rails, hay, por supuesto, un plugin de acts_as, acts_as_solr.
Presentó el combo recientemente en Montreal on Rails y ofrece una descripción completa y completa de how to use acts_as_solr on his blog.
Al parecer, también es compatible con los acentos franceses.
Estamos usando http://hyperestraier.sourceforge.net/, que se heredó. No he investigado otros motores, pero hyperestraier proporciona todos los ganchos necesarios. Sin embargo, configurar el índice de búsqueda es complicado. Probablemente opciones más fáciles disponibles.
Esta pregunta se ha formulado anteriormente here con respuestas más detalladas.
Estoy pasando por este proceso exacto en este momento, así que, aunque no tengo experiencia real, he pasado muchas horas investigando todas las opciones. Esto es lo que he aprendido hasta ahora:
que tienen una hoja de cálculo con mi intento de documentar la ventajas y desventajas de todos ellos. Si alguien está interesado en verlo y/o ayudarme a corregirlo, solo contácteme. Lo publicaré en alguna parte una vez que sepa que es exacto.
Mi recomendación sería probar UltraSphinx o Thinking Sphinx si tiene claves primarias normales. Voy a probar Acts_As_Xapian en función de la buena documentación, el conjunto de características y lo activo que parece ser el proyecto.
Estoy usando acts_as_ferret. Es fácil de configurar y generalmente rápido. La funcionalidad integrada de búsqueda de registros activos es bastante útil: puede aplicar cualquier condición o unirse a otros modelos luego de que su búsqueda encuentre los registros coincidentes.
A diferencia de sphinx, no tiene que volver a indizar TODOS sus registros cuando agrega datos nuevos. Hay hooks after_save y after_update que insertarán tu nuevo registro en el db hurón. Este fue uno de los grandes puntos de venta para mí.
Cuando tiene que indexar sus datos en masa, el hurón es definitivamente más lento que acts_as_sphinx (por un factor de 3). Terminé escribiendo mi propio método para volver a indexar modelos que funcionan tan rápido como sphinx: básicamente precarga todos los datos de la base de datos en lugar de ir registrando por registro para crear el nuevo índice.
La documentación del hurón es buena para los aspectos básicos, pero es un poco escasa una vez que entra en búsquedas más complejas, ordena y utiliza un servidor dRb para alojar un índice remoto. Dicho esto, se siente un producto mucho más maduro que actúa como una esfinge, aunque tengo una experiencia limitada con la esfinge.
Depende de qué base de datos esté utilizando. Yo recomendaría usar Solr, ya que ofrece muchas opciones agradables para la búsqueda difusa y tiene un gran analizador de consultas. El inconveniente es que debes ejecutar un proceso separado para ello.También he usado Ferret, pero me pareció menos estable en cuanto al acceso de múltiples subprocesos al índice. No he probado Sphinx porque solo funciona con MySQL y Postgres.
Estoy usando una opción diferente que funcionó increíblemente bien. Estoy usando jruby y hablando con lucene directamente.
He usado acts_as_solr en el pasado y encontré algunos problemas. principalmente hace una llamada síncrona para cada guardado AR. Esto no es tan malo, pero en mi situación un ahorro a veces causaba muchas llamadas sincrónicas a Solr y ocasionalmente tomaba más tiempo del que mestizo permitía y obtenía una excepción de tiempo de espera mestizo (o algo así)
Thinking Sphinx es una mejor alternativa que Ultrasphinx, que parece abandonada, pero, en general, Xapian tiene un motor más potente que Sphinx y es más fácil de implementar en tiempo real.
Recomiendo acts_as_ferret. Pero aunque la parte difícil es ponerlo en funcionamiento con éxito en su servidor, una vez hecho esto apenas tendrá ningún problema ya que el servidor de hurón se ejecutará como un proceso de fondo separado para actualizar su índice cada vez que haya una nueva actualización. Además, funciona muy bien en mestizo con apache para nosotros.
He estado buscando la solución perfecta también. Al principio fui con Thinking Sphinx, que funcionó bien. Pero como intento alojar mi aplicación web en Heroku, la única opción es usar Solr. El mayor inconveniente, sin embargo, es que el desarrollo de la gema principal acts_as_solr parece haberse detenido después de mayo de 2008. Así que eso es demasiado viejo para mi gusto. Acabo de encontrar Sunspot como una alternativa avanzada y con actualizaciones recientes, así que es una que voy a considerar.
Otra opción que ofrece Heroku es ir a un servidor de índice alojado basado en Solr, llamado Websolr. La gema requerida websolr-acts_as_solr también está afortunadamente muy actualizada.
Si está utilizando un servicio de alojamiento compartido como yo (Bluehost), sus opciones pueden estar limitadas a las que ofrece el proveedor. En mi caso, no pude encontrar una manera buena y confiable de iniciar y mantener en funcionamiento un servidor por separado, como Lucene o Solr.
Por lo tanto, fui con Xapian y me ha estado funcionando bien. Hay 2 complementos para rails que he investigado: acts_as_xapian y xapian_fu. El primero te pondrá en marcha rápidamente, pero ya no parece mantenerse. Acabo de empezar a trabajar con xapian_fu.
En caso de que alguien todavía esté interesado, lo último que se puede usar ahora es elasticsearch. Hay gemas disponibles para él como neumático o elasticsearch-rails. También está basado en Lucene como Solr, basado en Java. Solr está realmente integrado con este proyecto ahora ...
Curioso, si ambos tienen soporte para contenido geográfico, ¿por qué "usar Thinking Sphinx en proyectos nuevos y UltraSphinx en proyectos que usan contenido geo"? –