¿Cómo se utiliza la consulta IBM Cloudant ?

IBM Cloudant Se accede a la consulta a través del punto final de API de POST /{db}/_find donde se pasa la especificación JSON de la consulta en el cuerpo HTTP POST. Por ejemplo, esta consulta busca hasta 10 documentos donde firstname es "Charles" y surname es "Dickens":

{
  "selector": {
    "firstname": "Charles",
    "surname": "Dickens"
  },
  "limit": 10
}

Para obtener más información, consulte Sintaxis del selector.

¿Cómo puedo crear un índice para dar soporte a una consulta IBM Cloudant ?

Sin un índice secundario adecuado, IBM Cloudant Query explora cada documento de la base de datos a su vez hasta que tenga suficientes coincidencias para satisfacer la consulta. Cuanto más grande sea el conjunto de datos y más documentos tenga que escanear para encontrar documentos coincidentes, más lento será el tiempo de respuesta. Para un rendimiento más rápido, una IBM Cloudant _find debe estar respaldada por un índice secundario adecuado. Un índice secundario es una estructura de datos calculada previamente que permite a IBM Cloudant saltar rápidamente a la porción de datos que necesita sin explorar documentos irrelevantes. Para los campos surname , llamamos al punto final POST /{db}/_index para pasar la definición de índice JSON como cuerpo HTTP POST:

{
  "index": {
    "fields": ["firstname", "surname"]
  },
  "ddoc": "jsonindexes",
  "name": "byName",
  "type": "json"
}

Para obtener más información, consulte Creación de un índice.

¿Puedo ordenar mis resultados de búsqueda con la consulta IBM Cloudant ?

¡Sí! La sintaxis JSON de _find permite que se proporcione un parámetro sort que lista el atributo o atributos por los que ordenar. En este caso, estamos ordenando por date:

{
  "selector": {
    "firstname": "Charles",
    "surname": "Dickens"
  },
  "sort": ["date"],
  "limit": 10
}

Debe estar presente un índice adecuado que contenga los campos selector y sort . De lo contrario, IBM Cloudant se niega a ejecutar la consulta. A continuación se muestra una definición de índice adecuada para la consulta anterior:

{
   "index": {
      "fields": [
         "firstname",
         "surname",
         "date"
      ]
   },
   "ddoc": "jsonindexes",
   "name": "byNameAndDate",
   "type": "json"
}

¿Puedo ordenar en orden inverso?

¡Sí! IBM Cloudant Query admite la ordenación del conjunto de resultados en orden ascendente o descendente, pero no una combinación de los dos. Por ejemplo, una consulta que ordena algunos campos en orden ascendente, y una consulta en la que no se permite descender.

Esta consulta devuelve documentos que coinciden con firstname y surname y ordena por surname/firstname/date descendente:

{
  "selector": {
    "firstname": "Charles",
    "surname": "Dickens"
  },
  "sort": [
    { "firstname": "desc" },
    { "surname": "desc" },
    { "date": "desc" }
  ],
  "limit": 10
}

Debe estar presente un índice adecuado que contenga los campos selector y sort . De lo contrario, IBM Cloudant se niega a ejecutar la consulta. A continuación se muestra una definición de índice adecuada para la consulta anterior:

{
   "index": {
      "fields": [
         "firstname",
         "surname",
         "date"
      ]
   },
   "ddoc": "jsonindexes",
   "name": "byNameAndDate",
   "type": "json"
}

El índice anterior es adecuado para el orden de clasificación ascendente y descendente.

¿Cómo puedo saber si un índice está respaldando una consulta?

El punto final de API de POST /{db}/_explain cuando se pasa un objeto JSON que normalmente se envía al punto final POST /{db}/_find , explica cómo se maneja una consulta de este tipo y qué índices, si los hay, se pueden utilizar.

Si el objeto index de la respuesta indica que se está utilizando "all_docs", se necesita una exploración de base de datos completa para dar servicio a la consulta. Se recomienda utilizar el mecanismo _explain para comprobar cada consulta IBM Cloudant para asegurarse de que utiliza un índice antes de realizar el despliegue en producción.

Por ejemplo, un índice type=json en firstname, surname y date es adecuado para buscar documentos para:

• Un firstname, lastnamey dateconocidos.
• Un firstnameconocido, lastnamey un rango de valores date (que utilizan operadores $lt, $lte, $gt, $gte ).
• Un firstname y un lastname conocidos ordenados por date.

También se puede utilizar para ayudar a las consultas sobre firstname, surname, datey otros atributos. En otras palabras, puede ser capaz de responder sólo una parte de la consulta, pero puede ayudar a reducir el número de documentos que se exploran para encontrar la respuesta.

¿Cómo puedo asegurar que mi consulta sea eficaz?

Lo ideal sería que una ejecución de consulta de IBM Cloudant tuviera que explorar sólo un documento para cada documento devuelto. Si una consulta tiene que escanear un millón de documentos por cada uno devuelto, claramente no es óptima y necesita un índice secundario para ayudarle.

Cuando ejecuta una consulta, al pasar execution_stats: true como un parámetro adicional fuerza a IBM Cloudant a enumerar el número de documentos que ha explorado al realizar la consulta, por ejemplo:

{
  "selector": {
    "firstname": "Charles",
    "surname": "Dickens"
  },
  "sort": ["date"],
  "limit": 10,
  "execution_stats": true
}

Los datos devueltos ahora incluyen un objeto JSON adicional:

{
  ...
  "execution_stats": {
    "total_keys_examined": 0,
    "total_docs_examined": 1000000,
    "total_quorum_docs_examined": 0,
    "results_returned": 2,
    "execution_time_ms": 4400.699
  }
}

La proporción entre total_docs_examined y results_returned es clave aquí: un valor alto indica que se están explorando demasiados documentos por documento que se devuelve.

Para obtener más información, consulte Blog post on Optimizing IBM Cloudant Consultas.

¿Qué operadores de consulta IBM Cloudant derrotan el uso de un índice?

Cualquiera de los operadores de combinación distintos de $and puede hacer que una consulta realice una exploración de base de datos completa sin la ayuda de un índice secundario. Por ejemplo, si se utiliza un operador $or , no se puede utilizar ningún índice secundario para ayudar a la consulta. En caso de duda, utilice el punto final POST /{db}/_explain para comprobar que se utiliza un índice y el parámetro execution_stats: true para medir la eficiencia de cada consulta.

Para que un índice de type=json se utilice para dar soporte a una consulta, debe coincidir con los campos que se utilizan en el selector y los parámetros de ordenación. Los operadores de comparación se pueden utilizar en el último elemento para realizar consultas de rango.

Para obtener más información, consulte Explicar planes.

¿Puedo utilizar IBM Cloudant Query con un índice Lucene?

¡Sí! IBM Cloudant Query da soporte a dos tipos de índices:

• "type": "json" -un índice de orden fijo basado en la API MapReduce de IBM Cloudant. Bueno para consultas fijas, con contenedor modelo que coinciden con todos los términos del índice.
• "type": "text" -un índice Lucene basado en la API de búsqueda de IBM Cloudant. Adecuado para consultas de propósito general en uno, algunos o todos los campos indexados.

Se crea un índice type=text con una definición de índice como la siguiente:

{
   "index": {
      "fields": [
         { "name": "firstname", "type": "string"},
         { "name": "surname", "type": "string"},
         { "name": "date", "type": "string"}
      ]
   },
   "ddoc": "textindexes",
   "name": "byNameAndDate",
   "type": "text"
}

Tenga en cuenta que la matriz fields requiere que cada atributo se denomine y se teclee (a diferencia de los índices de type=json ).

Las consultas que contienen uno o varios de los campos indexados pueden utilizar el índice resultante:

{
  "selector": {
    "surname": "Dickens"
  },
  "sort": ["date"],
  "limit": 10,
  "execution_stats": true
}

Los índices respaldados por Lucene permiten cierta flexibilidad adicional sobre los índices de type=json . Puede utilizar uno, algunos o todos los campos indexados en cualquier orden, y el índice da soporte a la consulta. Con los índices de type=json , la consulta debe coincidir con todos los campos indexados para ser útil.

Para obtener más información, consulte Creación de un índice de type=text.

¿Puedo crear un índice de consulta IBM Cloudant para un subconjunto de una base de datos?

¡Sí! Si su caso de uso requiere que las consultas se realicen dentro de los confines de un subconjunto de la base de datos (por ejemplo, pedidos completados , usuarios confirmados o productos en stock ), es mejor un índice parcial . Un índice parcial permite que se utilice un selector de consulta IBM Cloudant en el momento de la creación del índice para ganar el conjunto de datos que lo convierte en el índice, manteniendo el índice pequeño y con rendimiento. A continuación, en el momento de la consulta, se utiliza un selector de consulta estándar IBM Cloudant para filtrar adicionalmente el índice parcial para obtener el conjunto de resultados.

Se crea un índice parcial pasando un partial_filter_selector al método POST /{db}/_index . En este ejemplo, sólo los libros de texto que tienen un estado de "publicado" o "reimprimir" pueden llegar al índice. Consulte el ejemplo siguiente:

{
  "index": {
    "partial_filter_selector": {
      "$or": [
        { "status": "published" },
        { "status": "reprint" }
      ],
      "hardback": true
    },
    "fields": ["firstname","surname","date"]
  },
  "ddoc" : "partialindexes",
  "name": "byNameAndDate"
  "type" : "json"
}

En el momento de la consulta, se debe proporcionar el campo use_index para indicar a IBM Cloudant que desea que utilice el índice especificado:

{
  "selector": {
      "$or": [
        { "status": "published" },
        { "status": "reprint" }
      ],
      "hardback": true,
      "firstname": "Charles",
      "surname": "Dickens"
  },
  "sort": ["date"],
  "limit": 10,
  "execution_stats": true,
  "use_index": "partialindexes/byNameAndDate"
}

Los campos partial_filter_selector se repiten en el selector de tiempo de consulta.

Para obtener más información, consulte Creación de un índice parcial.

¿Puedo utilizar IBM Cloudant Query en bases de datos particionadas?

¡Sí! De forma predeterminada, un índice de consulta IBM Cloudant es global (por ejemplo, no particionado) pero en una base de datos particionada, se puede crear un índice particionado añadiendo partitioned: true cuando se crea el índice: e Para crear un índice particionado en firstname y surname, se utiliza POST /<dbname>/_index :

{
  "index": {
    "fields": ["firstname", "surname"]
  },
  "ddoc": "jsonindexes",
  "name": "byName",
  "type": "json",
  "partitioned": true
}

Los índices particionados se pueden utilizar cuando se ejecuta sólo una consulta particionada, por ejemplo, utilizando el punto final de la API de GET /<dbname>/_partition/<partition key>/_find .

Para obtener más información, consulte Creación de un índice particionado.

¿Puedo utilizar expresiones regulares en mis consultas?

¡Sí! IBM Cloudant Query tiene un operador $regex que permite términos de expresión regular dentro de una consulta.

Continúe con precaución: si una consulta contiene solo un operador $regex , un índice secundario no puede ayudarle: la consulta da como resultado una exploración de documento por documento de la base de datos.

Un operador $regex se puede etiquetar al final de una consulta ya ejecutante. Por ejemplo, si ya tenemos un índice type=json en firstname y surname, podemos utilizar el ejemplo siguiente:

{
  "selector": {
    "firstname": "Charles",
    "surname": "Dickens",
    "title": {
      "$regex": "^Oliv"
    }
  },
  "limit": 10
}

IBM Cloudant utiliza el índice para buscar documentos por firstname y surname y winnows el conjunto de resultados que utiliza la expresión regular en el campo title .