TechnologyDecember 15, 2014

Tout savoir sur ALLOW FILTERING

Tout savoir sur ALLOW FILTERING

Consultez notre page sur l’indexation dans Cassandra pour en savoir plus sur la manière de résoudre le problème ALLOW FILTERING avec les SAI (storage-attached indexes) et vous essayer à un exercice pratique.

 


 

Lors de mes discussions avec les participants au London C* Summit, je me suis rendu compte que la raison pour laquelle Cassandra nécessite ALLOW FILTERING pour certaines requêtes CQL et pas d’autres n’est pas toujours claire.

Pourquoi ALLOW FILTERING ?

Prenons par exemple la table suivante :

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
CREATE TABLE blogs (blogId int, 
                    time1 int, 
                    time2 int, 
                    author text, 
                    content text, 
                    PRIMARY KEY(blogId, time1, time2));

Si vous exécutez la requête suivante :

SELECT * FROM blogs;

Cassandra vous retournera toutes les données que la table blogs contient. Si vous ne voulez que les données à un moment spécifié time1, vous ajouterez naturellement une condition égale sur la colonne time1 :

SELECT * FROM blogs WHERE time1 = 1418306451235;

En réponse, vous recevrez le message d’erreur suivant :

<em>Bad Request: Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING.</em>

Cassandra sait qu’elle ne pourra peut-être pas exécuter la requête de manière efficace. Elle vous avertit donc : « Attention ! Exécuter cette requête telle quelle n’est peut-être pas une bonne idée, car elle mobilisera beaucoup de vos ressources informatiques. »

La seule manière pour Cassandra d’exécuter cette requête est de récupérer toutes les lignes de la table blogs et d’exclure celles qui n’ont pas la valeur demandée pour la colonne time1.

Si votre table contient par exemple 1 million de lignes et que 95 % d’entre elles ont la valeur demandée pour la colonne time1, la requête restera relativement efficace et vous devriez utiliser ALLOW FILTERING.

En revanche, si votre table contient 1 million de lignes et seulement 2 contiennent la valeur demandée pour la colonne time1, votre requête est extrêmement inefficace. Cassandra chargera 999 998 lignes pour rien, Si la requête est souvent utilisée, il est probablement préférable d’ajouter un index à la colonne time1.

Malheureusement, Cassandra ne peut pas différencier entre les 2 cas ci-dessus, car ils dépendent de la distribution des données de la table. Cassandra émet donc une mise en garde et c’est à vous de faire le bon choix.

Index secondaires et ALLOW FILTERING

Si nous ajoutons un index à la colonne author et exécutons la requête suivante :

SELECT * FROM blogs WHERE author = ‘Jonathan Ellis’;

Cassandra retournera tous les blogs écrits par Jonathan et ne demandera pas ALLOW FILTERING. Cela est dû au fait que Cassandra peut utiliser l’index secondaire sur la colonne author pour trouver les lignes correspondantes et n’a pas besoin d’effectuer d’opération de filtrage.

En revanche, si nous exécutons ceci :

SELECT * FROM blogs WHERE author=’Jonathan Ellis’ and time2 = 1418306451235;

Cassandra demandera ALLOW FILTERING, car elle devra d’abord trouver et charger les lignes contenant Jonathan comme auteur puis exclure celles qui n’ont pas une colonne time2 égale à la valeur spécifiée.

Ajouter un index à time2 peut améliorer la performance de la requête. Cassandra utilisera ensuite l’index avec la sélectivité la plus élevée pour trouver les lignes qui doivent être chargées. Cela ne changera toutefois rien quant à la nécessité d’ALLOW FILTERING, car elle devra tout de même filtrer les lignes chargées en utilisant le prédicat restant.

Faire le bon choix

Lorsque votre requête est rejetée par Cassandra parce qu’elle nécessite un filtrage, vous devez résister à l’envie de simplement ajouter ALLOW FITLERING. Réfléchissez plutôt à vos données, à votre modèle et à ce que vous essayez de faire. Vous avez toujours plusieurs options.

Vous pouvez changer votre modèle de données, utiliser un index, utiliser une autre table ou utiliser ALLOW FILTERING.

Vous devez faire le bon choix pour votre cas d’utilisation spécifique.

Share

One-stop Data API for Production GenAI

Astra DB gives JavaScript developers a complete data API and out-of-the-box integrations that make it easier to build production RAG apps with high relevancy and low latency.