Oracle fue la primera base de datos con la que desarrollé, así que sé que pensar en cambiar a algo como NoSQL y dejar atrás el modelo relacional puede parecer algo aterrador. La cosa es que realmente no daba miedo cuando finalmente opté por hacer el cambio al modelo de documentos NoSQL que ofrece Couchbase. Esto se debe a que, a diferencia de otras bases de datos NoSQL, Couchbase ofrece un lenguaje similar a SQL que resultaría muy familiar a un usuario de RDBMS.
Para hacer la transición más fácil, vamos a recorrer un escenario en el que estás usando un RDBMS de Oracle y te gustaría hacer la transición a Couchbase.
Principales diferencias entre Oracle y Couchbase
Viniendo de Oracle, supongo que ya sabes que es una base de datos relacional que consta de tablas, filas y columnas. Bastante estándar cuando se trata de cualquier base de datos relacional. Este no es el caso con una base de datos de documentos NoSQL como Couchbase. En su lugar estás trabajando con objetos JSON y arrays que no tienen estructura y prácticamente ninguna limitación.
Aunque el modelado de datos es, en mi opinión, la mayor diferencia, no es la única. Sin embargo, empecemos por ahí.
El modelo de datos de las bases de datos relacionales
Para mantener las cosas simples y fáciles de seguir en este artículo, vamos a suponer que tenemos las siguientes tablas:
- cliente
- id: numérico clave primaria
- nombre: varchar
- apellido: varchar
- historial_cliente
- id: numérico clave primaria
- product_id: clave externa numérica
- cantidad: numérico
- dirección_cliente
- id: numérico clave primaria
- customer_id: clave externa numérica
- ciudad: varchar
- estado: varchar
- producto
- id: numérico clave primaria
- nombre: varchar
- descripción: varchar
- reseña_del_producto
- id: numérico clave primaria
- product_id: clave externa numérica
- customer_id: clave externa numérica
- revisión: varchar
Las tablas y columnas anteriores no son las más complejas, pero demuestran el modelo relacional. Todas ellas están conectadas mediante el uso de relaciones de clave primaria y foránea.
Opciones para un modelo de datos NoSQL
Dado que NoSQL carece de esquema, existen múltiples formas de modelar los datos que acabamos de ver en Oracle.
Documentos de referencia
La referencia a documentos probablemente le resulte más familiar en términos de datos relacionales. En un RDBMS como Oracle, se hace referencia a otras filas de datos a través de claves primarias y externas. En NoSQL no existe el concepto de clave primaria o foránea, pero eso no significa que no se pueda establecer el mismo tipo de relación.
Por ejemplo, tomemos los siguientes documentos NoSQL:
c::1
|
1 2 3 4 5 6 7 |
{ "tipo": "cliente", "nombre": "Nic", "apellido": "Raboy" } |
ca:1
|
1 2 3 4 5 6 7 8 |
{ "tipo": "dirección_cliente", "customer_id": "c::1", "ciudad": "San Francisco", "estado": "California" } |
Supongamos que los documentos anteriores se modelan de forma similar a su equivalente RDBMS. c::1 es sólo un valor id que me inventé para el cliente documento y ca:1 es un id que inventé para el dirección_cliente documento.
Aunque todavía no los vamos a consultar, podemos pensar que cada uno de estos documentos equivale a una fila de una base de datos relacional. Por ejemplo, una fila del documento cliente La tabla Oracle sería un documento en Couchbase.
Muy similares, ¿correcto?
Incrustación de documentos
Aquí es donde las cosas pueden llegar a ser muy diferentes viniendo de Oracle. Dado que JSON son datos complejos, podemos tener arrays dentro de nuestros documentos. Entonces, ¿qué pasa si queremos mantener todos los datos juntos?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "tipo": "cliente", "nombre": "Nic", "apellido": "Raboy", "direcciones": [ { "ciudad": "San Francisco", "estado": "California" }, { "ciudad": "Mountain View", "estado": "California" } ] } |
¿Qué le parece? Con lo anterior, en lugar de una dirección por documento, ahora estamos almacenando todas las direcciones de cualquier cliente en particular, con los datos del cliente.
Puede que te estés preguntando qué ocurre si tienes relaciones muy complejas en tus datos de Oracle que, al transponerlas a Couchbase, harían que los mismos datos se incrustaran en más de un documento de Couchbase. Esto podría ocurrir, pero no es algo malo. No necesitas datos normalizados en una base de datos NoSQL como Couchbase. Sin embargo, si estás realmente preocupado, ¿por qué no mezclar ambos enfoques? Mantén datos como historial_cliente juntos sin relaciones y se refieren a otros que pueden cambiar con más frecuencia.
Diferencias de consulta entre Oracle y Couchbase
Oracle SQL frente a Couchbase N1QL
No es ningún secreto que Oracle utiliza su propio estilo de SQL tradicional para consultar datos en la base de datos, pero es SQL. Por ejemplo, si quisiéramos obtener todas las reseñas de productos y expandir las tablas relacionales en torno a ellas, haríamos una consulta como ésta:
|
1 2 3 4 5 6 7 |
SELECCIONE c.nombre, c.apellido, p.nombre, r.revise DESDE revise r ÚNASE A cliente c EN r.customer_id = c.id ÚNASE A producto p EN r.producto_id = p.id |
¿Y si te dijera que puedes hacer casi lo mismo con datos NoSQL de Couchbase? Toma la siguiente consulta Couchbase N1QL:
|
1 2 3 4 5 6 7 |
SELECCIONE c.nombre, c.apellido, p.nombre, r.revise DESDE `cubo-nombre` r ÚNASE A `cubo-nombre` c EN TECLAS r.customer_id ÚNASE A `cubo-nombre` p EN TECLAS r.producto_id |
No es muy diferente, ¿verdad? Usted puede notar que estamos utilizando nombre-cubo tres veces. Esto es porque no hay tablas en NoSQL y todos los diferentes documentos y tipos de documentos existirán en el mismo cubo. La clave del documento es el valor sobre el que nos unimos.
Tal vez desee insertar nuevos datos en Oracle cliente tabla. En Oracle, podría hacer algo como esto:
|
1 2 3 4 |
INSERTAR EN cliente (id, nombre, apellido) VALORES (1, Arun, Gupta); |
Si quieres insertar datos en Couchbase puedes hacer lo siguiente:
|
1 2 3 4 |
INSERTAR EN `cubo-nombre` (CLAVE, VALOR) VALORES (1, {"nombre": "Arun", "apellido": "Gupta"}); |
Diferencias de desarrollo entre Oracle y Couchbase
Desde la perspectiva del desarrollador, muchos de los que utilizan Oracle como base de datos tienden a utilizar Java. Oracle no se limita sólo a Java, pero como Java es Oracle, a menudo tiene sentido. Por eso, los próximos ejemplos se basarán específicamente en Java.
El controlador JDBC de Oracle
En una aplicación Java, si quisieras conectarte a una base de datos Oracle utilizarías el controlador Java Database Connector (JDBC). Con el controlador incluido en tu proyecto, ya sea a través de herramientas como Maven o manualmente, puedes cargarlo y empezar a consultar datos.
Un ejemplo podría ser el siguiente:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Clase.forName("oracle.jdbc.driver.OracleDriver"); Propiedades información = nuevo Propiedades(); información.poner("usuario", "nraboy"); información.poner("contraseña", "contraseña"); Conexión conexión = DriverManager.getConnection("jdbc:oracle:thin:@//HOST:PORT/DATABASE", información); Declaración stmt = conexión.getConnection().createStatement(); ResultSet rs = stmt.executeQuery("SELECT * FROM cliente"); mientras que(rs.siguiente()) { // rs.getString("nombre"); } stmt.cerrar(); |
El SDK Java de Couchbase
Para conectarse a Couchbase a través de una aplicación Java se utilizaría el SDK Java de Couchbase en lugar de un driver JDBC, aunque exista uno. La razón por la que usaríamos el SDK es porque las cosas se vuelven increíblemente fáciles con él.
Por ejemplo, con el SDK de Couchbase, el mismo tipo de operación que Oracle podría tener el siguiente aspecto:
|
1 2 3 4 5 6 7 8 |
CouchbaseCluster.crear(ANFITRIÓN).openBucket(CUBO, CONTRASEÑA); Cadena consulta = "SELECT * FROM `bucket-name-here`"; N1qlQueryResultado queryResult = cubo.consulta(consulta); para (N1qlQueryRow fila : queryResult) { // fila.valor().toMap(); } |
Lo anterior asume, por supuesto, que descargaste el SDK Java de Couchbase o usaste Maven para obtenerlo.
Diferencias entre herramientas
Cuando se utiliza Oracle hay muchas herramientas que se pueden utilizar. Por ejemplo, si desea ejecutar consultas en la base de datos, puede utilizar la herramienta de línea de comandos SQLPlus. Todavía tienes la posibilidad de usar herramientas comparables al hacer el cambio a Couchbase. Si buscas una herramienta de línea de comandos, puedes usar CBQ para consultar tus datos. Si eres un usuario avanzado de Oracle Desarrollador SQLno te preocupes porque Couchbase tiene su Workbench de consulta en marcha.
Herramientas de migración de datos
Cuando se trata de tus datos, puede que te estés preguntando cómo puedes sacar tus datos de Oracle y meterlos en Couchbase lo antes posible. Manuel Hurtado escribió un excelente artículo para trasladar datos de Oracle a Couchbase.
En resumen, el artículo de Manuel explica cómo utilizar una utilidad Java llamada oracle2couchbase. Esta herramienta exportará filas de una tabla a documentos JSON.
Conclusión
Aunque Oracle y Couchbase son dos plataformas de bases de datos muy diferentes, hay suficientes similitudes como para que el cambio no sea tan difícil. El modelo de datos relacional todavía puede ser preservado hasta cierto punto usando documentos referidos y estos documentos todavía pueden ser consultados usando un lenguaje similar a SQL lo suficientemente similar a Oracle SQL que te haría sentir como en casa.
Si eres usuario de Oracle, no debes descartar Couchbase. La forma en que existen los datos ahora es diferente a la de hace veinte años. Tener la flexibilidad de NoSQL es genial para el futuro.
[...] Pasar de la base de datos Oracle a Couchbase [...]