logstach: jdbc_page_size ne jette pas toutes mes données à la recherche élastique

Question

Je voudrais exporter la table de tom_test2 postgresql à la recherche élastique. Le tableau a 176805 lignes:

=> select count(*) from tom_test2; 
count 
-------- 
176805 
(1 row) 

Le fichier logstach conf suivant importation correctement mes données à la recherche élastique:

input { 
    jdbc { 
     # Postgres jdbc connection string to our database, mydb 
     jdbc_connection_string => "xxx" 
     # The user we wish to execute our statement as 
     jdbc_user => "xxx" 
     jdbc_password => "xxx" 
     # The path to our downloaded jdbc driver 
     jdbc_driver_library => "xxx" 
     # The name of the driver class for Postgresql 
     jdbc_driver_class => "org.postgresql.Driver" 
     # our query 
     statement => "select * from tom_test2" 
    } 
} 


output { 
    elasticsearch { 
     hosts => ["xxx"] 
     index => "tom" 
     document_type => "tom_test" 
    } 
} 

A la recherche élastique:

GET tom/tom_test/_search 

    "hits": { 
    "total": 176805, 
    "max_score": 1, 
} 

je supprime mon index en recherche élastique:

delete tom 

Et maintenant je voudrais faire la même opération en utilisant jdbc_page_size dans le cas où mes données devient plus grand, mon fichier logstach conf est maintenant:

input { 
    jdbc { 
     # Postgres jdbc connection string to our database, mydb 
     jdbc_connection_string => "xxx" 
     # The user we wish to execute our statement as 
     jdbc_user => "xxx" 
     jdbc_password => "xxx" 
     # The path to our downloaded jdbc driver 
     jdbc_driver_library => "xxx" 
     # The name of the driver class for Postgresql 
     jdbc_driver_class => "org.postgresql.Driver" 
     # our query 
     statement => "select * from tom_test2" 

     jdbc_page_size => 1000 
     jdbc_paging_enabled => true 
    } 
} 


output { 
    elasticsearch { 
     hosts => ["xxx"] 
     index => "tom" 
     document_type => "tom_test" 
    } 
} 

Mon compte est maintenant mal:

GET tom/tom_test/_search 

    "hits": { 
    "total": 106174, 
    "max_score": 1, 
} 

comme 176805 -106174 = 70631 lignes sont manquantes

Answer 1

La raison pour laquelle vous faites face à ceci - vous avez des problèmes de commande: votre requête ne contrôle pas l'ordre dans lequel les données sont reçues, et en général postgresql ne devrait pas garantir cela dans la pagination conséquente non ordonnée appelle vous don Ne récupère pas les mêmes données: cela produit une situation où certaines données ne seront pas récupérées du tout, et certaines données seront récupérées plusieurs fois :(même si les données ne sont pas modifiées pendant ces appels, l'assistant de fond peut changer l'ordre de les données dans le fichier physique, et ainsi reproduire la situation décrite.

Soit ajouter de l'ordre à votre déclaration SELECT * FROM tom_test2 ORDER BY id et la page de vos données. Mais attention: dans ce cas, votre téléchargement sur elasticsearch n'assurera pas la réplique exacte de la table à ce moment. La cause de cela sera, que pendant le traitement de logstash de demande de pagination conséquente introduit la mise à jour des données dans la page suivante, c'est-à-dire que vous téléchargez en ce moment page 1 à 10000 et mise à jour aux données sur page 10001 et 20000 ... vous avez donc un problème de cohérence de vos données. Si vous voulez récupérer toutes les données et utiliser généreusement la mémoire sur logstash ..., vous devez contrôler le paramètre jdbc_fetch_size, c'est-à-dire que vous effectuez le même SELECT * FROM tom_test2. Avec cette approche, vous créez un seul résultat de requête, mais vous le «pompez» en morceaux, et la modification des données pendant votre «pompage» ne vous causera pas: vous récupérerez l'état au moment du démarrage de la requête.

Answer 2

Parce que la commande n'est pas garantie entre les requêtes jdbc_page_size comme AVERTISSEMENT dans le documentation of jdbc_paging_enabled.

Je recommande d'utiliser jdbc_fetch_size au lieu d'utiliser jdbc_page_size comme documentation also says that pour les grands ensembles de résultats.

P.S: parfois;) poser vos questions à http://discuss.elastic.co est mieux répondu par mainteneurs élastiques