Según vemos en la página oficial del proyecto, NewSQL dispone a día de hoy de dos posibles gramáticas a implementar. Una de ellas está basada en la Java Database (JDB) y otra sería la evolución propia de SQL (SQL II, o S2). Aún no se ha decidido qué versión será la empleada como newSQL, por lo que, podemos decir que es un proyecto a futuro y no hay implementación real de momento.

Implementación JDB

La sintaxis que se desea implementar al estilo JDB tendría esta forma en comparación con el SQL actual:

La sintaxis puede parecer bastante clara y limpia, sobre todo para los que programan con lenguajes del estilo de Java, C++, PHP y de sintaxis derivada. No obstante, si tenemos en cuenta que esto sustituye a SQL, pero no a la forma de enviar las consultas, generar una cadena de texto de este estilo para enviarla al Sistema Gestor de Base de Datos, puede resultar bastante tedioso igualmente.

Hay bastantes dudas sobre, por ejemplo el INSERT, ya que, ahí nos muestran una inserción completa, pero, ¿y si queremos que haya datos por defecto y solo declarar algunos? … igualmente, en la cadena de búsqueda, da la sensación de haber empleado XPath para seleccionar las tuplas… ¿cómo se haría si se busca por un criterio en lugar de un ID? … al final puede quedar algo difícil de entender, realmente.

SQL II (S2)

La otra opción, es una versión evolucionada de SQL (o simplificada, según se mire), que tiene la siguiente forma:

Revisándolo, se ve claro que no aporta mucho, realmente, a lo que se usa de hoy en día. Es más, se intenta introducir de forma fija el uso del operador “==” en lugar de “=”, lo cual resulta extraño e inapropiado, desde mi punto de vista, ya que, en todo caso, cambiaría mejor el “=” del UPDATE por un “<-”.

Conclusiones

Desde mi punto de vista, más que centrarse en cómo escribir “mejor” los sistemas SQL, deberían de centrarse en agregar dichas sentencias para que se mezclasen con el código, algo como SQLJ, de cara a integración con los lenguajes, y de cara al mejor uso de SQL, hacer estándares del uso de las fechas (que cada sistema los usa a su forma), así como los LIMIT, funciones básicas y tipos de datos, entre otras muchas cosas, para que los SGBD fuesen más compatibles entre ellos.

No obstante, la historia quiso que MySQL AB, la empresa que se creó para comercializar la idea de la base de datos rápida para webs, fuese finalmente adquirida por Sun Microsystems, para dar un supuesto impulso a su integración con el mundo de Java. A lo que respondió otro de los grandes del sector, finalmente, comprando a la propia Sun Microsystems.

En el momento en el que MySQL pasó a ser de Sun, comenzaron las tiranteces, de forma que, Monty, uno de los fundadores y responsable del desarrollo inicial de MySQL, que comentó que el nombre, precisamente, provenía de una de sus hijas (llamada My), hizo un fork, dándole el nombre de MariaDB (otra de sus hijas).

El caso es que, por ética profesional y propia, al final, he decidido abandonar definitivamente MySQL para usar única y exclusivamente MariaDB en lo que concierne a base de datos tipo MySQL… ya que, también hay otras como PostgreSQL que siguen siendo una muy buena opción a considerar, según el caso que se dé.

Migrando

Lo primero, veo que en la propia página de Monty dedicada a MariaDB, hay un configurador bastante bueno de elegir la distribución, la versión de MariaDB a instalar y el mirror más cercano. Con esto tenemos que la instalación en mi Debian Squeeze, por ejemplo, se basa en poner los repositorios correspondientes y hacer el apt-get install para mariadb-server-5.3 (por ejemplo).

Tanto si se instala de forma automática, como de forma manual, si tenemos corriendo un MySQL 5.1 (por ejemplo), el sistema se encarga de desinstalarlo, poner en su lugar MariaDB y ejecutar un script llamado mysql_upgrade (que en caso de la instalación desde apt-get install se realizará de forma automática).

El servidor se levanta de forma rápida y tenemos un MySQL completamente funcional con la base de datos instalada y funcionando. El corte casi que ni se nota.

No obstante, siempre es deseable tener una copia de seguridad por lo que pudiera pasar. Está el caso de éxito de SpamExperts que migraron cerca de 300 servidores en más o menos tres horas y sin complicaciones.

Las ramas de MariaDB

Actualmente hay disponibles tres ramas de MariaDB, la versión 5.1, la versión 5.2 y la versión 5.3.

• La versión 5.1 es una versión prácticamente igual que la versión 5.1 de MySQL, solo que con muchas correcciones de errores realizadas.
• La versión 5.2 es la siguiente evolución, que consta con muchas de las características que querrían haber introducido sus creadores en la versión anterior, pero no pudieron por falta de tiempo.
• La versión 5.3 es la actual, que integra muchas mejoras y cosas que en MySQL solo están en la versión comercial.

La versión 5.3, que es la última y la más avanzada, tiene cosas como:

• Optimizaciones en subconsultas, de siempre en SQL, el hecho de realizar subconsultas es algo que da un poco de miedo, porque, además de que puede ser lioso el hecho de construir una gran consulta con subconsultas dentro, tiene penalización en rendimiento. Pues bien, esta versión está optimizada para el uso de subconsultas de modo que, con respecto a MySQL (la versión normal) mejora el rendimiento sustancialmente.
• Interfaz NoSQL… bueno, realmente, sigue siendo SQL, pero permite redefinir y aumentar la base de datos de forma fácil en cada UPDATE e INSERT. Un ejemplo puede verse en esta página.
• Nuevos engines (realmente esto es de la 5.2), permite usar OQGRAPH, que es un engine preparado para el almacenamiento de elementos jerárquicos y grafos; y SphinxSE que integra un sistema de búsqueda de texto muy parecida al FTS de PostgreSQL enlazando con el servidor de Sphinx.
• Autenticación por plugins: permite tener autenticación vía PAM, LDAP, etc.

Conclusiones

MariaDB se mueve en un entorno ágil con mucha gente que lo mantiene desde su comunidad, y sobretodo, con el apoyo y liderazgo de quien comenzó en su día MySQL, por lo que, es más que posible que dentro de unos cuantos meses o años, se comience a escuchar hablar más de MariaDB que de MySQL. Además, migrar ahora es fácil, ya que las versiones 5.1 en ambos elementos son muy parecidos (son casi iguales), pero ya con la versión 5.5 de MySQL (han saltado de la 5.1 a la 5.5 directamente) y la 5.3 de MariaDB, cada vez se irán distanciando más.

Mi consejo: ¡actualiza ya!

En este caso, aunque he hablado en otras ocasiones de CouchDB, de Cassandra, etc. me ha llamado la atención MongoDB. Esta base de datos realizada en C++, que cuenta, entre sus principales características con ser una base de datos de esquema libre, de alto rendimiento y orientada a documentos.

Coincide que ayer se liberó la versión 2.0.1, aunque no comentaré las nuevas mejoras, sino en sí, lo que hace MongoDB.

Acceso a Datos

El sistema de MongoDB es de esquema libre. Esto quiere decir que no requiere de una definición previa de datos, es decir, de hecho, los datos que se almacenan en sus colecciones son heterogéneos completamente.

Mientras que una base de datos relacional, con tablas, se estructura en base de datos, tablas, tuplas y campos, una base de datos, como MongoDB, se estructura en base de datos, colección y datos. Esto quiere decir que, dentro de una colección podría poner el dato:

{ a: 1, b: 2, c: 3 }

Y acto seguido, agregar otro dato a la colección que sea:

{ a:2, [ {nombre: 'Manuel', apellido: 'Rubio', web: 'http://bosqueviejo.net'} ] }

Lo que sí es conveniente respetar, al menos, es el primer dato, ya que así las búsquedas son más fáciles, tanto para el sistema como para el usuario (o programador que realiza las consultas).

NoSQL… vale, ¿entonces qué?

En este tipo de base de datos, que son NoSQL, se emplean muchas técnicas para realizar búsquedas, pero MongoDB ha optado, quizás, por la más simple, que es integrar un lenguaje para esta tarea. Por lo que es posible realizar consultas estructurando la información que se pasa a nivel de criterio de búsqueda en…. ¡JavaScript!

Alguien me dijo que JavaScript era el lenguaje del futuro y, parece que al fin, ese futuro llegó, puesto que hay JavaScript en la programación web, como servidor a través de NodeJS, para el dialplan de FreeSwitch incluso… y ahora como lenguaje de consulta a una base de datos.

Entonces, vale, aceptamos JavaScript. Esto hace que las consultas se estructuren en hash (objetos realmente), de la siguiente forma:

db.cosas.find({'a': 2})

La estructura sigue el orden de db (como base de datos) y cosas (como colección de datos). Cada base de datos es un objeto que tiene como atributos sus colecciones y cada colección tiene a su vez una serie de métodos que le permiten realizar acciones con su conjunto de datos.

Buscar o Encontrar

Aunque hay otras base de datos NoSQL que solo sirven para encontrar (se debe de acceder por un identificador primario o el sistema debe de recorrer todo el conjunto de datos haciendo criba de los registros), MongoDB tiene mecanismos bastante buenos que le permiten realizar búsquedas bastante óptimas sobre el conjunto de datos heterogéneo. Algo tan simple como: la creación de índices.

Podemos crear índices sobre un campo que sepamos que seguramente estará en la mayoría del conjunto de datos (como por ejemplo a en el ejemplo expuesto) y así acelerar las búsquedas en este sentido.

Así mismo, el sistema en JavaScript permite realizar búsquedas basadas en rangos, o incluso con listas de inclusión de la siguiente forma:

db.cosas.find({ $or: [{ 'a': 1}, { 'a': 2}]});
db.cosas.find( {'a': { $gt: 0, $lte: 1 }});

Ambas consultas, por forma sacarían los dos registros que expusimos de ejemplo arriba, ya que en el primer caso, a puede tomar los valores 1 ó 2, y en el segundo caso a puede tomar valores mayores que cero y menores o iguales que uno.

Hay mucha, pero mucha, más información de esto en el manual oficial de MongoDB en su propia página.

Desde otros lenguajes

El sistema, realmente es una joya para la gente que programe en JavaScript y se haya lanzado a cosas como NodeJS y JavaScript MVC, ya que tendrán la posibilidad de realizar la búsqueda en JavaScript igualmente, y la integración con este lenguaje es la más clara de las que he podido ver (a nivel de envío de datos) ya que se estructura en base a la misma estructura que tiene JavaScript.

Por otro lado, hay implementaciones para PHP (la cual he podido ver más de cerca), C, C++, Erlang, Haskell, Java, JavaScript, .NET (C#, F#, PowerShell, etc), Perl, Python, Ruby y Scala, de los que da soporte directo MongoDB, y otros soportados por la comunidad como: ActionScript3, Clojure, ColdFusion, D, Delphi, Factor, Fantom, Go, Groovy, Lisp, Lua, MatLab, Objetive C, Prolog, R, Racket y Smalltalk.

Conclusiones

Me ha impresionado muy positivamente esta base de datos, las pruebas que he realizado, de cara a rendimiento y uso a través de objetos han sido muy fáciles y la integración muy clara y sencilla. Es una muy buena opción para la toma de datos heterogéneos, sin duda, pero también como base de datos escalable en el tiempo y de alto rendimiento.

Actualización 16/09/2011: se me olvidó comentar que SPOF significa, según sus siglas, Single Point Of Failure, algo así como el punto único de fallo. Se refiere a cuando un sistema, aún teniendo bastante redundancia, tiene un punto único, en la red, en el software o en alguna parte del sistema que, fallando, deja sin servicio a todo.

Como la mayoría de software realizado por empresas y que se adentran en el software libre, Riak tiene dos versiones, una Open Source (que es completa y funcional) y otra Enterprise (que agrega commodities -o facilidades- tales como una interfaz de administración).

La base de datos Riak está basada en el documento escrito por Amazon sobre el sistema de almacenamiento Dynamo, el cual se basa en un sistema de alta disponibilidad, con estructura de almacenamiento del par clave-valor y distribuido. Este documento ha sido seguido, además, por Cassandra (la base de datos de Facebook, liberada y acogida en el seno de la Fundación Apache, y que ha sido implementada desde entonces por Digg, Twitter, Reddit, Rackspace, etc.) y por Voldemort (la base de datos de LinkedIn).

Características principales

Riak, además de seguir las bases de Dynamo, ha agregado otras características propias a la lista, quedando (visto en su página web oficial) la siguiente lista de características a destacar:

• Escalabilidad: la escalabilidad con Riak es lineal, predecible y de coste efectivo. Agregar nuevas máquinas no significa tener una avalancha de de peticiones que ponga en peligro la efectividad del sistema. Se pueden ir agregando o eliminando máquinas sin mayor problema, y sin que suponga una carga excesiva para el sistema base.
• Tolerancia a fallos: el cluster soporta o admite fallos en nodos aislados, o incluso en partes del cluster, está preparado para no perder datos ante este tipo de fallos. El sistema ha sido diseñado con fallos de máquinas e interrupciones de servicio de red como norma, no como excepción.
• Alta disponibilidad: para alta disponibilidad el sistema debe de estar disponible, no solo para lecturas, sino también para escrituras. La arquitectura de share-nothing (nada compartido) hace que cada nodo en el cluster esté habilitado para realizar lecturas y escrituras, por lo que, la alta disponibilidad está garantizada.
• Replicación: dependiendo de las necesidades, Riak se puede configurar para replicar entre múltiples clusters iguales o diseñar uno o más clusters como solo-lectura o backup. Cada nodo en el cluster puede responder a las peticiones de lecutra/escritura, y el evento de replicación asegura que todos los clusters sean actualizados. Los algoritmos se ejecutan en cada nodo asegurando la consistencia de datos.

En base al teorema CAP del Dr. Eric Brewer, las tres propiedades deseadas de un sistema distribuido son: consistencia, disponibilidad y partición (tolerancia a fallos). El teorema establece que puedes solo puedes tener dos de las tres propiedades en cada momento. Riak se enfoca en Disponibilidad y Partición. Esta elección pone a Riak en el campo de la consistencia eventual. Sin embargo, la ventana para consistencia eventual es en términos de milisegundos, lo que es suficiente para la mayoría de aplicaciones.

¿Cómo funciona?

No me quiero extender mucho, ya que esta información está disponible (aunque en inglés) en la propia web de Riak, en Concepts, así que resumiré un poco.

El almacén de datos se realiza en base a el par clave-valor, es lo que podríamos llamar una base de datos hash. No obstante, la clave se compone de bucket y key, que son como en Erlang el módulo y la función, o en Java el paquete y la clase. El conjunto bucket/key es la unidad de organización única que puede emplearse.

El sistema admite también el uso de enlaces (links). Esto quiere decir que el contenido de un bucket/key, puede ser un contenido o un enlace a otro bucket/key que tenga su propio contenido. Algo así como el enlace simbólico en los sistemas de ficheros de Unix/Linux/BSD/…

Además, el contenido, puede ir estructurado en forma de metadatos, es decir, como las cabeceras de los mensajes HTTP, para disponer de arrays asociativos (hash) dentro del contenido.

Uso de diferentes backends. En la versión 0.12, Bitcask se estableció como backend para Riak, pero hay más, aquí ponemos un listado de los disponibles:

• Bitcask: simple pero potente almacenaje de pares clave-valor. Es de baja latencia y alto rendimiento.
• DETS / ETS: tablas incorporadas en Erlang para el almacenamiento de información.
• Erlang Balanced Trees (gb_trees): sistema de árbol balanceado. Rápido para leer, pero algo lento para escribir.
• Innostore: basado en el engine InnoDB de MySQL. Debido a restricciones de licencia, se proporciona por separado.

Cada cluster que se configura de Riak, consta de los siguientes elementos:

• Nodos: nodos físicos, o máquinas, de las que se compone el cluster.
• Nodos Virtuales: nodos virtuales (o vnodes) que corren en cada máquina. Cada máquina física puede contener uno o varios nodos virtuales.
• Particiones: cada cluster Riak tiene un entero de 160-bits dividido en particiones ecuánimes. Cada vnode reclamará una partición del anillo.

Cada nodo en el cluster es responsable del 1/(número total de nodos físicos) del anillo. Puedes determinar el número de vnodes en cada nodo calculando el (número de particiones)/(número de nodos). Por ejemplo, un anillo con 32 particiones, compuesto por cuatro nodos físicos, tendrá aproximadamente ocho vnodos por nodo. Esta configuración es representada por el siguiente diagrama:

Riak está diseñado para ser un sistema distribuido, cuantos más nodos haya en el sistema, más rápido funcionará.

No hay nodo maestro, todos los nodos en Riak son iguales. Cada nodo es completamente capaz de servir cualquier petición de cliente. Esto es posible debido a la forma en la que Riak usa la consistencia de hash para distribuir datos a través del cluster, que se realiza a través de un gossip protocol.

Sobre la replicación

Riak controla tantas réplicas como datos son mantenidos a través de una configuración llamada n-valor. Este valor tiene una configuración por defecto en cada nodo pero puede ser sobreescrito por cada bucket. Los objetos de Riak heredan el n-valor de su bucket padre. Todos los nodos en el mismo cluster deben de acordar y usar el mismo n-valor.

Por ejemplo, aquí hay una representación de que sucede cuando n-valor es 3 (esta es la configuración por defecto). Cuando almacenas el dato en el bucket con un n-valor de tres, el dato se replicará a tres particiones separadas del anillo.

Y cuando un nodo falla o se agrega otro nodo, ¿qué sucede?

Riak usa una técnica llamada hinted handoff, para compensar el cluster en el momento que un nodo falla. Los vecinos del nodo fallido tomarán relevo y realizarán el trabajo de ese nodo permitiendo al cluster trabajar de forma normal. Esto puede considerarse una forma de auto-curación.

Si se agrega un nodo nuevo, en cambio, se rebalancean los datos.

Algunas pegas… siempre las hay

Primero, los buckets que usan un conjunto de propiedades no estandar forzarán a Riak a enviar vía gossip más datos a través del cluster. Los datos adicionales pueden ralentizar el proceso. Segundo, algunos backends, como Innostore, almacenan cada bucket como una entidad separada. Esto puede causar que nos quedemos sin recursos tales como manejadores de ficheros. Estas restricciones de recursos pueden no impactar al rendimiento, pero representarán otro límite en el máximo número de buckets a gestionar.

Conclusiones

A nivel teórico, todo bien, parece. Habrá que realizar un banco de pruebas y ver qué tal va el sistema. De momento, me he quedado sin tiempo (del que había planificado) para escribir este artículo, por lo que, dejo las pruebas para la siguiente parte… que entraremos de lleno en la práctica.

Fuente: documentación oficial de PostgreSQL 9.0.

El concepto de FTS

La búsqueda de texto completa (Full Text Searching o FTS) proporciona la capacidad de identificar documentos de lenguaje natural que satisfacen una consulta y, opcionalmente, ordenarlos por relevancia a la consulta. El tipo más común de búsqueda es buscar todos los documentos que contengan los términos de la consulta y los retorna en orden de similitud. Los conceptos de consulta y similitud son muy flexibles y dependen de la aplicación específica. La búsqueda más simple considera una consulta como un conjunto de palabras y su similitud con la frecuencia de aparición de las mismas en el documento.

¿Qué es un documento?

Un documento es la unidad de búsqueda en un sistema FTS; por ejemplo, un artículo de una revista o un mensaje de email. El motor de búsqueda de texto debe estar preparado para analizar documentos y almacenar asociaciones de lexemas (palabras clave) con su documento padre. Después, estas asociaciones son usadas para buscar documentos que contengan esas palabras clave.

Para PostgreSQL un documento es, normalmente, un campo de texto, o una concatenación de varios campos de texto almacenados en una o varias tablas, o un texto obtenido de forma dinámica. En otras palabras, un documento puede ser construido de diferentes formas y puede no estar almacenado en ningún sitio. Por ejemplo:

SELECT title || ' ' || author || ' ' || abstract || ' ' || body AS document
FROM messages
WHERE mid = 12;

Búsqueda de texto básica

El FTS en PostgreSQL está basada en el operador @@, el cual retorna true si un tsvector (documento) coincide con una tsquery (consulta). No importa el orden en el que se pongan:

SELECT 'tres tristes tigres comieron trigo de un trigal'::tsvector @@ 'tristes & tigres'::tsquery;

Búsqueda de Resultados por Ránking

Ránking intenta medir como de relevantes son los documentos para una consulta en particular, así que cuando hay muchas coincidencias, la más relevante se muestra primero. PostgreSQL proporciona dos funciones de ránking predefinidas, las cuales tienen en cuenta el léxico, proximidad y estructura de la información. Esto es, que consideran como aparecen de frecuentes los términos en el documento, como de juntos están en el documento y como de importante es la parte de el documento donde aparecen. Sin embargo, el concepto de relevancia es vago y muy específico de la aplicación. Aplicaciones diferentes pueden requerir información adicional para el ránking. Las funciones construidas para ránking son solo ejemplos. Puedes escribir tus propias funciones de ránking y/o combinar sus resultados con factores adicionales para ajustarlas a tus necesidades específicas.

Aquí hay un ejemplo que, selecciona solo las diez coincidencias más altas en el ránking:

SELECT title, ts_rank_cd(textsearch, query) AS rank
FROM apod, to_tsquery('neutrino|(dark & matter)') query
WHERE query @@ textsearch
ORDER BY rank DESC
LIMIT 10;

El resultado:

                     title                     |   rank
-----------------------------------------------+----------
 Neutrinos in the Sun                          |      3.1
 The Sudbury Neutrino Detector                 |      2.4
 A MACHO View of Galactic Dark Matter          |  2.01317
 Hot Gas and Dark Matter                       |  1.91171
 The Virgo Cluster: Hot Plasma and Dark Matter |  1.90953
 Rafting for Solar Neutrinos                   |      1.9
 NGC 4650A: Strange Galaxy and Dark Matter     |  1.85774
 Hot Gas and Dark Matter                       |   1.6123
 Ice Fishing for Cosmic Neutrinos              |      1.6
 Weak Lensing Distorts the Universe            | 0.818218

La misma usando un ranking normalizado:

SELECT title, ts_rank_cd(textsearch, query, 32 /* rank/(rank+1) */ ) AS rank
FROM apod, to_tsquery('neutrino|(dark & matter)') query
WHERE  query @@ textsearch
ORDER BY rank DESC
LIMIT 10;

Y su resultado:

                     title                     |        rank
-----------------------------------------------+-------------------
 Neutrinos in the Sun                          | 0.756097569485493
 The Sudbury Neutrino Detector                 | 0.705882361190954
 A MACHO View of Galactic Dark Matter          | 0.668123210574724
 Hot Gas and Dark Matter                       |  0.65655958650282
 The Virgo Cluster: Hot Plasma and Dark Matter | 0.656301290640973
 Rafting for Solar Neutrinos                   | 0.655172410958162
 NGC 4650A: Strange Galaxy and Dark Matter     | 0.650072921219637
 Hot Gas and Dark Matter                       | 0.617195790024749
 Ice Fishing for Cosmic Neutrinos              | 0.615384618911517
 Weak Lensing Distorts the Universe            | 0.450010798361481

¿Hay más?

Pues claaaaaro que sí. Pero de momento lo dejo aquí, en previsión de hacer una segunda entrega con cosas como resultados resaltados (highlighting results) y sobretodo, la personalización de los analizadores, plantillas, configuraciones y diccionarios.

En postgresql, por ejemplo, el sistema de lenguajes que se pueden usar e implementar para la creación de funciones: PL/pgSQL, PL/Tcl, PL/Python, PL/Perl, PL/PHP, PL/Java, PL/Ruby, …; todos ellos se pueden ver en la página de documentación de PostgreSQL.

Esto quiere decir que, en una llamada a una función SQL se puede emplear una función específica programada en cualquiera de estos lenguajes, así como el lanzamiento de un trigger, puede ser compuesto por una serie de llamadas a estos procedimientos.

No obstante, la gente suele tener bastante miedo a usar estos sistemas para lógica de negocio por varios motivos, pero principalmente porque el despliegue es complejo.

Sí, en ciertos SGBD, un despliegue y mantenimiento resulta algo complejo, el hecho de mantener unas versiones y saber exactamente qué hay en producción y qué no hay, así como el hecho de que un cambio pueda hacerse en cualquier momento y pueda desvirtuar lo que haya en el repositorio en sí.

No obstante, puede solventarse con el uso de sistemas como migrations de rails, o similares. Es decir, no cargar nada directamente desde una interfaz abierta o desde la consola, sino desde una herramienta que permita controlar las subidas en forma de versiones.

En sí, el sistema de CHECK de PostgreSQL permite y da ventajas al usuario de desarrollar parte de la lógica de negocio. Allá donde no llegan los mecanismos típicos, es donde se puede comenzar a tirar de las funciones desarrolladas en cualquier lenguaje, con la potencia de que estas pueden ser lanzadas como CONSTRAINT, TRIGGERS o de forma inmediata en una consulta SQL.

En mi opinión, el uso de PostgreSQL como capa de datos, y además como capa de negocio, es una opción tan válida como extraer esa lógica a otros sistemas externos. La única nota negativa, es la interconexión, que obliga a que se haga con el conector de base de datos mientras que desarrollando la capa de negocio en otro tipo de framework, este acceso podría bien ser por mecanismos más orientados a RPC como SOAP o REST.

Leyendo el blog de dos ideas con referencia a un artículo que publicaron llamado NoSQL: el movimiento en contra de las bases de datos, se comenta una conferencia en la que grandes profesionales del sector de los sistemas, con necesidades de escalabilidad y alta capacidad de almacenaje, mencionaban sus soluciones NoSQL.

Entre ellos, representantes de empresas como Google, Amazon, Facebook, Twitter, LinkedIn, … pusieron en conocimiento de todos los asistentes sus soluciones ya desarrolladas y en funcionamiento para suplir las carencias que las bases de datos tradicionales no podían cubrir.

Las ventajas de NoSQL

Las ventajas de estos sistemas de almacenamiento (hay muchos integrantes de este movimiento que consideran una aberración llamarlos bases de datos) son las siguientes:

• Pueden manejar enormes cantidades de datos: esto es debido a su propia estructura distribuida. Por ejemplo, HyperTable, una implementación de código abierto basada en BigTable (de Google), puede escribir 1000 millones de celdas de datos por día. Al igual que BigTable, con MapReduce, es capaz de manejar 20 petabytes diarios.
• Se ejecutan en clusters de máquinas baratas: estos sistemas no requieren de apenas computación, en comparación con los sitemas gestores de base de datos tradicionales y basados en SQL, por lo que se pueden montar en máquinas de un coste más reducido y en mayor número, gracias a su nivel de escalabilidad.
• No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia compleja requiere, además de un nivel de ejecución más concreto para poderse llevar a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base a rendimiento.
• Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de consulta complejo ni con capacidad declarativa para en una sola línea realizar una cantidad interna de operaciones desorbitada.

Las desventajas

Bueno, y después de poner estos sistemas por las nubes… ahora toca pegar un poco los pies al suelo y darse de cara con la realidad. Quiero decir que, sí, hay desventajas, esto no es una panacea que sirva para paliar la necesidad del almacenaje de datos para todos los casos. En entornos de sistemas de información, en gestión de cuentas, y entornos en los que es preferible que los datos puedan tener algo más de inteligencia, en lugar de algo más de rapidez, estos sistemas no son aconsejables, ya que la única, pero mayor desventaja de estos es que no respetan ACID.

Conclusiones

En mi caso particular, trabajando en un área de sistemas relacionado con la telefonía en el que premia más la velocidad de tratamiento de datos, así como la capacidad para poder manejar gran cantidad de los mismos, y en el que la integridad referencial es algo que ni se usa ni se tiene en cuenta, sí, es una solución real, una forma de ahorrarse gran cantidad de código y dolores de cabeza con respecto a la escalabilidad y concurrencia de la información dentro de la plataforma tecnológica.

Ahora, si mi trabajo fuese desarrollar sistemas CRM, ERP o similares, que dependen más de la integridad de los datos, así como su relación y unas reglas de negocio establecidas y programadas, es innegable que las bases de datos con soporte SQL agregan mucho valor en este sentido.

Por lo que, podemos concluir en que, para programación de sistemas son un recurso muy útil y que puede facilitar y paliar problemáticas relacionadas con el almacenaje de información, así como el tratamiento in-situ de la misma con cara a la lógica del servicio, y por otro lado, si lo que premia más es tener una lógica de negocio bien definida, en ese caso, quizás es mejor seguir usando los sistemas SQL.

El problema real vino cuando Sun Microsystems fue adquirida por Oracle. Esta adquisición puso a MySQL en la duda de si seguiría siendo lo que es, o pasaría a ser otro producto más recortado en su versión comunitaria y ofrecido por un precio medio/alto a empresas que se lo puedan permitir. Como si de una versión light de Oracle DB se tratase.

Entre todo este tumulto, en parte levantado por Monty, uno de los principales desarrolladores de MySQL, que se fue de la empresa cuando comenzó todo el lío, surgen varias versiones de MySQL, forks, que prometen seguir la línea original y seguir apostando por el crecimiento de este sistema dentro de la comunidad y el software libre.

Una de las apuestas es MariaDB, promovida por el propio Monty, es un fork del último código estable de MySQL, agregando todos los patchs que no se incluyeron en MySQL y dando soporte a problemas que parece que los desarrolladores principales de MySQL han olvidado.

En otro punto se sitúa el proyecto Drizzle, que intenta seguir los ideales iniciales de MySQL en un punto en los que muchos de los desarrolladores que pertenecían a esta comunidad, consideran que se torció el desarrollo principal.

Con esto podemos decir que el espíritu de MySQL no ha muerto, ni morirá, puesto que seguirá vivo en dos ramas separadas de su código original en los momentos clave en los que cada comunidad vió que era el momento de un cambio.

Como nota curiosa, el ecosistema de protección de los sistemas gestores de base de datos abiertas (Open Database Alliance), se encarga de la promoción entorno a los sistemas gestores de las base de datos. Una propuesta interesante que promete un poco de seguridad dentro de este entorno.

El problema que intenta solucionar este sistema es el siguiente. Imagina que tenemos un sistema que hace múltiples escrituras y lecturas de una base de datos. No es difícil, seguro que conoces cientos de sistemas que lo hacen. Ahora, ten en cuenta que, los accesos a base de datos, depende para qué, realizan ciertos bloqueos, para asegurarse de que la información a modificar o a leer (incluso) no es modificada por nadie, hasta que termine su actividad.

En MySQL, por ejemplo, existen distintos tipos de bloqueos, muchos de ellos automáticos, que hacen el bloqueo de una tabla completa, o de ciertas partes específicas, al hacer una actividad de modificación, o un bloqueo compartido, para hacer actividades de lectura (solo bloquea en este caso a los que intentan escribir).

Pero en tema de índices, hay muchos SGBD que usan sistemas de índices que al actualizarse, se bloquean completamente, dejando, no solo las escrituras bloqueadas, sino también las lecturas, creando un lag de acceso a los datos.

Interbase fue la primera base de datos que eliminó la contención, los deadlocks y garantizaba transacciones ACID mediante el sistema MVCC. La idea es: no actualizar ni eliminar nunca una fila del disco. Si deseas actualizar, se agrega una nueva fila con la misma clave primaria, la cual oculta la antigua fila. Si deseas eliminar, agrega una nueva fila que etiqueta la clave primaria como eliminada, la cual oculta la antigua fila.

Las viejas filas no eran nunca actualizadas, así que no era necesario implementar ningún sistema de bloqueo y la contención (o espera) mágicamente desapareció.

El sistema, no obstante, tiene pequeños defectos: usa más espacio de disco y puede ser algo más lento a la hora de leer datos. La buena noticia es que los datos se pueden respaldar (realizarse un backup) en cualquier momento sin bloquear el sistema.

En MySQL, los tipos de tablas Falcon (a partir de la versión 6.0) e InnoDB (antes de la 6.0), implementan este sistema para las actualizaciones (updates) usando bloqueo a nivel de fila, lo cual puede causar un tiempo de espera para otros procesos (contención).

En PostgreSQL se usa el comando VACUUM para actualizar las base de datos, es decir, implementar las transacciones agregadas al final en lugar de a las que reemplazan y eliminar las tuplas marcadas para reclamar más espacio en disco. Esta operación demora, pero hace que la base de datos pase de un consumo alto de disco duro, al ajustado que debe de ser, antes de la próxima sesión crítica

Hay otras bases de datos que también implementan Multiversion concurrency control, tal y como menciona la wikipedia, tales como:

• Berkeley DB: que es una base de datos a nivel de fichero, como puede ser SQLite, pero sin uso del lenguaje SQL.
• CouchDB: de la cual ya comenté algunas cosas en otro artículo.
• Oracle 7: y superiores.
• Microsoft SQL Server 2005: y superiores. El soporte es opcional, se pueden configurar los niveles de aislamiento (isolation) para poder usar MVCC o no.
• MySQL: a través de InnoDB o Falcon, pero se usa nivel de bloqueo por fila, en lugar de snapshot.

Más información:

• PostgreSQL 8.3: Concurrency Control
• MVCC and snapshot-capable database – Do It Yourself
• PostgreSQL: ¿la base de datos empezó a consumir exageradamente espacio de disco? (actualizado)
• On Transaction Isolation Levels
• PostgreSQL MVCC and VACUUM

El sistema de CouchDB, además de destacar como base de datos documental, cuya definición, extraída de la Wikipedia, viene a decir:

Permiten la indexación a texto completo, y en líneas generales realizar búsquedas más potentes. Tesaurus es un sistema de índices optimizado para este tipo de bases de datos.

Este sistema está altamente indicado para proyectos del tipo:

• Buscadores, ya que se pueden almacenar webs y después hacer búsquedas en texto de forma eficiente.
• Bitácoras, blogs, weblogs…; donde el almacenamiento de artículos o extensos textos, puede ser indizado y manejado para realizar las búsquedas.
• Almacenes de libros, documentos y otros textos que puedan escribirse, sobre todo en formatos de texto plano, como pueden ser HTML, XML (Docbook, DITA, …), SGML, TXT, LaTeX, …

A esto sumamos que el transporte se realiza mediante HTTP, por la convención establecida mediante REST, y tenemos un sistema fácil de implementar y que soporta la carga que supone transmitir todos los documentos almacenados de una forma eficiente.

Cabe destacar que, aunque sea una base de datos documental y esté basada en el almacenamiento de documentos en campos de texto grandes, también se pueden almacenar otros tipos de datos y crear “tablas” a modo de tener un formato relacional, donde el documento juegue el papel principal, claro.