Procesamiento de consultas de Cloud SQL

Las tablas externas de Oracle no tienen índices tradicionales. Las consultas de estas tablas externas normalmente necesitan una exploración de tabla total. El agente de procesamiento de Oracle Cloud SQL en los nodos de datos del cluster de Hadoop amplía las capacidades de exploración inteligente (como las descargas de predicado de filtro) a las tablas externas de Oracle. Smart Scan se ha utilizado durante algún tiempo en Oracle Exadata Database Machine para realizar un filtrado de columnas y predicados en la capa de almacenamiento antes de que los resultados de la consulta se envíen de nuevo a la capa de base de datos. En Cloud SQL, Smart Scan es un filtrado final que se realiza localmente en el servidor de Hadoop para garantizar que solo los elementos solicitados se envían a Cloud SQL Query Server. Las celdas de Cloud SQL que se ejecutan en los nodos de datos de Hadoop pueden realizar exploraciones inteligentes con diferentes formatos de datos en HDFS, como texto CSV, Avro y Parquet.

Esta implementación de Smart Scan aprovecha la potencia de procesamiento en paralelo masiva del cluster de Hadoop para filtrar los datos en su origen. Puede desechar de forma preventiva una parte enorme de datos irrelevantes, hasta un 99 % del total. Esto tiene varias ventajas:

• Reduce considerablemente el movimiento de datos y el tráfico de red entre el cluster y la base de datos.

• Devuelve conjuntos de resultados mucho más pequeños al servidor de Oracle Database.

• Agrega datos cuando es posible, ya que aprovecha la escalabilidad y el procesamiento de clusters.

Los resultados de la consulta se devuelven considerablemente más rápido. Es el resultado directo del tráfico reducido en la red y la carga reducida en Oracle Database.

Para los datos almacenados en HDFS, Oracle Cloud SQL mantiene los índices de almacenamiento automáticamente, que es transparente para Oracle Database. Los índices de almacenamiento contienen el resumen de la distribución de datos en un disco duro para los datos almacenados en HDFS. Los índices de almacenamiento reducen el costo de las operaciones de E/S y el costo de la CPU relacionados con la conversión de datos de archivos planos a bloques de Oracle Database. Puede pensar en un índice de almacenamiento como un índice negativo. Indica a Smart Scan que los datos no están en un bloque de datos, lo que permite a Smart Scan omitir la lectura de ese bloque. Esto puede provocar una reducción de E/S significativa.

Los índices de almacenamiento solo se pueden utilizar para tablas externas que estén basadas en HDFS y se hayan creado con los controladores ORACLE_HDFS o ORACLE_HIVE. Los índices de almacenamiento no se pueden utilizar para las tablas externas que utilizan StorageHandlers, como Apache HBase y Oracle NoSQL.

Un índice de almacenamiento es una recopilación de índices de región en memoria, y cada índice de región almacena resúmenes para hasta 32 columnas. Hay un índice de región para cada división. El contenido almacenado en un índice de región es independiente de los otros índices de región. Esto los hace altamente escalables y evita la contención de bloqueos internos.

Los índices de almacenamiento mantienen los valores mínimo y máximo de las columnas de una región para cada índice de región. Los valores mínimos y máximos se utilizan para eliminar la E/S innecesaria, que también se conoce como filtrado de E/S. Los bytes de E/S de gránulo XT de celda guardados por la estadística de índices de almacenamiento, disponible en la vista V$SYSSTAT, muestra el número de bytes de E/S guardados mediante los índices de almacenamiento.

Las consultas que utilizan las siguientes comparaciones mejoran con los índices de almacenamiento:

• Igualdad (=)

• Inequality (<, != o >)

• Menor o igual que (<=)

• Mayor o igual que (>=)

• ES NULO

• NO ES NULO

Los índices de almacenamiento se crean automáticamente después de que el servicio Oracle Cloud SQL reciba una consulta con un predicado de comparación mayor que el valor máximo o menor que el valor mínimo para la columna en una región.

Eliminación de E/S de disco con índices de almacenamiento

En la siguiente figura se muestran una tabla e índices de región. Los valores de la columna B en la tabla oscilan entre 1 y 8. Un índice de región almacena el mínimo de 1 y el máximo de 5. El otro índice de región almacena el mínimo de 3 y el máximo de 8.

Para una consulta como la siguiente, solo coincide el primer juego de filas. Se elimina la E/S de disco porque el mínimo y el máximo del segundo juego de filas no coinciden con la cláusula WHERE de la consulta.

SELECT * 
FROM TABLE 
WHERE B < 2;

Mejora del rendimiento de la unión con índices de almacenamiento

El uso de índices de almacenamiento permite que las uniones de tablas omitan operaciones de E/S innecesarias. Por ejemplo, la siguiente consulta realizaría una operación de E/S y aplicaría un filtro Bloom solo al primer bloque de la tabla de hechos. Los filtros Bloom son la clave para mejorar el rendimiento de la unión. En el ejemplo, un predicado está en la tabla de dimensiones, no en la tabla de hechos. El filtro Bloom se crea según dim.name=Hard drive, y este filtro se aplica después a la tabla de hechos. Por lo tanto, aunque el filtro esté en la tabla de dimensiones, podrá filtrar los datos en su origen (Hadoop) según los resultados de la consulta de dimensión. Esto también permite que se apliquen las optimizaciones, como los índices de almacenamiento.

SELECT count(*) 
FROM fact, dimension dim  
WHERE fact.m=dim.m and dim.product="Hard drive";

Los índices de almacenamiento eliminan completamente la E/S del segundo bloque de la tabla de hechos porque su rango mínimo/máximo (5,8) no está presente en el filtro Bloom.

Muchos sistemas de Big Data soportan algún nivel de descarga de predicado, ya sea a través del propio tipo de archivo (por ejemplo, Apache Parquet) o a través de la partición de Hive y las API de StorageHandler. Oracle Cloud SQL aprovecha estas capacidades de descarga mediante la transferencia de predicados de Oracle Database a sistemas de soporte. Por ejemplo, el descenso de predicados activa los siguientes comportamientos automáticos:

• Las consultas de las tablas particionadas de Hive se depuran según los predicados de filtro de las columnas de partición.

• Las consultas de archivos de Apache Parquet y Apache ORC reducen la E/S mediante la prueba de predicados en las estructuras internas de tipo índice incluidas en estos formatos de archivo.

  Nota
  
  Los archivos de Parquet deben crearse con Hive o Spark. Los archivos de Parquet creados con Apache Impala no tienen las estadísticas necesarias para que el descenso de predicados se aplique.

• Las consultas de Oracle NoSQL Database o Apache HBase utilizan predicados de SARGable para impulsar las subexploraciones de los datos en el almacén de datos remoto.

Las consultas de datos de Hadoop pueden implicar el procesamiento de objetos grandes con millones de registros posibles. No es eficaz devolver estos objetos a Oracle Database para el filtrado y análisis. Oracle Cloud SQL puede proporcionar un aumento significativo del rendimiento al transferir el procesamiento de CLOB a sus propias celdas de procesamiento en el cluster de Hadoop. El filtrado en Hadoop reduce el número de filas devueltas a Oracle Database. El análisis reduce la cantidad de datos devueltos de una columna en cada fila filtrada.

Puede desactivar o volver a activar el procesamiento de CLOB según sus propias necesidades.

Esta funcionalidad se aplica actualmente solo a expresiones JSON que devuelven datos CLOB. Las expresiones de filtro JSON elegibles para la evaluación de capa de almacenamiento incluyen sintaxis simplificada, JSON_VALUE y JSON_QUERY.

Se proporcionará el mismo soporte para otros tipos de CLOB (como substr y instr), así como para los datos BLOB, en una versión futura.

{"ponumber":9764,"reference":"LSMITH-20141017","requestor":"Lindsey Smith","email": "Lindsey@myco.com", "company":"myco" …}

CREATE TABLE POS_DATA
  ( pos_info CLOB )
  ORGANIZATION EXTERNAL
  ( TYPE ORACLE_HDFS
    DEFAULT DIRECTORY DEFAULT_DIR
    LOCATION ('/data/pos/*')
  )
 REJECT LIMIT UNLIMITED;

SELECT p.pos_info.email, p.pos_info.requestor
FROM POS_DATA p
WHERE p.pos_info.company='myco'

Oracle Cloud SQL utiliza la tecnología Oracle In-Memory para transferir el procesamiento de agregación a las celdas de Cloud SQL. Esto permite a Cloud SQL aprovechar la potencia de procesamiento del cluster de Hadoop para distribuir agregaciones entre los nodos de cluster.

El aumento del rendimiento puede ser significativamente más rápido en comparación con las agregaciones que no descargan, especialmente cuando hay un número moderado de agrupaciones de resumen. Para las consultas de una única tabla, la operación de agregación debe descargar coherentemente.

Las celdas de Cloud SQL soportan agregaciones de una única tabla y de varias tablas (por ejemplo, tablas de dimensiones que se unen a una tabla de hechos). Para agregaciones de varias tablas, Oracle Database utiliza la optimización de transformación de vector clave en la que los vectores clave se transfieren a las celdas del proceso de agregación. Este tipo de transformación es útil para las consultas SQL de unión en estrella que utilizan operadores de agregación típicos (como SUM, MIN, MAX y COUNT), que son comunes en las consultas de negocio.

Una consulta de transformación de vector es una consulta más eficaz que utiliza un filtro Bloom para las uniones. Cuando utiliza una consulta transformada de vector con celdas de Cloud SQL, el rendimiento de las uniones en la consulta mejora con la capacidad de descargar la filtración para las filas que se utilizan para la agregación. Verá una operación KEY VECTOR USE en el plan de consulta durante esta optimización.

En las celdas de Cloud SQL, las consultas transformadas de vector se benefician de un procesamiento más eficaz debido a la aplicación de columnas group-by (vectores clave) al índice de almacenamiento de Cloud SQL.

Oracle Cloud SQL proporciona una serie de estadísticas que pueden contribuir datos para los análisis de rendimiento.

SQL> SELECT sn.name,ms.value 
FROM V$MYSTAT ms, V$STATNAME sn 
WHERE ms.STATISTIC#=sn.STATISTIC# AND sn.name LIKE '%XT%'; 

NAME                                                      VALUE
-----------------------------------------------------     -----
cell XT granules requested for predicate offload          0 
cell XT granule bytes requested for predicate offload     0
cell interconnect bytes returned by XT smart scan         0 
cell XT granule predicate offload retries                 0
cell XT granule IO bytes saved by storage index           0 

SQL> SELECT n.name, round(s.value/1024/1024) 
FROM v$mystat s, v$statname n
WHERE s.statistic# IN (462,463)
AND s.statistic# = n.statistic#;

cell XT granule bytes requested for predicate offload  32768
cell interconnect bytes returned by XT smart scan   32

SQL> SELECT count(*) FROM bdsql_parq.web_sales;

  COUNT(*)
----------
 287301291

SQL> SELECT substr(n.name, 0,60) name, u.value
FROM v$statname n, v$mystat u
WHERE ((n.name LIKE 'key vector%') OR
       (n.name LIKE 'vector group by%') OR
       (n.name LIKE 'vector encoded%') OR
       (n.name LIKE '%XT%') OR
       (n.name LIKE 'IM %' AND n.name NOT LIKE '%spare%'))
      AND u.sid=userenv('SID')
      AND n.STATISTIC# = u.STATISTIC#
      AND u.value > 0;


NAME                                                      VALUE
-----------------------------------------------------     -----
cell XT granules requested for predicate offload          808 
cell XT granule bytes requested for predicate offload     2.5833E+10
cell interconnect bytes returned by XT smart scan         6903552 
vector group by operations sent to cell                   1
vector group by rows processed on cell                    287301291
vector group by rows returned by cell                     808

SELECT substr(n.name, 0,60) name, u.value
FROM v$statname n, v$mystat u
WHERE ((n.name LIKE 'key vector%') OR
       (n.name LIKE 'vector group by%') OR
       (n.name LIKE 'vector encoded%') OR
       (n.name LIKE '%XT%'))
      AND u.sid=userenv('SID')
      AND n.STATISTIC# = u.STATISTIC#


NAME                                                      VALUE
-----------------------------------------------------     -----
cell XT granules requested for predicate offload          250 
cell XT granule bytes requested for predicate offload     61,112,831,993
cell interconnect bytes returned by XT smart scan         193,282,128 
key vector rows processed by value                        14,156,958
key vector rows filtered                                  9,620,606
key vector filtered on cell                               273,144,333
key vector probed on cell                                 287,301,291
key vectors sent to cell                                  1
key vectors sent to cell in lite mode due to quota        1
key vector serializations in lite mode for cell           1
key vector efilters created                               1