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

Campos de tabla

Descubra cómo diseño y configuración de datos mediante campos de tabla.

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

Asimismo, 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 se puede 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

Tiene 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

Para almacenar información sobre los patrones de exploración, cree 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))

Clave Primaria y Clave de Partición

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. Se mantienen durante toda la vida útil de la tabla y no se pueden modificar ni borrar.

Claves primarias

Debe asignar 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 caso de operaciones sencillas de creación, lectura, actualización y supresión, Oracle NoSQL Database Cloud Service utiliza la clave primaria para recuperar una fila específica para leer o modificar. Tenga en cuenta, 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 horizontal

El objetivo principal de las claves 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 de particiones horizontales para facilitar la referencia y 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 forma atómica y eficiente.

El diseño de la clave primaria y de partición tiene implicaciones sobre la ampliación y el logro del rendimiento global 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 subjuego 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 la aplicación realiza consultas frecuentes con las columnas productName y productType, sería conveniente especificar dichos campos como claves de partición horizontal. 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 de partición horizontal, las columnas consultadas con más frecuencia se pueden almacenar en cualquier partición horizontal. 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 fragmentos para obtener un mejor rendimiento, debe evitar claves de partición horizontal que tengan pocos valores únicos.

Note:

Si no designa claves de partición horizontal 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 considerar al seleccionar una clave de partición horizontal

Cardinalidad: los campos de cardinalidad baja, como el país de origen de un usuario, agrupan los registros en unas pocas fragmentos. A su vez, dichas particiones horizontales necesitan un rebalanceo frecuente de los datos, lo que aumenta la probabilidad 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 los objetos que comparten la clave de partición horizontal pueden participar en una transacción. Si necesita transacciones ACID que cubran varios registros, seleccione 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 particiones horizontales: cuando las claves de particiones horizontales 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 aislan a una sola partición horizontal, la consulta se aplica a todas las particiones horizontales, lo cual es menos eficaz y aumenta la latencia de la consulta.

Consulte Creación de tablas para aprender a asignar claves primarias y de particiones horizontales utilizando el objeto TableRequest.

Tiempo de Actividad

Especifique 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, después del cual las filas caducan automáticamente y ya no están disponibles. Es 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 la tabla heredan el valor de TTL de la tabla en la que residen, a menos que se defina explícitamente un valor de TTL para las filas de la tabla. La definición de un valor de TTL de una fila sustituye el valor de TTL de la tabla. Si cambia el valor de TTL de la tabla y la fila tiene un valor de TTL establecido, prevalece el valor de la fila.

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 vencidos se borran del disco después de la fecha de vencimiento.

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.

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 tabla.

La sentencia create table permite crear una tabla como secundaria de otra tabla, que a continuación 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 consta de 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.
No se puede borrar una tabla principal antes de borrar sus secundarios.
Una restricción de integridad referencial no se aplica en una tabla principal-secundaria.

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