Pregunta

Estoy construyendo un índice de los datos, lo que conllevará el almacenamiento de una gran cantidad de trillizos en forma (document, term, weight). Me va a almacenar hasta unos pocos millones de esas filas. Actualmente estoy haciendo esto en MySQL como una simple tabla. Estoy almacenando los identificadores de documentos y plazo como valores de cadena que las claves externas a otras tablas. Estoy re-escribir el software y buscando mejores formas de almacenar los datos.

En cuanto a la forma en que funciona HBase, esto parece poner el esquema bastante bien. En lugar de almacenar una gran cantidad de trillizos, podría asignar a document {term => weight}.

Estoy haciendo esto en un solo nodo , por lo que no se preocupan por nodos distribuidos etc. ¿Debo seguir con MySQL, ya que funciona, o sería aconsejable tratar HBase? Veo que Lucene lo utiliza para la indización de texto completo (que es análogo a lo que estoy haciendo). Mi pregunta es realmente cómo sería un solo nodo HBase Comparar con un solo nodo MySQL? Vengo de Scala, por lo que puede ser que una API de Java directa tener una ventaja sobre JDBC y MySQL analizar cada consulta, etc?

Mi preocupación principal es la velocidad de inserción, ya que ese ha sido el cuello de botella anteriormente. Después del procesamiento, probablemente voy a terminar poniendo los datos de nuevo en MySQL para vivir-consulta porque tengo que hacer algunos cálculos que son mejor realizadas dentro de MySQL.

Voy a tratar de prototipos tanto, pero estoy seguro de la comunidad me puede dar alguna información valiosa sobre esto.

¿Fue útil?

Solución

Utilice la herramienta adecuada para el trabajo.

Hay una gran cantidad de sistemas de bases de anti-RDBMS o (Disponible Básicamente, estado blando, el tiempo constante), en oposición a ACID (atomicidad, coherencia, aislamiento, durabilidad) para elegir aquí y aquí .

He usado RDBMS tradicional y aunque se puede almacenar CLOBs / BLOB, lo hacen No se han incorporado en los índices personalizados específicamente para buscar estos objetos.

¿Quieres hacer la mayoría del trabajo (cálculo de la frecuencia ponderada para cada tupla encontrado) al insertar un documento.

También puede ser que desee hacer algún trabajo anotando la utilidad de cada uno (documentId, palabra de búsqueda) después de cada par de búsqueda.

De esa manera usted puede dar mejores y mejores búsquedas cada vez.

También desea almacenar una puntuación o el peso para cada búsqueda y ponderada calificaciones de similitud con otras búsquedas.

Es probable que algunas búsquedas son más comunes que otros y que los usuarios no están fraseo su consulta de búsqueda correctamente a pesar de que significan hacer una búsqueda común.

Inserción de un documento también debe causar algún cambio en el peso de búsqueda índices.

Cuanto más lo pienso, más compleja será la solución se vuelve. Usted tiene que comenzar con un buen diseño en primer lugar. Cuantos más factores de su diseño anticipa, mejor será el resultado.

Otros consejos

MapReduce parece una gran manera de generar las tuplas. Si usted puede conseguir un trabajo Scala en un archivo JAR (no estoy seguro ya que no he usado antes y Scala soy un n00b JVM), que sería una simple cuestión de enviar a lo largo y escribir un poco de un envoltorio para ejecutarlo en el mapa reducir clúster.

Como para almacenar las tuplas después de que haya terminado, es posible que también desee considerar una base de datos de documentos como mongodb si sólo está almacenando tuplas.

En general, parece que estás haciendo algo más estadística con los textos ... ¿ha considerado el simple uso de Lucene Solr o para hacer lo que está haciendo en lugar de escribir su propio?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top