Création d'un index partiel

IBM Cloudant Query prend en charge les index partiels à l'aide de la zone partial_filter_selector. Le site partial_filter_selector contient une requête standard IBM Cloudant qui est exécutée au moment de l'indexation. Les documents qui ne correspondent pas au sélecteur ne sont pas ajoutés à l'index.

Voici un exemple de requête :

{
  "selector": {
    "status": {
      "$ne": "archived"
    },
    "type": "user"
  }
}

Sans index partiel, cette requête nécessite une analyse d'index complète pour identifier tous les documents dont le type est type:user et dont le statut n'est pas archived. En effet, dans ce cas, un index normal peut être utilisé pour rechercher les lignes contiguës, à la différence de l'opérateur $ne.

Pour améliorer le temps de réponse, vous pouvez créer un index qui exclut les documents avec status: { $ne: archived } au moment de l'indexation en utilisant partial_filter_selector comme le montre l'exemple suivant :

POST /db/_index HTTP/1.1
Content-Type: application/json
Content-Length: 144
Host: localhost:5984

{
  "index": {
    "partial_filter_selector": {
      "status": {
        "$ne": "archived"
      }
    },
    "fields": ["type"]
  },
  "ddoc" : "type-not-archived",
  "type" : "json"
}

Les index partiels ne sont pas utilisés par le planificateur de requêtes à moins qu'ils ne soient spécifiés par un champ. Vous devez donc modifier la requête originale par un champ use_index, vous devez donc modifier la requête originale :

{
  "selector": {
    "status": {
      "$ne": "archived"
    },
    "type": "user"
  },
  "use_index": "type-not-archived"
}

Techniquement, il n'est pas nécessaire d'inclure le filtre dans la zone status dans le sélecteur de requête. L'index partiel garantit que cette valeur est toujours true. Toutefois, si vous incluez le filtre, l'intention du sélecteur sera plus claire. Il est également plus facile de tirer profit des améliorations futures de la planification de requête (par exemple, la sélection automatique d'index partiels).