Aquí está la página de inicio de la serie: https://www.couchbase.com/blog/couchbase-oracle-developers-part-2-architecture/

Los DBA de Oracle trabajan con clusters, máquinas, sistemas de almacenamiento, discos, etc. Los desarrolladores de Oracle y sus aplicaciones trabajan con bases de datos, tablas, filas, columnas, particiones, usuarios, tipos de datos dentro del sistema de base de datos Oracle. Vamos a comparar y contrastar cómo se hace esto en Couchbase.

 

 

 

 

 

Tema Oracle Couchbase
Base de datos Base de datos Dentro de una instancia de Couchbase (nodo único o cluster multinodo), puedes crear uno o más buckets.  Desde la perspectiva del desarrollador, se crean buckets y se empieza a insertar JSON de varios tipos en los buckets.

CREAR:

Puedes crear un bucket a través de la consola web de Couchbase o a través de la API REST. En la consola web, proporcione la siguiente información.

 

 

 

 

 

 

 

 

 

 

El usuario proporciona lo siguiente:

Nombre de un cubo.

Ubicación de un almacén de datos existente. Couchbase crea un directorio con el nombre del bucket debajo del especificado directamente. En este caso, el directorio CUSTOMER se crea bajo : /my/data. Este directorio /my/data debe existir en cada nodo del cluster Couchbase con servicio de datos (clave-valor). Esto es fijo e inalterable.

Memoria utilizada en megabytes. Se trata de la cantidad fija de memoria utilizada para almacenar en caché los datos a medida que los insertas/cargas. Los datos reales en memoria dependen del patrón de acceso de tu aplicación. Se utilizan los algoritmos habituales LRU, MRU para determinar qué documentos se mantienen en memoria y cuáles se desalojan. Para más información sobre el desalojo de claves, consulte el enlace:

http://bit.ly/2ngKUZk

Tipo cubo

Couchbase: Base de datos JSON

Memcached: Memcache

Efímero: igual que Couchbase bucket, excepto que todos los datos e índices están sólo en memoria.

Réplica: Por defecto hay una copia de los datos en el cluster. Puede tener hasta tres copias de los datos dentro del clúster. En el Reglas del teorema CAP. Hay un montón de artículos y charlas sobre el teorema CAP y su aplicación a las bases de datos NoSQL en el dominio público.Couchbase Bucket es un sistema CP. Esto significa que Couchbase elige consistencia sobre disponibilidad (C sobre A). Soportar la tolerancia a la partición es un requisito para estos sistemas multi-nodo escalables.

Consulte la documentación de Couchbase para obtener información detallada sobre todos los parámetros y ejemplos.

http://bit.ly/2GrbMOw

Cuadro Cuadro Ahora mismo, Couchbase Bucket sirve para dos cosas propósitos.  

  1. Punto de control de acceso
  2. Contenedor para todos los documentos.

Como hemos comentado antes, puede haber hasta 10 buckets en un sistema Couchbase. En RDBMS, almacenas una fila que pertenece a un dominio en una única tabla.

En Couchbase, modelas tu documento para que contenga tantos datos sobre el objeto como sea posible. Por ejemplo, el objeto CLIENTE puede contener no sólo la información básica del cliente, sino también los pedidos del cliente, de modo que una sola operación GET puede obtener toda la información del cliente rápidamente.

 Ejemplo de documento INSERT mediante N1QL:

Tenga en cuenta que no había ninguna CREATE TABLE para CUSTOMER. Usted inserta simple y directamente el documento JSON en el bucket. Necesita un documento único para el bucket. Este único se modela en clave primaria para una tabla. Si tiene varias partes, sepárelas con un delimitador como un guión, un guión bajo o un punto.

Ahora tiene el documento CLIENTE en el bucket denominado comercio electrónico.

Ahora, quieres otro tipo de documento, digamos SOCIO.  

Puede simplemente crear un bucket separado llamado PARTNER. O puede insertar los documentos PARTNER en el mismo BUCKET. Insertar en un bucket separado es sencillo. En Couchbase, es una práctica común y recomendada usar el mismo bucket para almacenar documentos de múltiples tipos para una aplicación. Esto tiene dos ventajas.

  1. Couchbase puede crear hasta 10 buckets en un cluster. Es habitual tener muchos tipos de documentos. No querrás quedarte sin buckets.
  2. Tener un único cubo facilita la gestión. Es como tener una única base de datos frente a varias.

 

Fila Fila  Documento JSON, con su documentkey.

Consideraciones para el diseño de las claves de los documentos: http://bit.ly/2GnRwwV

Columna Columna JSON se compone de pares clave-valor.

Ejemplo: {"fullname": "Joe Smith"}

{"name: {"fname": "Joe", "lname": "Smith"}

{"hobbies": ["lego", "robótica", "esquí"]}

En estos documentos, "nombre" es una clave, también conocida como atributo. Su valor puede ser escalar (fullname) o un objeto (name) o array (hobbies).

En Oracle, al crear la tabla, se especifican los nombres de las columnas y sus tipos de datos.

En Couchbase, basta con insertar documentos JSON. Cada documento autodescribe el atributo (columna) nombres. Esto le da flexibilidad para hacer evolucionar el esquema sin tener que bloquear la tabla. Los tipos de datos se interpretan simplemente a partir del propio valor: Cadena, número, nulo, verdadero, falso, objeto o una matriz.

Vistas Las vistas pueden crearse con la sentencia CREATE VIEW. Una vez creadas, son simplemente relaciones que pueden utilizarse en cualquier lugar donde pueda utilizarse una tabla (conjunto de relaciones). Existen algunos requisitos adicionales para las actualizaciones de vistas (por ejemplo, en lugar de desencadenadores para insertar, actualizaciones en vistas complejas). Couchbase no tiene vistas dinámicas basadas en SQL como Oracle. Couchbase tiene una tecnología que llamamos, "Couchbase Views", basada en map reduce framework. Estos son similares a las vistas materializadas y no la vista SQL y no se puede utilizar con N1QL.
Vistas materializadas (también conocidas como tablas de consulta materializadas) Vistas materializadas  Couchbase VIEW proporciona un marco map-reduce flexible para que puedas crear pre-agregaciones, índices, cualquier otra cosa que quieras crear. Más información en: http://bit.ly/2EhIFfF
Secuencias Secuencias No disponible
Disparadores Disparadores Los activadores no están disponibles.

Los ajustes de caducidad (TTL: time to live) permiten activar automáticamente la eliminación de un documento tras un periodo determinado. http://bit.ly/2DFe7U2 

Restricciones Restricciones: clave primaria, unique, Check, referencial, not null, Couchbase requiere e impone una restricción única en la clave del documento dentro de un bucket. Los documentos pueden tener referencia a la clave de otro documento. Es simplemente almacenar los datos y se puede utilizar en operaciones JOIN. La referencia en sí no se comprueba ni se aplica.
Índices Índices  Índice. Más detalles en la sección Índice. De momento, puede ver el blog detallado: http://bit.ly/2DI1nAa

Autor

Publicado por Keshav Murthy

Keshav Murthy es Vicepresidente de Couchbase R&D. Anteriormente, estuvo en MapR, IBM, Informix, Sybase, con más de 20 años de experiencia en diseño y desarrollo de bases de datos. Dirigió el equipo de I+D de SQL y NoSQL en IBM Informix. Ha recibido dos premios President's Club en Couchbase y dos premios Outstanding Technical Achievement en IBM. Keshav es licenciado en Informática e Ingeniería por la Universidad de Mysore (India), es titular de diez patentes estadounidenses y tiene tres pendientes.

Dejar una respuesta