Diseño de una tabla en Oracle NoSQL Database Cloud Service

Descubra cómo diseñar y configurar tablas en Oracle NoSQL Database Cloud Service.

En este artículo se incluyen los siguientes temas:

Campos de tabla

Descubra cómo diseñar y configurar datos mediante campos de tabla.

Una aplicación debe utilizar tablas sin esquema, donde una fila consta de campos clave y un solo campo JSON. Una tabla sin esquema ofrece flexibilidad en cuanto a los elementos que se pueden almacenar en una fila.

De manera alternativa, la aplicación puede utilizar tablas de esquema fijo, donde todos los campos de la tabla se definen con un tipo concreto.

Las tablas de esquema fijo con datos tipificados son más seguras de usar en términos de aplicación y eficacia del almacenamiento. Aunque es posible modificar el esquema de tablas de esquema fijo, la estructura de la tabla no se puede cambiar fácilmente. Una tabla sin esquema es flexible y la estructura de la tabla se puede modificar fácilmente.

Por último, una aplicación también puede utilizar un enfoque de modelo de datos híbrido en el que una tabla puede tener campos de datos JSON y datos tipificados.

Los siguientes ejemplos muestran cómo diseñar y configurar datos para los tres enfoques.

Ejemplo 1: Diseño de una tabla sin esquema

Dispone de varias opciones para almacenar información sobre los patrones de exploración en la tabla. Una opción es definir una tabla que use el ID de cookie como clave y mantenga los datos de segmentación de público como un solo campo JSON.

// schema less, data is stored in a JSON field
CREATE TABLE audience_info (
       cookie_id LONG,
       audience_data JSON,
       PRIMARY KEY(cookie_id))

En este caso, la tabla audience_info puede contener un objeto JSON como:

{
  "cookie_id": "",
  "audience_data": {
    "ipaddr" : "
10.0.00.xxx",
    "audience_segment: {
       "sports_lover" : "2018-11-30",
       "book_reader" :  "2018-12-01"
    }
  }
}

La aplicación tendrá un campo clave y un campo de datos para esta tabla. Tiene flexibilidad a la hora de seleccionar la información que desea almacenar en el campo audience_data. Por lo tanto, puede cambiar fácilmente los tipos de información disponibles.

Ejemplo 2: Diseño de una tabla de esquema fijo

Puede almacenar información sobre los patrones de exploración creando la tabla con campos declarados más explícitamente:

// fixed schema, data is stored in typed fields.
CREATE TABLE audience_info(
       cookie_id LONG,
       ipaddr STRING,
       audience_segment RECORD(sports_lover TIMESTAMP(9),
                               book_reader TIMESTAMP(9)),
       PRIMARY KEY(cookie_id))

En este ejemplo, la tabla tiene un campo de clave y dos campos de datos. Los datos son más compactos y puede asegurarse de que todos los campos de datos son precisos.

Ejemplo 3: Diseño de una tabla híbrida

Puede almacenar información sobre los patrones de exploración con los campos de datos tipificados y JSON de la tabla.

// mixed, data is stored in both typed and JSON fields.
CREATE TABLE audience_info (
       cookie_id LONG,
       ipaddr STRING,
       audience_segment JSON,
       PRIMARY KEY(cookie_id))

Claves primarias y claves de partición horizontal

Conozca la finalidad de las claves primarias y las claves de partición al diseñar la aplicación.

Las claves primarias y las claves de partición son elementos importantes del esquema y ayudan a acceder y distribuir los datos de forma eficiente. Las claves primarias y las claves de partición horizontal solo se crean cuando se crea una tabla. Permanecen en el sitio durante toda la vida útil de la tabla y no se pueden modificar ni borrar.

Claves Primarias

Debe designar una o más columnas de clave primaria al crear la tabla. Una clave primaria identifica de forma única todas las filas de la tabla. En el uso de operaciones sencillas de CRUD, Oracle NoSQL Database Cloud Service utiliza la clave primaria para recuperar una fila específica para leer o modificar. Imagine, por ejemplo, que una tabla tiene los siguientes campos:

productName
productType
productLine

Ya sabe que el nombre del producto es importante y único para cada fila, así que defina productName como clave primaria. A continuación, recupera las filas de interés basándose en productName. En ese caso, utilice una sentencia como esta para definir la tabla.

/* Create a new table called users. */
CREATE TABLE if not exists myProducts
(
  productName STRING,
  productType STRING,
  productLine INTEGER,
  PRIMARY KEY (productName)
)"

Claves de partición

El objetivo principal de las claves a partir de particiones horizontales es distribuir los datos en el cluster de Oracle NoSQL Database Cloud Service para una mayor eficacia y ubicar localmente los registros que comparten la clave a partir de particiones horizontales para facilitar el acceso. Los registros que comparten la clave de partición horizontal se almacenan en la misma ubicación física y se puede acceder a ella de manera atómica y eficiente.

El diseño de las claves principal y partición tiene implicaciones sobre la ampliación y la obtención del rendimiento aprovisionado. Por ejemplo, cuando los registros comparten claves de partición horizontal, puede suprimir varias filas de la tabla en una operación atómica o recuperar un subconjunto de filas de la tabla en una sola operación atómica. Además de habilitar la escalabilidad, las claves de partición bien diseñadas pueden mejorar el rendimiento, ya que necesitan menos ciclos para colocar los datos u obtener datos de una sola partición.

Por ejemplo, suponga que designa tres campos de clave primaria:

PRIMARY KEY (productName, productType, productLine)

Puesto que sabe que su aplicación realiza consultas frecuentes con las columnas productName y productType, es conveniente especificar dichos campos como claves de partición horizontales. La designación de clave de partición horizontal garantiza que todas las filas de estas dos columnas se almacenen en la misma partición horizontal. Si estos dos campos no son claves a partir de particiones horizontales, las columnas consultadas con más frecuencia se pueden almacenar en cualquier partición. Por tanto, para localizar todas las filas de ambos campos, es necesario explorar todo el almacenamiento de datos, en lugar de una partición horizontal.

Las claves de partición horizontal designan almacenamiento en la misma partición horizontal para facilitar la consulta eficaz de valores de clave. Sin embargo, como desea que los datos se distribuyan entre las particiones horizontales para obtener un mejor rendimiento, debe evitar claves de partición horizontal que tengan pocos valores únicos.

Nota: Si no Designa Claves de Partición Horizontales al Crear una Tabla, Oracle NoSQL Database Cloud Service utiliza las claves primarias para la organización de particiones horizontales.

Factores importantes que se deben tener en cuenta al seleccionar una clave de partición horizontal

Cardinalidad: los campos de cardinalidad baja, como un país de inicio de un usuario, agrupan registros en unas pocas particiones horizontales. A su vez, dichas particiones horizontales necesitan un reequilibrado frecuente de los datos, lo cual aumenta el riesgo de problemas en las particiones horizontales más usadas. En su lugar, cada clave de partición horizontal debe tener una cardinalidad alta, donde la clave de partición horizontal puede expresar un segmento par de registros en el conjunto de datos. Por ejemplo, los números de identidad como customerID, userID o productID son buenos candidatos para una clave de partición horizontal.
Atomicidad: solo pueden participar en una transacción los objetos que comparten la clave del fragmento. Si necesita transacciones ACID que abarquen varios registros, seleccione solo una clave de partición horizontal que permita cumplir dicho requisito.

¿Cuáles son las mejores prácticas que se deben seguir?

Distribución Uniforme de Claves de Partición: Cuando las Claves de Partición Horizontal se Distribuyen de manera uniforme, ninguna Partición Horizontal Limita la Capacidad del Sistema.
Aislamiento de Consultas: las consultas se deben dirigir a una partición horizontal específica para maximizar la eficiencia y el rendimiento. Si las consultas no se aíslan a una sola partición horizontal, la consulta se aplica a todas las particiones horizontales, lo cual resulta menos eficaz y aumenta la latencia de la consulta.

Consulte Crear tablas para aprender a asignar claves primarias y las de particiones horizontales utilizando el objeto TableRequest.

Tiempo de Actividad

Aprenda a especificar los tiempos de vencimiento de las tablas y las filas mediante la función de tiempo de actividad (TTL).

Muchas aplicaciones gestionan datos con una vida útil limitada. El tiempo de actividad (TTL) es un mecanismo que permite definir un periodo en las filas de la tabla, tras el cual las filas caducan automáticamente y ya no están disponibles. Se trata de la cantidad de tiempo que los datos pueden permanecer en Oracle NoSQL Database Cloud Service. Los datos que alcanzan el tiempo de vencimiento ya no se pueden recuperar y no aparecen en ninguna estadística de almacenamiento.

Por defecto, todas las tablas creadas tienen un valor de TTL igual a cero, lo que indica que no existe tiempo de vencimiento. Puede declarar un valor de TTL al crear una tabla indicando un número seguido de HOURS o DAYS. Las filas de tabla heredan el valor de TTL de la tablas en las que residen, a menos que se defina explícitamente un valor de TTL para la tabla. La definición del valor TTL de una fila sustituye el valor TTL de la tabla. Si cambia el valor TTL de las tablas después de que las filas tengan un valores de TTL, el valor TTL de las filas se mantiene.

Puede actualizar el valor de TTL de una fila de la tabla en cualquier momento antes de que la fila alcance el tiempo de vencimiento. Los datos que hayan vencido no serán accesibles. Por lo tanto, el uso de valores de TTL es más eficaz que suprimir las filas manualmente, ya que se evita la sobrecarga de escritura de una entrada del log de la base de datos para la supresión de datos. Los datos que hayan vencido se borran del disco después de la fecha de vencimiento.

Ciclos de vida y estados de tabla

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 con el 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.

A continuación, se muestra la Descripción de table-state.png

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

Estado de la Tabla	Descripción
`CREATING`	La tabla está en proceso de creación. No está listo para su uso.
`UPDATING`	La actualización de la tabla está en curso. No se pueden realizar más modificaciones en la tabla mientras se encuentra en este estado. Una tabla está en el estado `UPDATING` cuando: Se están cambiando los límites de la tabla Evoluciona el esquema de la tabla. Se agrega o borra 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á borrando 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. Nota: Una vez borrada, se puede volver a crear la tabla con el mismo nombre.

Jerarquías de Tabla

Oracle NoSQL Database permite que las tablas existan en una relación principal-secundario. Esto se conoce como jerarquías de tablas.

La sentencia create table permite crear una tabla como secundaria de otra tabla, que luego se convierte en la principal de la nueva tabla. Para ello, se utiliza un nombre compuesto (name_path) para la tabla secundaria. Un nombre compuesto consiste en un número N (N > 1) de identificadores separados por puntos. El último identificador es el nombre local de la tabla secundaria y los primeros identificadores N-1 apuntan al nombre del principal.

Características de las tablas padre-hijo:

Una tabla secundaria hereda las columnas de clave primaria de su tabla principal.
Todas las tablas de la jerarquía tienen las mismas columnas de clave de partición horizontal, que se especifican en la sentencia create table de la tabla raíz.
Una tabla principal no se puede borrar antes de que se borren sus secundarios.
Una restricción de integridad referencial no se aplica en una tabla principal-secundario.

Debe considerar el uso de tablas secundarias cuando sea necesaria alguna forma de normalización de datos. Las tablas secundarias también pueden ser una buena opción al modelar relaciones de 1 a N y también proporcionar semántica de transacciones ACID al escribir varios registros en una jerarquía principal-secundario.