diseño de base de datos muy grande para buscar texto

Question

Necesitamos diseñar un sistema que permita a los usuarios buscar por palabras clave diferentes en textos grandes y también, en el futuro, crear informes básicos sobre la frecuencia de esa palabra clave en todos los artículos sobre un período.

Tendremos:

• alrededor de 200.000 artículos añadidos cada día
• cada texto artículo está sobre 2 KB
• artículos se almacenan durante 6 meses

Para hacer eso, se nos ocurrió con la siguiente solución:

• crear un repositorio SOLR para almacenar los artículos
• utilizar una base de datos MySQL para almacenar el artículo de información adicional

el sistema buscará SOLR por palabra clave y luego va a buscar los resultados en MySQL para recuperar información adicional.

Entonces, ¿sería este un buen enfoque?

Si la mayoría de las búsquedas serán solo sobre los artículos agregados en el último mes, ¿sería una buena idea mantener dos bases de datos, una con los artículos agregados en el último mes para la mayoría de las búsquedas y otra con todos los artículos?

Si tiene algún consejo/trucos sobre cómo mejorar esto, sería muy apreciado.

¡Gracias de antemano!

Answer 1

Creo que su solución es bastante buena. Evaluaría poner una instancia de Memcache antes de SOLR si desea obtener respuestas más rápidas en consultas comunes.

No estoy seguro acerca de las dos bases de datos, tendría que ver cuál es el beneficio de rendimiento en comparación con la carga de mover registros del primero al segundo DB a medida que envejecen. Dudo que haya un gran beneficio, pero eso es solo una corazonada, no tome mis palabras y haga experimentos.

Además, ¿está considerando el hecho de que puede necesitar alguna solución escalable horizontalmente si su conjunto de datos es muy grande?

Answer 2

En lugar de tener sus datos almacenados en MySQL y Solr, es posible que desee probar MySQL 5.6 ahora. Debería poder usar un motor de almacenamiento para todos sus requisitos.

MySQL de hecho ha sido compatible con la búsqueda de texto completo durante años, pero solo en el obsoleto motor de tabla MyISAM. MySQL 5.6 admite esa característica para las tablas InnoDB, lo que la hace mucho más relevante para frameworks como Ruby on Rails, por ejemplo.

La documentación para la búsqueda de texto completo de MySQL está en:

http://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html

La sintaxis de la consulta, que puede ser de particular interés para aquellos comparándolo con características de Solr, se encuentra en:

http://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html

Answer 3

De hecho, no tengo ninguna idea sobre el uso de Solr Search Platform, pero en mi opinión, puede usar Java Content Repository JCR, esto le permitirá obtener los datos en su base de datos i n un formato de árbol. Por lo tanto, la búsqueda será exponencialmente rápida de lo habitual. Usted debe echar un vistazo a este enlace para obtener más información al respecto

http://onjava.com/onjava/2006/10/04/what-is-java-content-repository.html

Espero que ayude

Answer 4

que desea para cada una de las columnas (columna 1, columna 2, Columna3) para tener una mirada índice y no un escaneo de tabla en una tabla tan grande.

El problema es que una consulta usará un índice.

Si realiza un índice (Columna1, Columna2, Columna3) seguirá realizando un examen de tabla para cada búsqueda, porque cuando utiliza el índice para, por ejemplo, Columna1, también debe buscar la Palabra clave de búsqueda en Columna2 y Columna3. al mismo tiempo y estos no están ordenados. - el índice solo se pide para Column1; Column2 y Column2 están en orden aleatorio

Así que tiene 2 soluciones: o bien cambia el diseño de la tabla para que no tenga Column1, Column2 y Column3, sino solo 1 columna con la palabra clave de búsqueda: cname, y si necesita para saber si era Column1,2 o 3, luego agregue otra columna con un entero que diga 1,2 o 3. Ponga un índice en esta columna cname y sus búsquedas irán rápido. Pero dependiendo de las otras columnas que tenga esto puede significar que duplica algunos datos.

Esto es lo que haría. Si eso no funciona lo suficiente, incluso divida la tabla para que solo tenga una tabla (id, cname) y con la ID puede buscar otras columnas que necesite de otra tabla. Si la tabla se convierte en demasiado tiempo incluso se puede dividirlo, hacer una cnameAM que contiene palabras que comienzan con A a M y cnameNZ que contiene el resto ..

Si no puede cambiar el diseño de la mesa: en lugar de utilizar 1 consulta , use múltiples consultas

Ponga un índice en cada una de las columnas y use 3 consultas. Así que crea un índice en (id, columna 1), crea un índice en (id, columna 2) y (id, Columna3) y hacer:

SELECT * FROM 'SearchTable' WHERE Column1='$SearchKeyword' 
SELECT * FROM 'SearchTable' WHERE Column2='$SearchKeyword' 
SELECT * FROM 'SearchTable' WHERE Column3='$SearchKeyword' 

estos 3 selecciona irán muy rápido, ya que cada uno hacer una busque en su índice específico y luego únase a los 3 conjuntos de resultados para un procesamiento posterior o busque más columnas usando la identificación que recuperó