Nuevas funciones de consulta en Couchbase Server 5.5

Por ejemplo, aquí está la sintaxis antigua:

Esto obtendrá 10 rutas que comienzan en el aeropuerto CMH, unidas con sus correspondientes documentos de aerolíneas. Los resultados están abajo (los estoy mostrando en vista de tabla, pero sigue siendo JSON):

Y aquí está la nueva sintaxis haciendo lo mismo:

La única diferencia es el EN. En lugar de EN TECLASAhora es ON =. Es más natural para los que proceden de un entorno relacional (como yo).

Pero eso no es todo. Ahora ya no estás limitado a unirte sólo a claves de documentos. He aquí un ejemplo de ÚNASE A en un campo de la ciudad.

Esta consulta mostrará los hoteles que coincidan con los aeropuertos en función de su ciudad.

Tenga en cuenta que para que esto funcione, debe tener un índice creado en el campo que está en el lado interno del JOIN. El bucket "muestra-viaje" ya contiene un índice predefinido en el campo ciudad. Si lo intentara con otros campos, obtendría un mensaje de error como "No index available for ANSI join term...".

Para más información sobre ANSI JOIN, consulte la página documentación completa de N1QL JOIN.

Nota: La antigua sintaxis JOIN, ON KEYS seguirá funcionando, así que no se preocupe por tener que actualizar su antiguo código.

A continuación probaré con un hash join, que debe invocarse explícitamente con una directiva USAR HASH insinuar.

Un hash join tiene dos lados: un CONSTRUIR y un SONDA. En CONSTRUIR de la unión se utilizará para crear una tabla hash en memoria. La dirección SONDA utilizará esa tabla para encontrar coincidencias y realizar la unión. Normalmente, esto significa que desea que la tabla CONSTRUIR que se utilizará en el menor de los dos conjuntos. Sin embargo, sólo se puede proporcionar una sugerencia de hash, y sólo para el lado derecho de la unión. Por tanto, si especifica CONSTRUIR en el lado derecho, entonces está utilizando implícitamente SONDA en el lado izquierdo (y viceversa).

Entonces, ¿por qué utilicé HASH(CONSTRUIR)?

Lo sé por usar INFER y/o Ideas para cubos que los puntos de referencia representan aproximadamente 10% de los datos, y los hoteles alrededor de 3%. Además, sé por haberlo probado que HASH(CONSTRUIR) era ligeramente más lento. Pero en cualquier caso, el tiempo de ejecución de la consulta era de milisegundos. Resulta que hay dos pares hotel-landmark con la misma dirección de correo electrónico.

USAR HASH le dirá a Couchbase que intente un hash join. Si no puede hacerlo (o si estás usando Couchbase Server Community Edition), volverá a un nested-loop. (Por cierto, puedes especificar explícitamente nested-loop con la opción USO NL pero actualmente no hay ninguna razón para hacerlo).

Para más información, consulte Unión HASH áreas de la documentación.

He aquí un ejemplo de consulta que busca el número total de hoteles y los agrupa por país, estado y ciudad.

La consulta se ejecutará y devolverá como resultado:

Echemos un vistazo al plan de consulta visual (sólo disponible en la edición Enterprise, pero puede ver el texto sin procesar del plan en la edición Community).

Tenga en cuenta que el único índice que se utiliza es para el tipo campo. El paso de agrupación realiza el trabajo de agregación. Con el conjunto de datos de muestras de viajes relativamente pequeño, esta consulta tarda unos 90 ms en mi escritorio de nodo único. Pero veamos qué ocurre si añado un índice a los campos por los que estoy agrupando:

Ahora, ejecute lo anterior SELECCIONE de nuevo. Debería devolver los mismos resultados. Pero..:

Nótese que esta vez no hay paso de "grupo". Todo el trabajo se transfiere al servicio de índices, que puede utilizar la función ix_hotelregiones índice. Puede utilizar este índice porque mi consulta coincide exactamente con los campos del índice.

El "push down" del índice no siempre se produce: su consulta tiene que cumplir unas condiciones específicas. Para más información, consulte la página Rendimiento de GROUP BY y agregado áreas de la documentación.