ventajas tutorial sintaxis rails programas ejemplos desventajas comandos caracteristicas basicos ruby-on-rails ruby search

tutorial - ¿Cuál es la mejor opción para buscar en Ruby on Rails?



sintaxis de ruby on rails (19)

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.

Hay varias opciones de complementos para construir un motor de búsqueda en su aplicación Ruby on Rails. ¿Cuál de estos es el mejor?

En caso de que alguien aún esté interesado, lo último que se puede usar ahora es elasticsearch . Hay gemas disponibles para ello como llantas o carriles elásticos . También está basado en Lucene como Solr, basado en Java. Solr está realmente integrado con este proyecto ahora ...

Esta pregunta se ha formulado previamente aquí con respuestas más detalladas.

Estamos usando http://hyperestraier.sourceforge.net/ , que fue heredado. 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.

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:

  • * Sphinx: buena reputación de velocidad y funcionalidad, pero Sphinx necesita claves enteras y mi modelo usa GUID; ThinkingSphinx anunció recientemente el soporte para GeoSpatial
  • Acts_As_Solr: recomendado por un amigo con un sitio de gran volumen; los creadores originales han dejado de trabajar en él y la documentación es difícil de encontrar; requiere un servlet de Java
  • Acts_As_Ferret: parece fácil de usar, pero hay muchos detractores que dicen que es inestable
  • Otros dos con información limitada son Acts_As_Indexed y Acts_As_Searchable

Tengo una hoja de cálculo con mi intento de documentar las 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 tienes 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 indexar 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 tienes que indexar en masa tus datos, 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 funciona 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 conceptos básicos, pero es un poco escasa una vez que ingresas a búsquedas más complejas, ordena y usa 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.

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 save a veces causaba muchas llamadas sincrónicas a solr y ocasionalmente tomaba más tiempo de lo que mongrel permitía y obtenía una excepción de mestrel timeout (o algo así)

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 principal joya de 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 Heroku ofrece es ir a un servidor de índices alojado basado en Solr, llamado Websolr . La gema requerida websolr-acts_as_solr también está afortunadamente muy actualizada.

He usado Ferret y funcionó bien para mis propósitos, pero no he evaluado las otras opciones.

He usado Thinking Sphinx y parece bastante bueno, pero no he tenido tiempo de evaluar todas las opciones.

Recomiendo Thinking Sphinx. Es la opción más rápida en mi opinión.

Recomiendo actos_ como_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.

Si está utilizando un servicio de alojamiento compartido como yo (Bluehost), sus opciones pueden estar limitadas a lo 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.

Solo he usado el combo Ferret / acts_as_ferret (decisión heredada) en un proyecto de cliente. Recomiendo mirar las otras opciones primero.

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, acierta un error en aaf.

En tal caso, en lugar de simplemente hacer que la funcionalidad de búsqueda falle, cualquier acción del controlador que toque un modelo indexado fallará por completo y generará una excepción. ¿Cuál es baaad, hmkay?

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.

Thinking Sphinx tiene una sintaxis más concisa para definir qué campos y qué modelos están indexados.

Tanto UltraSphinx como Thinking Sphinx (recientemente) cuentan con funciones ultramodernas que tienen 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 de require ).

Usamos Thinking Sphinx en nuevos proyectos y UltraSphinx en proyectos que usan contenido geográfico.

Una opción que no he probado es el Xapian basado en C ++

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 visión completa y completa de cómo usar acts_as_solr en su blog .

Al parecer, también es compatible con los acentos franceses.