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

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 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. 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 de partición horizontal 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 partición horizontal 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 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 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.

Factores importantes que se deben tener en cuenta 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 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 los objetos que comparten la clave de partición horizontal pueden participar en una transacción. 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 horizontal: 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 Creación de tablas e índices para aprender a asignar claves primarias y de particiones horizontales utilizando el objeto TableRequest.