Referencia de Oracle NoSQL Database Cloud Service

Tipos de dato soportados

Oracle NoSQL Database Cloud Service soporta muchos tipos de datos comunes.

Tipo de datos	Descripción
`BINARY`	secuencia de cero o más bytes. El tamaño de almacenamiento es el número de bytes más una codificación del tamaño de la matriz de bytes, que es una variable, según el tamaño de la matriz.
`FIXED_BINARY`	Una matriz de bytes de tamaño fijo. No hay sobrecarga de codificación adicional para este tipo de datos.
`BOOLEAN`	Tipo de datos con uno de los dos valores posibles: `TRUE` o `FALSE`. El tamaño de almacenamiento del booleano es de 1 byte.
`DOUBLE`	Número de punto flotante largo, codificado con 8 bytes de almacenamiento para claves de índice. Si es una clave primaria, utiliza 10 bytes de almacenamiento.
`FLOAT`	Número de punto flotante largo, codificado con 4 bytes de almacenamiento para claves de índice. Si es una clave primaria, utiliza 5 bytes de almacenamiento.
`LONG`	Un número entero largo tiene una codificación de longitud variable que utiliza de 1 a 8 bytes de almacenamiento según el valor. Si es una clave primaria, utiliza 10 bytes de almacenamiento.
`INTEGER`	Un número entero largo tiene una codificación de longitud variable que utiliza de 1 a 4 bytes de almacenamiento según el valor. Si es una clave primaria, utiliza 5 bytes de almacenamiento.
`STRING`	Una secuencia de cero o más caracteres Unicode. El tipo String se codifica como UTF-8 y se almacena en esa codificación. El tamaño de almacenamiento es el número de bytes UTF-8 más la longitud, que puede ser de 1 a 4 bytes según el número de bytes en la codificación. Cuando se almacena en una clave de índice, el tamaño de almacenamiento es el número de bytes UTF-8 más un único byte de terminación nulo.
`NUMBER`	Número decimal de precisión arbitraria. Se serializa en un formato de matriz de bytes que se puede utilizar para comparaciones ordenadas. El formato tiene 2 partes: Signo y exponente más un dígito. Se tarda entre 1 y 6 bytes, pero normalmente es 2, a menos que el exponente sea bastante grande Mantisa del valor que es aproximadamente un byte por cada 2 dígitos Ejemplos: 12.345678 serializa en 6 bytes 1.234E+102 serializa en 5 bytes Note: Cuando necesite utilizar valores numéricos en el esquema, se recomienda decidir los tipos de datos en el orden indicado a continuación: INTEGER, LONG, FLOAT, DOUBLE, NUMBER Evite NUMBER a menos que realmente lo necesite para su caso de uso, ya que NUMBER es costoso tanto en términos de almacenamiento como de potencia de procesamiento utilizada.
`TIMESTAMP`	Un punto en el tiempo con una precisión. La precisión afecta al tamaño y al uso del almacenamiento. El registro de hora se almacena y gestiona en UTC (hora universal coordinada). El tipo de dato Timestamp necesita entre 3 y 9 bytes en función de la precisión utilizada. El siguiente desglose ilustra el almacenamiento utilizado por este tipo de dato: bit[0~13] año - 14 bits bit[14~17] mes - 4 bits bit[18~22] día - 5 bits bit[23~27] hora - 5 bits [opcional] bit[28~33] minuto - 6 bits [opcional] bit[34~39] segundo - 6 bits [opcional] bit[40~71] segundo fraccional [opcional con longitud variable]
`UUID`	Nota: El tipo de datos UUID se considera un subtipo del tipo de datos STRING. El tamaño de almacenamiento es de 16 bytes como clave de índice. Si se utiliza como clave primaria, el tamaño de almacenamiento es de 19 bytes.
`ENUM`	Una enumeración se representa como una matriz de cadenas. Los valores `ENUM` son identificadores simbólicos (tokens) y se almacenan como un pequeño valor entero que representa una posición ordenada en la enumeración.
`ARRAY`	Recopilación ordenada de cero tipos de elementos. Las matrices que no están definidas como JSON no pueden contener valores `NULL`. Las matrices declaradas como JSON pueden contener cualquier elemento JSON válido, incluido el valor especial "null", que es relevante para JSON.
`MAP`	Una recopilación sin ordenar de cero o más pares de clave-elemento, donde todas las claves son cadenas y todos los elementos son del mismo tipo. Todas las claves deben ser únicas. Los pares de clave-elemento se denominan campos, las claves son nombre de campo y los elementos asociados son valor de campo. Los valores de campo pueden tener diferentes tipos, pero las asignaciones no pueden contener valores de campo NULL.
`RECORD`	Una recopilación fija de uno o más pares clave-elemento, donde todas las claves son cadenas. Todas las claves de un registro deben ser únicas.
`JSON`	Todos los datos de JSON válidos.

Estados de tabla y ciclos de vida

Obtenga información sobre los diferentes estados de tabla y su importancia (proceso de ciclo de vida de tabla).

Cada tabla pasa por una serie de estados diferentes, desde la creación de la tabla hasta la supresión (borrado. Por ejemplo, una tabla en estado DROPPING no puede continuar con el estado ACTIVE, mientras que una tabla en estado ACTIVE puede cambiar al estado UPDATING. Puede realizar un seguimiento de los distintos estados de una tabla controlando el ciclo de vida de la tabla. En esta sección se describen los distintos estados de tabla.

Descripción de la tabla state.png
Descripción de la tabla de la ilustración-state.png

Estado de la Tabla	Descripción
`CREATING`	La tabla está en proceso de creación. No está lista para usarse.
`UPDATING`	Actualización de la tabla en curso. No se pueden realizar más modificaciones en la tabla mientras se encuentra en este estado. Una tabla está en estado `UPDATING` cuando: Se están cambiando los límites de la tabla El esquema de la tabla está evolucionando. Agregar o borrar el índice de una tabla.
`ACTIVE`	La tabla se puede utilizar en el estado actual. Puede que la tabla se haya creado o modificado recientemente, pero el estado de la tabla es ahora estable.
`DROPPING`	La tabla se está suprimiendo y no se puede acceder a ella con ningún fin.
`DROPPED`	La tabla se ha borrado y ya no existe para las actividades de lectura, escritura o consulta. Note: Una vez borrada, se puede volver a crear una tabla con el mismo nombre.

Depuración de errores de sentencias SQL en la consola de OCI

Al utilizar la consola de OCI para crear una tabla mediante una sentencia DDL o mediante una sentencia DML para insertar o actualizar datos o mediante una consulta SELECT para recuperar datos, puede que aparezca un error que indique que la sentencia es Incompleta o defectuosa en uno de los siguientes escenarios comunes:

Si tiene un punto y coma al final de la sentencia SQL.
Si hay un error de sintaxis en la sentencia SQL, como el uso incorrecto de comas, el uso de cualquier carácter innecesario en la sentencia, etc.
Si hay un error de ortografía en la sentencia SQL en cualquiera de las palabras clave SQL o en la definición del tipo de dato.
Si ha definido la columna como NOT NULL pero no le ha asignado un valor DEFAULT.
Si ha definido la columna como NOT NULL pero no le ha asignado un valor DEFAULT.

Cómo manejar algunos errores incompletos o defectuosos al utilizar la consola de OCI para crear o gestionar datos:

Elimine el punto y coma (si está presente) al final de la sentencia SQL.
Compruebe si hay algún carácter no deseado o puntuación incorrecta en la sentencia SQL.
Compruebe si hay errores ortográficos en la sentencia SQL.
Compruebe si todas las definiciones de columna están completas y son correctas.
Compruebe si ha definido una clave primaria para la tabla.

Si sigue recibiendo un error después de eliminar algunas de las posibles situaciones como se ha explicado anteriormente, puede utilizar Cloud Shell para ejecutar la consulta y capturar el error exacto como se muestra en el siguiente ejemplo.

Ejemplo: obtención del mensaje de error para una sentencia SELECT de Cloud Shell

El comando summarize comprueba la sintaxis y devuelve un breve resumen de una sentencia SQL.

En la consola de OCI, abra Cloud Shell desde el menú superior derecho.
Copie la sentencia SQL SELECT (por ejemplo, query1.sql) en una variable (SQL_SELECTSTMT).
Por ejemplo:
```
SQL_SELECTSTMT=$(cat ~/query1.sql | tr '\n' ' ')
```

Llame al siguiente comando oci para comprobar la sintaxis de la sentencia SQL SELECT.

Note:

Debe proporcionar compartment_id para esta sentencia SELECT.

oci raw-request --http-method GET --target-uri 
https://nosql.${OCI_REGION}.oci.oraclecloud.com/20190828/query/summarize?compartmentId=$NOSQL_COMPID\
&statement="$SQL_SELECTSTMT" | jq '.data'

Esto le dará el error exacto en la sentencia SQL.

Referencia de Data Definition Language

Aprenda a utilizar DDL en Oracle NoSQL Database Cloud Service.

Utilice DDL de Oracle NoSQL Database Cloud Service para crear, modificar y borrar tablas e índices.

Para obtener más información sobre la sintaxis del lenguaje DDL, consulte la guía Guía del lenguaje de definición de datos de tablas. Esta guía describe el lenguaje DDL soportado por el producto Oracle NoSQL Database local. Oracle NoSQL Database Cloud Service soporta un subgrupo de esta funcionalidad y las diferencias se documentan en la sección Diferencias de DDL en la nube.

Además, cada controlador NoSQL <language> proporciona una API para ejecutar una sentencia de DDL. Para escribir la aplicación, consulte Uso de API para crear tablas e índices en Oracle NoSQL Database Cloud Service.

Sentencias de DDL típicas

Algunos ejemplos de sentencias de DDL habituales son los siguientes:

Crear Tabla

CREATE TABLE [IF NOT EXISTS] (
    field-definition, field-definition-2 ...,
    PRIMARY KEY (field-name, field-name-2...),
) [USING TTL ttl]

Por ejemplo:

CREATE TABLE IF NOT EXISTS audience_info (
    cookie_id LONG,
    ipaddr STRING,
    audience_segment JSON,
    PRIMARY KEY(cookie_id))

Modificar tabla

ALTER TABLE table-name (ADD field-definition)
ALTER TABLE table-name (DROP field-name)
ALTER TABLE table-name USING TTL ttl

Por ejemplo:

ALTER TABLE audience_info USING TTL 7 days

Recuadro de Diálogo Crear Índice

CREATE INDEX [IF NOT EXISTS] index-name ON table-name (path_list)

Por ejemplo:

CREATE INDEX segmentIdx ON audience_info
       (audience_segment.sports_lover AS STRING)

Borrar tabla

DROP TABLE [IF EXISTS] table-name

Por ejemplo:

DROP TABLE audience_info

Consulte las guías de referencia para obtener una lista completa:

Diferencias de DDL en la nube

El lenguaje DDL del servicio en la nube difiere de lo que se describe a continuación en la guía de referencia:

Nombres de tablas

Tienen un límite de 256 caracteres y solo se pueden utilizar caracteres alfanuméricos y de subrayado.
Deben empezar por una letra
No pueden incluir caracteres especiales
No se soporta el uso de tablas secundarias

Conceptos no admitidos

Sentencias DESCRIBE y SHOW TABLE.
índices de texto completo
Gestión de usuarios y roles
Regiones locales

Referencia del lenguaje de consulta

Descubra cómo utilizar sentencias SQL para actualizar y consultar datos en Oracle NoSQL Database Cloud Service.

Oracle NoSQL Database utiliza el lenguaje de consulta SQL para actualizar y consultar datos en las tablas NoSQL. Consulte Referencia de SQL para Oracle NoSQL Database para conocer la sintaxis del lenguaje de consulta.

Consulta típica

SELECT <expression>
FROM <table name>
[WHERE <expression>]
[GROUP BY <expression>]
[ORDER BY <expression> [<sort order>]]
[LIMIT <number>]
[OFFSET <number>]; 

For example:
SELECT * FROM Users;
SELECT id, firstname, lastname FROM Users WHERE firstname = "Taylor";

UPDATE <table_name> [AS <table_alias>]
    <update_clause>[, <update_clause>]*
WHERE <expr>[<returning_clause>];

For example:
UPDATE JSONPersons $j
  SET TTL 1 DAYS
  WHERE id = 6
  RETURNING remaining_days($j) AS Expires;

Diferencias de lenguajes de consulta en la nube

El soporte de consulta del servicio en la nube difiere de lo que se describe en la guía de referencia del lenguaje de consulta de la siguiente forma:

Restricciones sobre Expresiones Utilizadas en la Cláusula SELECT

Oracle NoSQL Database Cloud Service admite la agrupación de expresiones o expresiones aritméticas entre funciones de agregación. No se permite ningún otro tipo de expresión en la cláusula SELECT. Por ejemplo, las expresiones CASE no están permitidas en la cláusula SELECT.

Cada controlador de base de datos NoSQL proporciona una API para ejecutar una sentencia de consulta.

Referencia de plan de consulta

Un plan de ejecución de consultas es la secuencia de operaciones que realiza Oracle NoSQL Database para ejecutar una consulta.

Un plan de ejecución de consulta es un árbol de iteradores de plan. Cada tipo de iterador evalúa un tipo diferente de expresión que puede aparecer en una consulta. En general, la elección del índice y el tipo de predicados de índice asociados pueden tener un efecto drástico en el rendimiento de las consultas. Como resultado, como usuario, a menudo desea ver qué índice utiliza una consulta y qué predicados se han reducido a él. Según esta información, puede que desee forzar el uso de un índice diferente mediante indicaciones de índice. Esta información se incluye en el plan de ejecución de consultas. . Todos los controladores NoSQL de Oracle proporcionan API para mostrar el plan de ejecución de una consulta.

Algunos de los iteradores más comunes e importantes utilizados en las consultas son:

Iterador de tabla: un iterador de tabla es responsable de:

Exploración del índice utilizado por la consulta (que puede ser el índice principal).
Aplicación de cualquier predicado de filtrado transferido al índice
Recupere las filas a las que apuntan las entradas de índice cualificadas si es necesario. Si el índice se cubre, el juego de resultados del iterador TABLE es un juego de entradas de índice; de lo contrario, es un juego de filas de tabla.

Note:

Un índice se denomina índice de cobertura con respecto a una consulta si la consulta se puede evaluar utilizando solo las entradas de ese índice, es decir, sin necesidad de recuperar las filas asociadas.

SELECT iterator: es responsable de ejecutar la expresión SELECT.

Cada consulta tiene una cláusula SELECT. Por lo tanto, cada plan de consulta tendrá un iterador SELECT. Un iterador SELECT tiene la siguiente estructura:


"iterator kind" : "SELECT",
"FROM" :
  {
  },
"FROM variable" : "...",
"SELECT expressions" : 
[
  {
  }
]

El iterador SELECT tiene campos como: "FROM", "WHERE", "FROM variable" y "SELECT expresiones". "FROM" y "variable FROM" representan la cláusula FROM de la expresión SELECT, WHERE representa la cláusula filter y "expresión SELECT" representa la cláusula SELECT.

Recibir iterador: es un iterador interno especial que separa el plan de consulta en 2 partes:

El propio iterador RECEIVE y todos los iteradores que están por encima de él en el árbol del iterador se ejecutan en el controlador.
Todos los iteradores debajo del iterador RECEIVE se ejecutan en los nodos de replicación (RN); estos iteradores forman un subárbol enraizado en el elemento secundario único del iterador RECEIVE.

En general, el iterador RECEIVE actúa como coordinador de consultas. Envía su subplan a los RN adecuados para su ejecución y recopila los resultados. Puede realizar operaciones adicionales, como ordenar y duplicar la eliminación, y propagar los resultados a sus iteradores ascendientes (si los hay) para su posterior procesamiento.

Tipos de distribución:

Un tipo de distribución especifica cómo se distribuirá la consulta para su ejecución en los RN que participan en una base de datos NoSQL de Oracle (un almacén). El tipo de distribución es una propiedad del iterador RECEIVE.

Las diferentes opciones de tipos de distribución son:

SINGLE_PARTITION: una consulta SINGLE_PARTITION especifica una clave de partición horizontal completa en su cláusula WHERE. Como resultado, el juego de resultados completo está contenido en una sola partición y el iterador RECEIVE enviará su subplan a un único RN que almacene esa partición. Una consulta SINGLE_PARTITION puede utilizar el índice de clave primaria o un índice secundario.
ALL_PARTITIONS: las consultas utilizan el índice de clave primaria aquí y no especifican una clave de partición horizontal completa. Como resultado, si el almacén tiene particiones M, el iterador RECEIVE enviará M copias de su subplan para que se ejecuten en una de las particiones M cada una.
ALL_SHARDS: las consultas utilizan un índice secundario aquí y no especifican una clave de partición horizontal completa. Como resultado, si la tienda tiene N particiones horizontales, el iterador RECEIVE enviará N copias de su subplan para que se ejecuten sobre una de las N particiones horizontales cada una.

Anatomía de un plan de ejecución de consulta:

La ejecución de la consulta se realiza en lotes. Cuando se envía un subplan de consulta a una partición o partición horizontal para su ejecución, se ejecutará allí hasta que se alcance un límite de lotes. El límite de lotes es un número de unidades de lectura consumidas localmente por la consulta. El valor por defecto es 2000 unidades de lectura (unos 2 MB de datos) y solo se puede reducir mediante una opción de nivel de consulta.

Cuando se alcanza el límite de lotes, los resultados locales producidos se envían de vuelta al iterador RECEIVE para su posterior procesamiento junto con un indicador booleano que indica si pueden estar disponibles más resultados locales. Si el indicador es verdadero, la respuesta incluye información de reanudación. Si el iterador RECEIVE decide volver a enviar la consulta a la misma partición/partición, incluirá esta información de reanudación en su solicitud, de modo que la ejecución de la consulta se reiniciará en el punto en el que se detuvo durante el lote anterior. Esto se debe a que no se mantiene ningún estado de consulta en el RN una vez que finaliza un lote. El siguiente lote para la misma partición/partición puede tener lugar en el mismo RN que el lote anterior o en un RN diferente que también almacene la misma partición/partición.