Mantener elasticsearch y la base de datos en sincronía

Question

Estoy tratando de encontrar una manera de mantener mi db mysql y elasticsearch db en sincronía. Configuré un río jdbc con el complemento jprante/elasticsearch-river-jdbc para elasticsearch. Cuando yo haga la solicitud a continuación:

curl -XPUT 'localhost:9200/_river/my_jdbc_river/_meta' -d '{ 
"type" : "jdbc", 
"jdbc" : { 
    "driver" : "com.mysql.jdbc.Driver", 
    "url" : "jdbc:mysql://localhost:3306/MY-DATABASE", 
    "user" : "root", 
    "password" : "password", 
    "sql" : "select * from users", 
    "poll" : "1m" 
}, 
"index" : { 
    "index" : "test_index", 
    "type" : "user" 
} 
}' 

el río comienza indexación de datos, pero para algunos registros consigo org.elasticsearch.index.mapper.MapperParsingException. Bueno, hay una discusión relacionada con este tema here, pero quiero saber una forma de evitar este problema.

¿Es posible corregir esto permanentemente creando un explicit mapping para todos los 'campos' del 'tipo' que estoy tratando de indexar o hay una mejor manera de resolver este problema?

Otra pregunta que tengo es, cuando el jdbc-river sondea nuevamente la base de datos, parece volver a indexar todo el conjunto de datos (dado en la consulta sql) nuevamente en ES. No estoy seguro, pero ¿se hace esto porque elasticsearch quiere agregar datos nuevos y actualizar los cambios en los datos existentes? ¿Es posible indexar solo los datos nuevos, si los datos de la tabla son estáticos?

Answer 1

¿Miraste la asignación predeterminada? http://www.elasticsearch.org/guide/reference/mapping/dynamic-mapping.html

Creo que puede ayudarlo aquí.

Si tiene un campo de fecha de inserción en su tabla de datos, puede usarlo para filtrar lo que tiene que indexar. Ver https://github.com/jprante/elasticsearch-river-jdbc#time-based-selecting

HTH

David

Answer 2

elasticsearch se ha reducido el concepto de sincronización río en absoluto. No es una ruta recomendada, porque generalmente no tiene sentido mantener la misma estructura de tabla SQL normalizada en la tienda de documentos como Elastic Search.

Supongamos que tiene el Producto como una entidad con algunos atributos y Revisiones en la entidad del Producto como una tabla secundaria parental, ya que los Comentarios pueden ser múltiples en la misma tabla.

Products(Id, name, status,... etc) 
Product_reviewes(product_id, review_id) 
Reviews(id, note, rating,... etc) 

En almacén de documentos es posible que desee crear un único índice con nombre dicen de productos que incluye Product{attribute1, attribute1,... Product reviews[review1, review2,...]}

Aquí es el enfoque de sincronización en dicha configuración.

Supuesto:

1. base de datos SQL (verdadera fuente de registro)
   
2. elástico de búsqueda o cualquier otra tienda NoSQL Documento
   

Solución:

1. Tan pronto como Las actualizaciones/actualizaciones ocurren en eventos/eventos de publicación en JMS/AMQP/Cola de base de datos/Sistema de archivos em Queue/Amazon SQS etc. producto completo o ID de objeto primario (recomendaría solo ID)
2. El consumidor de cola debe llamar al servicio web para obtener el objeto completo si solo se inserta el ID principal en cola o simplemente tomar el objeto que auto y enviar los cambios respectivos a la búsqueda elástica/base de datos NoSQL.