2011-08-24 3 views
1

J'ai HBase fonctionnant en mode autonome et j'ai rencontré quelques problèmes lorsque j'ai interrogé les tables en utilisant l'API Java. Le tableau a plusieurs millions d'entrées (mais pourrait atteindre des milliards) qui ont la clé ligne métrique suivante:HBase scan avec des filtres de comparaison a un long délai lors du retour à la dernière ligne

<UUID>-<Tag>-<Timestamp> 

J'utilise deux filtres opération de comparaison pour interroger une plage de ligne spécifique qui représente un intervalle de temps.

Scan scan = new Scan(); 
RowFilter upperRowFilter = new RowFilter(CompareOp.LESS, 
    new BinaryComparator(securityId + eventType + intervalEnd) 
     .getBytes())); 

RowFilter lowerRowFilter = new RowFilter(CompareOp.GREATER_OR_EQUAL, 
    new BinaryComparator(securityId + eventType + intervalStart) 
     .getBytes())); 

FilterList filterList = new FilterList(); 
filterList.addFilter(lowerRowFilter); 
filterList.addFilter(upperRowFilter); 

scan.setFilter(filterList); 
scanner = table.getScanner(scan); 
result = scanner.next(); 

Quand j'appelle la méthode tout ResultScanner # suivant() fonctionne très bien jusqu'à ce qu'il arrive à la dernière ligne de la plage clé qui est spécifiée à travers les filtres. Il faut jusqu'à 40 secondes jusqu'à ce que le ResultScanner renvoie la dernière ligne, qui est lexicalement plus petite que la limite de plage supérieure .

Quand je change l'ordre des filtres dans le FilterList de

filterList.addFilter(lowerRowFilter); 
filterList.addFilter(upperRowFilter); 

à

filterList.addFilter(upperRowFilter); 
filterList.addFilter(lowerRowFilter); 

il prend le scanner jusqu'à 40 secondes jusqu'à ce qu'il commence à retourner les résultats mais il y a non plus de retard sur le retour de la dernière ligne, donc j'ai pensé que le retard vient du CompareOp.LESS - filtre. Le seul moyen que je connaisse pour contourner ce délai est d'omettre le upperRowFilter et de vérifier manuellement si les touches de rangée sont hors limites mais je suis sûr qu'il doit y avoir quelque chose de mal, parce que je n'ai rien trouvé sur ce problème. l'Internet. J'ai aussi déjà essayé de m'en débarrasser avec la mise en cache, mais quand j'utilise une taille de cache inférieure au nombre de lignes retournées, ça ne change rien et si j'utilise une taille de cache plus grande que le nombre de lignes retournées le délai est toujours là mais encore avant que les résultats sont retournés.

Avez-vous une idée de ce qui pourrait causer ce genre de comportement? Est-ce que je me trompe ou y a-t-il quelque chose qui me manque?

Merci d'avance!

Répondre

1

Le problème est que votre scanner analyse la table entière et rejette les résultats qui ne correspondent pas à votre requête. Vous devez définir explicitement une ligne d'arrêt de (securityId + eventType + intervalEnd). Si vous définissez une ligne de début correspondante de (securityId + eventType + intervalStart), vous n'aurez plus besoin d'un filtre et l'analyse sera efficace quelle que soit la taille de votre ensemble de données.

+0

Ouais thx, cela a résolu le problème pour moi! Mais ce que je ne comprends pas, c'est pourquoi le scanner scanne toute la table. Si une ligne qui est supérieure à (securityId + eventType + intervalStart) est trouvée, elle peut arrêter l'analyse ... – Tobson

Questions connexes