Cambiamos de servidor
Posted in CouchDB.es on November 15th, 2009 by Alex – Be the first to commentResumiendo: Se me acabó la paciencia con un hosting y nos vinimos a otro. Nada más
Resumiendo: Se me acabó la paciencia con un hosting y nos vinimos a otro. Nada más
Anterior artículo: Introducción a CouchDB (1)
Continuando con la introducción, hoy vamos a explicar varios conceptos más sobre las claves (keys), las revisiones que son las que organizan una base de datos.
Claves y revisiones
Cada documento tiene dos campos obligatorios, estos son: _id y _rev, que también forman parte de unos campos reservados por el sistema (existen otros, hablaremos más adelante de ellos), es decir: no los podremos usar como campos para almacenar datos del documento, por ello tienen un guión bajo al inicio, para evitar confusiones con campos propios del documento.
Ambos campos tienen que ser únicos, no pueden estar duplicados entre otros documentos en la misma base de datos.
¿Qué son?
_id es un campo único que indica el identificador único de un documento (o DocID)_rev es un campo único que indica con qué revisión del documento estamos tratando (hablaremos más adelante de las revisiones).Ejemplo:
{
"_id": "9ca5aa7891e3bb1963958eb713d02b0b",
"_rev": "1-12e6f6d62d0c5c16aadbb0837dff4f63",
"titulo": "Caperucita Roja"
}
En este ejemplo, tenemos un documento con un solo campo, con el identificador 9ca5aa7891e3bb1963958eb713d02b0b y como revisión 1-12e6f6d62d0c5c16aadbb0837dff4f63.
Hagamos cambios en este documento, por ejemplo, añadir otro campo:
{
"_id": "9ca5aa7891e3bb1963958eb713d02b0b",
"_rev": "2-3e0d0a8833471a19807a4f9eeddf9434",
"titulo": "Caperucita Roja",
"autor": "Anónimo"
}
Al actualizar el documento, CouchDB ha mantenido la ID, pero ha creado una revisión nueva
2-3e0d0a8833471a19807a4f9eeddf9434. El documento con el código de revisión anterior, permanecerá en la base de datos hasta ser compactado (Hablaremos más adelante de la compactación).
En CouchDB podemos hacer consultas directas por identificador y por revisión, podemos obtener todas las revisiones activas de un documento (si existieran) y podríamos consultar información sobre las mismas.
Si utilizamos Futon, este nos facilitará la tarea creando hashes únicos de 32 bytes para el campo _id, y una cadena compuesta de un entero, seguido de un guión como separador, y otro hash de 32 bytes para el campo _rev, de esta forma podemos saber rápidamente en qué revisión de un documento estamos.
Por lo general es preferible que estos campos mantengan valores alfanuméricos, pero las cadenas multibyte están soportadas por el sistema en principio. Nota: Si usamos el carácter ‘/’ dentro del nombre de un campo, deberemos escaparlo si queremos acceder al mismo por URL.
Continuará.
En una serie de posts intentaremos crear una breve e introductoria guía de conocimientos sobre CouchDB. Trataremos las bases y le daremos una explicación sencilla, además de una explicación extra para los programadores acostumbrados o provenientes de sistemas SQL (como un servidor).
¿Qué es CouchDB?
A pesar de que ya esté explicado en esta página “¿Qué es CouchDB?” vamos a dejarlo en palabras más sencillas y concretas:
CouchDB es un sistema de almacenamiento de documentos en formato JSON, a los que se asigna una clave única y a los que se accede vía peticiones HTTP y sobre los cuales se pueden ejecutar funciones MapReduce escritas en Javascript para manejar los datos.
Con esto debería quedar bastante claro. Si conoces otros sistemas de bases de datos deberías ver las diferencias con CouchDB.
Continúa en Introducción a CouchDB (2).
NoSQL es un término que representa y engloba a las bases de datos no relacionales u las orientadas a documentos y cuyo uso se ha extendido rápidamente, junto con la popularidad de este tipo de bases de datos.
Al contrario que bases de datos relacionales, las bases de datos orientadas a documentos no almacenan datos en tablas con campos uniformes para cada fila o registro. Cada documento es almacenado de forma que tenga ciertas características, cualquier número o tipo de campos pueden ser añadidos a un documento, e incluso contener varios tipos de datos.
Su mayor ventaja es que el escalado horizontal es extremadamente sencillo. Aunque ya hablaremos de ventajas e inconvenientes en breve en otro post.
Diferencias con SQL
Un ejemplo de base de datos orientada a documentos:
| Clave | Documento |
|---|---|
| 63 | Nombre: Pepe; Apellidos: García; Nacionalidad: Española |
| 64 | Nombre: François; Apellidos: Villepin; Nacionalidad: Francesa; Edad: 29; |
| 65 | Nombre: Mario; Nacionalidad: Italiana |
… comparada con una relacional:
| Clave | Nombre | Apellidos | Nacionalidad | Edad |
|---|---|---|---|---|
| 63 | Pepe | García | Española | |
| 64 | François | Villepin | Francesa | 29 |
| 65 | Mario | Italiana |
Además, en la relacional los campos podrían estar optimizados por tipo como VARCHAR, TEXT o INT parar mejorar la arquitectura.
Podemos ver que en la NoSQL, los campos vacíos no se añaden y que se pueden añadir campos concretos a documentos concretos, sin tener que aumentar el número de columnas.
Aplicaciones NoSQL conocidas
Más información:
CouchDBX es una versión pre-compilada específicamente para MacOSX (10.5 o 10.6) que nos ahorra tener que instalar CouchDB vía MacPorts o DarwinPorts.
Sus creadores Jan Lehnardt, Geoffrey Grosenbach y Jon Gretar nos traen una aplicación que se ejecuta y listo. Nada más. Movemos la aplicación a la carpeta de Aplicaciones del sistema, y ya directamente podremos manejar CouchDB desde la propia aplicación, pues incluye Futon, el gestor original de CouchDB.
Además de CouchDB, incluye ICU, Spidermonkey & Erlang. Para facilitar más el trabajo.
CouchDBX está licenciado bajo Apache License 2.0.
Inauguramos CouchDB.es, para intentar mantener al público hispanoparlante actualizado sobre las novedades y bondades de CouchDB como base de datos.