Cómo pasar de MySQL a Couchbase Server 2.0: Parte 1

Si tienes una base de datos construida usando MySQL, puede que te estés preguntando si, y lo que es más importante, cómo, esa base de datos (y tu aplicación) puede ser trasladada a Couchbase. El mayor escollo no son los aspectos técnicos de la creación de Couchbase o el almacenamiento de tu información (aunque son importantes), sino que se trata de ver tus datos de una manera diferente, y luego saber cómo eso cambia el funcionamiento de tu aplicación.

Vamos a empezar por ver cómo puedes convertir tu estructura de base de datos MySQL en Couchbase Server, y cómo la consulta de tu base de datos en Couchbase Server difiere de los métodos utilizados en MySQL.

Piense primero en la estructura de datos

MySQL (y otras bases de datos SQL y basadas en tablas) te obligan a pensar en tus datos en términos de tablas. Todos sus datos son una tabla, y cuando se almacenan estructuras complejas, un dato individual puede estar dividido en una o más tablas. Para algunas aplicaciones y tipos de datos, ésta es una forma perfectamente lógica y razonable de abordar y almacenar los datos. Pero para algunas aplicaciones, la estructura de tablas no se ajusta muy bien a los datos que se quieren almacenar.

Tomemos un ejemplo típico: una base de datos de recetas. Esto es algo que conozco bien, ya que Cheffy.com está construido sobre MySQL. La estructura básica de las tablas es una tabla central, llamada receta, que contiene el nombre de la receta, el subtítulo, la descripción y las raciones. Otra información relevante sobre la receta, como la lista de ingredientes, los pasos del método, los metadatos y las palabras clave, se almacena en otras tablas, vinculadas a la receta original mediante un ID de receta único. Puede ver esto, muy básicamente, en la siguiente figura.

???

Esta estructura tiene algunas ventajas potenciales: algunas operaciones, por ejemplo, pueden ser muy sencillas y fáciles. Por ejemplo, ¿desea encontrar todas las recetas que contienen el ingrediente "zanahoria"? Puede realizar una consulta en la tabla de ingredientes buscando "zanahoria" y, a partir de ahí, obtener una lista de recetas coincidentes. Mediante el uso de uniones, puede obtener una lista de las recetas, su título y otra información de la tabla de recetas, buscando en la tabla de ingredientes, utilizando la unión para conectar el ID de la receta en la tabla de ingredientes con el ID de la receta en el título de la receta.

???

Mientras que este tipo de búsqueda es fácil, recopilar toda la información sobre una receta, por ejemplo cuando se quiere mostrar la receta al usuario, puede ser realmente complicado. Podrías hacerlo con una sola consulta, pero a veces puede ser más fácil hacerlo con varias consultas, una para obtener los datos de la receta, otra para los ingredientes, otra para los metadatos, etc. Dentro de la capa de aplicación, esto se hace automáticamente para construir un objeto, que luego se utiliza como base para mostrar la receta al usuario de una manera formateada.

Para muchos usuarios y aplicaciones, o bien se construye una capa especial para hacer esto, o bien se utiliza uno de los muchos sistemas de mapeo objeto-relacional para mapear los datos desde la estructura tabular subyacente, al objeto de nivel superior con el que la aplicación (y el usuario) están familiarizados. Las recetas son un ejemplo, pero se extiende a una amplia variedad de otras aplicaciones, como la facturación (factura, proveedor, destino, líneas de factura) y las entradas de blog (contenido de la entrada, palabras clave, creador, comentarios).

Estas soluciones basadas en tablas no son intrínsecamente malas, pero en este tipo de situaciones, la información clave se almacena en varias tablas, lo que implica mantenerlas sincronizadas entre sí. Por ejemplo, ¿qué ocurre cuando se elimina un registro? Hay que borrar todos los demás registros que puedan estar vinculados al original, ya sea manualmente o mediante borrados en cascada.) Del mismo modo, cuando se trata de cargar la información sobre una receta, acabas ejecutando entre 5 y 10 consultas de la información juntas.

Couchbase adopta un enfoque diferente. En lugar de múltiples tablas en las que puedes almacenar diferentes piezas de información, en Couchbase almacenas una única estructura (en formato JavaScript Object Notation JSON). El formato JSON permite una estructura compleja de campos, arrays, objetos y tipos escalares, que pueden ser combinados juntos en un registro completo. Esto significa que ahora puede representar su antigua entidad de múltiples tablas (receta, entrada de blog) como un único "documento".

Ahora todo lo que tiene que ver con su receta está en un solo lugar, y podemos cargar la receta en una sola operación desde su base de datos Couchbase.

No hay estructura o definición para el contenido; cualquier documento en una base de datos Couchbase puede contener cualquier cosa y cualquier estructura. Sin embargo, puedes aplicar una rutina de validación que compruebe que la estructura del documento suministrado a la base de datos. La validación puede cubrir tanto los campos como su contenido.

Además, hay que tener en cuenta que, al no existir una estructura estricta, hay más flexibilidad a la hora de almacenar la información. Añadir una nueva sección al documento de la receta que contenga información sobre quién suministró la receta a la base de datos es un caso de ampliación de la estructura del documento.

Tampoco existe la noción de tablas múltiples. Sólo existe la base de datos y los documentos que contiene. Si desea admitir distintos tipos de información dentro de la misma base de datos, puede añadir un campo al documento. Por ejemplo, para identificar una receta se podría hacer:

La identificación del tipo de registro puede utilizarse en otras áreas del sistema de base de datos para ayudarle a reconocer (y seleccionar) los datos que está cargando.

Si todo es un documento, ¿cómo obtengo una lista de registros?

En la primera sección hablé de cómo con MySQL se puede construir una simple sentencia SQL para obtener una lista de recetas que incluyan zanahorias. En MySQL esto funciona buscando valores en la tabla de ingredientes para encontrar los IDs de las recetas, y luego usar un join para obtener los títulos de las recetas de la tabla de recetas. Para aumentar la velocidad, normalmente se utilizaría un índice para mejorar los tiempos de respuesta de la consulta y evitar tener que buscar individualmente en cada registro.

En Couchbase todo es un documento, y no hay ningún método incorporado para buscar en el campo de una tabla, ya que tampoco hay campos ni tablas. Como no hay una estructura rígida (y no hay forma de que el motor de base de datos identifique los campos en un documento de forma libre), ¿cómo hacemos cualquier operación que normalmente opera sobre una lista (o tabla)? Todo, desde un simple 'listar todas las recetas' hasta 'encontrar todas las recetas con un ingrediente de zanahoria', depende del uso de una lista en algún lugar.

Couchbase soporta una construcción llamada vista. Las vistas son similares en principio a las vistas dentro de MySQL, excepto que en Couchbase, las vistas son la única manera de obtener listas de documentos de tu base de datos, no un método de obtener una alternativa .

De hecho, un punto de vista define tres cosas:

• La estructura de la información incluida en la vista. Puede pensar en esto como la definición de la estructura de la tabla, al igual que definiría una tabla dentro de MySQL.
• Los campos o información en los que se puede buscar. Una vista produce dos elementos, una clave y un valor. Las claves constituyen el método mediante el cual se puede buscar, o más concretamente, seleccionar, el contenido de la base de datos que se desee.
• Un índice sobre la estructura y las claves. El índice se utiliza para mejorar la búsqueda de los datos notificados en la vista.

Las vistas se definen dentro de un documento de diseño, en JavaScript, mediante una función que acepta un documento. Cuando se construye la vista, cada documento de la base de datos se suministra a la vista, y la vista entonces emite la información que usted quiere que aparezca en la salida. No te preocupes por el JavaScript, el JavaScript se ejecuta en el servidor, no en el cliente.

Así que, volviendo a MySQL por un momento, una consulta (sin una cláusula WHERE), selecciona los campos a devolver la salida de la consulta, y construye una lista de filas coincidentes en la salida. Así, mirando a una sentencia SQL:

Cuando se ejecuta una consulta en MySQL, el servidor MySQL toma la información en la tabla o tablas, y luego construye la lista de registros (y los campos correspondientes) para ser devueltos, así:

En Couchbase, las vistas construyen una lista de registros a partir de la información individual de los documentos, creando un índice como efecto secundario de ese proceso. El resultado es una lista de todos los documentos generados por la vista.

???

En MySQL, cuando se ejecuta una consulta con una cláusula WHERE, el índice (con suerte) se utiliza para ayudar a seleccionar los registros que desea elegir:

???

En Couchbase, la vista generada es tu tabla, y cuando consultas la vista, Couchbase utiliza los valores clave (y el índice asociado que se generó), con los valores de consulta que especifiques filtrando la información devuelta para generar la lista final de registros coincidentes.

Este método de especificar las tablas que desea consultar le permite simplificar y optimizar la forma de extraer información de la base de datos. Pero también significa que tienes que pensar más detenidamente cómo quieres consultar la información.

La próxima vez

Ahora sabes cómo MySQL almacena y consulta información, y cómo ese conocimiento puede ser traducido cuando migras información a Couchbase Server 2.0. La próxima vez, empezaremos a construir algunas consultas basadas en lo que hemos aprendido, y empezaremos a ver consultas más avanzadas y el proceso de migración.