Moving from MySQL to Couchbase

Creo que es seguro asumir que cada desarrollador o administrador de sistemas ha tocado MySQL en algún momento. A menudo era el
rito de paso para cualquier nuevo desarrollador hace unos años, cuando florecieron lenguajes como PHP. Ahora puede que te encuentres en una situación en la que
las cosas han cambiado y ahora su base de datos puede necesitar un cambio. Más concretamente, un cambio a una base de datos NoSQL sin esquema.

A primera vista, si estás ojeando las diferencias, puede parecer una tarea aterradora. ¿Qué hago con todas mis tablas y
restricciones? ¿Cómo consulto mis datos? ¿Qué lenguajes de desarrollo puedo utilizar?

Vamos a ir más despacio y a recorrer un escenario en el que estás usando un RDBMS MySQL y te gustaría hacer la transición a Couchbase.

Principales diferencias entre MySQL y Couchbase

Viniendo de MySQL, 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 de una base de datos de documentos NoSQL como Couchbase.
En su lugar, trabajas con objetos JSON y matrices 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 simplificar, vamos a ceñirnos a un modelo de datos pequeño. Siempre se puede ajustar para dar cabida a un escenario más complejo. Nuestro modelo de datos
serán los siguientes:

cliente

id: numérico clave primaria
nombre: varchar
apellido: varchar

dirección_cliente

id: numérico clave primaria
ciudad: varchar
estado: varchar
zip: varchar
customer_id: clave externa numérica

Las dos tablas anteriores y sus columnas no son las más complejas, pero aún así demuestran ser relacionales a través de las tablas primaria y
relaciones de clave extranjera.

Opciones para un modelo de datos NoSQL

Los documentos NoSQL son un poco diferentes porque en este caso carecen de esquema. Esto significa que existen múltiples opciones a la hora de
se trata de modelar los datos que vimos para MySQL.

Documentos de referencia

Probablemente le resultará más familiar referirse a documentos en términos de datos relacionales. En un RDBMS como MySQL, se hace referencia a
a otras filas de datos mediante claves primarias y foráneas. No existe el concepto de clave primaria o foránea en NoSQL, pero eso no significa que no haya una clave primaria o foránea.
significa que no puedes montar el mismo tipo de relación.

Por ejemplo, tomemos los siguientes documentos NoSQL:

c::1


{
    "type": "customer",
    "first_name": "Nic",
    "last_name": "Raboy"
}

{

"tipo": "cliente",

"nombre": "Nic",

"apellido": "Raboy"

}

ca::1


{
    "type": "customer_address",
    "city": "San Francisco",
    "state": "CA",
    "zip": "94101",
    "customer_id": "c::1"
}

{

"tipo": "dirección_cliente",

"ciudad": "San Francisco",

"estado": "CA",

"zip": "94101",

"customer_id": "c::1"

}

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
documento del cliente 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 un archivo
base de datos relacional. Por ejemplo, una fila de la base de datos cliente La tabla MySQL 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 MySQL. Dado que JSON son datos complejos, podemos tener matrices dentro de nuestro
documentos. ¿Y si quisiéramos tener todos los datos juntos?


{
    "type": "customer",
    "first_name": "Nic",
    "last_name": "Raboy",
    "addresses": [
        {
            "city": "San Francisco",
            "state": "California"
        },
        {
            "city": "Mountain View",
            "state": "California"
        }
    ]
}

{

"tipo": "cliente",

"nombre": "Nic",

"apellido": "Raboy",

"direcciones": [

{

"ciudad": "San Francisco",

"estado": "California"

{

"ciudad": "Mountain View",

"estado": "California"

}

]

}

En el documento anterior estamos almacenando todas las direcciones de un cliente concreto en una matriz dentro del documento. Esto es en lugar de
creando un nuevo documento para cada dirección y haciendo referencia al documento del cliente.

Puede que se pregunte qué ocurre si tiene relaciones muy complejas en sus datos MySQL que, cuando se transponen a
Couchbase, daría lugar a que los mismos datos estuvieran incrustados en más de un documento 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? Conservar datos como historial_cliente juntos sin relaciones y se refieren a
otras que pueden cambiar con más frecuencia.

Diferencias de consulta entre MySQL y Couchbase

Couchbase N1QL vs MySQL SQL

MySQL, al igual que todas las plataformas de bases de datos relacionales, utiliza su propio estilo de SQL. Asumiendo que estamos usando el esquema definido anteriormente
para MySQL, podemos consultar los clientes y sus direcciones de la siguiente manera:


SELECT
    c.firstname, c.lastname, ca.city, ca.state
FROM customer_address ca
LEFT JOIN customer c ON ca.customer_id = c.id

SELECCIONE

c.nombre, c.apellido, ca.ciudad, ca.estado

DESDE dirección_cliente ca

IZQUIERDA ÚNASE A cliente c EN ca.customer_id = c.id

¿Y si te dijera que puedes hacer casi lo mismo con datos NoSQL de Couchbase? Toma la siguiente consulta Couchbase N1QL:


SELECT
    c.firstname, c.lastname, ca.city, ca.state
FROM `bucket-name` ca
LEFT JOIN `bucket-name` c ON KEYS ca.customer_id

SELECCIONE

c.nombre, c.apellido, ca.ciudad, ca.estado

DESDE `cubo-nombre` ca

IZQUIERDA ÚNASE A `cubo-nombre` c EN TECLAS ca.cliente_id

No es muy diferente, ¿verdad? Usted puede notar que estamos utilizando nombre-cubo dos veces. Esto se debe a que no hay
en NoSQL y todos los diferentes documentos y tipos de documentos existirán en el mismo bucket. La clave del documento es
valor al que nos unimos.

Ahora digamos que desea insertar nuevos datos en el MySQL cliente tabla. En MySQL, puede hacer algo como esto:


INSERT INTO customer (id, first_name, last_name)
VALUES (1, 'Arun', 'Gupta');

INSERTAR EN cliente (id, nombre, apellido)

VALORES (1, Arun, Gupta);

Si quieres insertar datos en Couchbase puedes hacer lo siguiente:


INSERT INTO `bucket-name` (KEY, VALUE)
VALUES (1, {"first_name": "Arun", "last_name": "Gupta"});

INSERTAR EN `cubo-nombre` (CLAVE, VALOR)

VALORES (1, {"nombre": "Arun", "apellido": "Gupta"});

Más información sobre Couchbase N1QL en aquí.

Diferencias de desarrollo entre MySQL y Couchbase

En mi anterior artículo sobre De Oracle a Couchbaseescribí sobre las diferencias de desarrollo desde la perspectiva de Java. Para
coherencia, usaré Java en los siguientes ejemplos. MySQL ciertamente no está restringido a Java y tampoco lo está Couchbase.

El controlador MySQL JDBC

En una aplicación Java, si quisieras conectarte a una base de datos MySQL utilizarías el controlador Java Database Connector (JDBC).
Con el controlador incluido en su proyecto, ya sea a través de herramientas como Maven o manualmente, puede cargarlo y empezar a consultar datos.

Un ejemplo podría ser el siguiente:


Class.forName("com.mysql.jdbc.Driver");
Properties info = new Properties();
info.put("user", "nraboy");
info.put("password", "password");
Connection connection = DriverManager.getConnection("jdbc:mysql://HOST:PORT/DATABASE", info);
Statement stmt = connection.getConnection().createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM customer");
while(rs.next()) {
    // rs.getString("first_name");
}
stmt.close();

Clase.forName("com.mysql.jdbc.Driver");

Propiedades información = nuevo Propiedades();

información.poner("usuario", "nraboy");

información.poner("contraseña", "contraseña");

Conexión conexión = DriverManager.getConnection("jdbc:mysql://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, debe utilizar el SDK Java de Couchbase en lugar de un controlador JDBC, aunque
existe 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:


CouchbaseCluster.create(HOST).openBucket(BUCKET, PASSWORD);
String query = "SELECT * FROM `bucket-name-here`";
N1qlQueryResult queryResult = bucket.query(query);
for (N1qlQueryRow row : queryResult) {
    // row.value().toMap();
}

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 usas MySQL tienes muchas herramientas que puedes usar. Por ejemplo, si desea ejecutar consultas contra la base de datos que
podría utilizar el MySQL CLI. Usted todavía tiene la posibilidad de utilizar herramientas comparables al hacer el cambio a Couchbase.
Si busca una herramienta de línea de comandos, puede utilizar CBQ para consultar sus datos. Si es un usuario avanzado de
MySQL Workbench, no te preocupes porque Couchbase tiene su Workbench de consulta como
de Servidor Couchbase 4.5.

Migración de datos

Cuando se trata de tus datos, puede que te estés preguntando cómo sacar tus datos de MySQL y meterlos en Couchbase lo más rápido posible.
Laurent Doguin escribió una excelente herramienta de migración para mover datos de MySQL a Couchbase.

Básicamente, lo que hace esta herramienta es conectarse a su base de datos MySQL a través de Java y el controlador JDBC. Cada fila de cada tabla se convertirá en un único documento JSON.

Aunque no habrá restricciones de base de datos en los nuevos documentos JSON, las claves seguirán existiendo y podrán consultarse a través de N1QL.

Conclusión

MySQL y Couchbase son dos tecnologías de bases de datos muy diferentes, pero la forma de utilizarlas no tiene por qué serlo. El modelo de datos relacional
puede conservarse hasta cierto punto en una base de datos de documentos NoSQL. Cualquier dato almacenado puede ser consultado en Couchbase de la misma forma que lo harías en una base de datos NoSQL.
en una base de datos MySQL mediante consultas SQL. La principal diferencia entre ambos es que no hay límites en cuanto a los datos que se pueden almacenar.
y cómo puedes almacenarlo.

Si es usuario de una base de datos Oracle, este post similar que escribí sobre pasar de Oracle a Couchbase.

Nic Raboy, Defensor del Desarrollador, Couchbase

3 Comentarios

NoSQL simplifica las operaciones de desarrollo de bases de datos febrero 24, 2017 a 10:17 pm

[...] Pasar de MySQL a Couchbase [...]

Inicia sesión para responder
Marcin Rosinski diciembre 16, 2017 a 4:56 am

Hola, ¿qué índice debería crearse para su consulta join del ejemplo anterior?

Inicia sesión para responder
1. Marcin diciembre 16, 2017 a 5:05 am
  
  OK, lo tengo, PRIMARY INDEX es necesario en este caso
  
  Inicia sesión para responder

Dejar una respuesta Cancelar respuesta

Lo siento, debes estar conectado para publicar un comentario.

Conéctese con su ID social

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Todos los mensajes

Pasar de MySQL a Couchbase