Llegamos a ustedes gracias a:



Columnas de opinión

Escalar y consultar las grandes bases de datos NoSQL

Por: Rahim Yaseen, vicepresidente senior de ingeniería en Couchbase

[18/03/2013] Dominadas por el paradigma RDMS, las bases de datos fueron un área o zona de tecnología bastante soñolienta por muchos años. Las NoSQL cambiaron todo ello. A pesar que la tecnología detrás de la mayoría de bases de datos NoSQL no son nuevas, la gran variedad de enfoques y productos han hecho que muchos consumidores luchen por ponerse al día.
Uno de los beneficios clave que ofrecen las NoSQL es su capacidad de escalar fácilmente en comparación con las bases de datos RDBMS. Pero, ¿cómo funciona esto exactamente? Para obtener la respuesta, la revista americana InfoWorld conversó con Rahim Yaseen, vicepresidente senior de ingeniería en Couchbase, empresa proveedora de una base de datos NoSQL muy popular tipo documento. Él también habla sobre el tema de la complejidad de realizar preguntas usando una base de datos de documentos.
Escalar y consultar en los grandes conjuntos de datos con NoSQL
Hoy en día, nos encontramos en un punto de inflexión donde las organizaciones están buscando maneras de gestionar, almacenar y aprovechar un cada vez mayor flujo de datos. Con conjuntos de datos muy grandes, las organizaciones deben determinar la solución que mejor se ajusta a sus necesidades para escalar su tecnología y su negocio.
Una decisión clave con las bases de datos es determinar si es mejor hacer scale out o hacer scale up, aunque, de todos modos, ¿qué significa esto?
En una arquitectura de scale out, que se asocia con las bases de datos NoSQL, se utiliza como arquitectura básica un conjunto distribuido de nodos conocido como clúster. Éste proporciona una capacidad de escalabilidad muy elástica, lo que le permite agregar en marcha nodos para manejar la carga. Esto es lo opuesto a la arquitectura scale up, asociada con los RDBM, la cual más bien añade más recursos a una sola máquina más grande.
Un concepto clave en el scaling out es shared nothing. Una arquitectura ideal de scale out se basa en una arquitectura shared nothing, donde todos los nodos son pares y no hay ningún recurso compartido que sirva como cuello de botella. Además de que todos los nodos son independientes, todos los datos deben estar uniformemente distribuidos en estos nodos, mediante un proceso llamado sharding. Este es un proceso importante y puede ser logrado, ya sea manualmente o a través de un sistema automatizado.
Sharding manual versus sharding automático
Para entender la diferencia entre sharding manual y el autosharding, considere el proceso de registro en una conferencia típica. Cuando entra al área de registros, lo más probable es que se le pida que vaya a la cabina de registros que corresponde a la primera letra de su apellido. Por ejemplo, desde la letra A hasta D, se registran en la cabina número 1, de E hasta H en la cabina número 2 y así sucesivamente. Éste es en un ejemplo de escala a través del sharding manual.
Con el sharding manual, los registros están distribuidos a través de una serie de cabinas de registro. Esto funciona porque hay un sistema predeterminado muy bien definido. No obstante, no hay garantías de que los datos o los solicitantes de registros van a ser distribuidos de manera uniforme, o que las cabinas se puedan ampliar fácilmente sin tener que reorganizar todos los registros. Por otra parte, el cierre de una sola cabina (equivalente a un error de nodo) requiere una reorganización en las otras cabinas.
Por otra parte, supongamos que entra a la misma conferencia y se le da la opción de registrarse en cualquiera de las cabinas de inscripción o registro. Este escenario es similar a como funciona la distribución de datos a través del sharding automático, donde los datos son automáticamente revisados para una distribución uniforme. Los datos pueden ser accedidos desde cualquier nodo mediante un algoritmo que dirige la solicitud al nodo particular.
Tenga en cuenta, sin embargo, que las fallas en los nodos son muy comunes. Las grandes arquitecturas de scale out deben operar en el supuesto de que es parte del procedimiento operativo normal el hecho de que varios nodos fallen en cualquier momento.
Si los nodos de una arquitectura scale out fallan, pero la arquitectura está bien diseñada, el proceso puede continuar con el resto del clúster. Aquí, el autosharding tiene una clara ventaja; con el sharding manual, replicar y mover los datos durante las fallas de nodo -es decir, rebalancear los datos- puede ser un gran reto. Dado que los conjuntos de datos se vuelven muy grandes, rebalancear una implementación después de un sharding manual es demasiado costoso, por tanto es necesario un esquema de autosharding.
Consultas a los grandes conjuntos de datos
El contraste entre el sharding manual y el autosharding también se puede apreciar al momento de consultar grandes conjuntos de datos. Piense nuevamente en la analogía del registro. Con el sharding manual, si quiere encontrar a todas las personas de la conferencia que tienen un apellido que comience con la letra S, solo tendrá que ir a una cabina de registro para determinar y hallar esos nombres.
Con el autosharding, si quisiera encontrar la misma información, tendría que ir a todas las cabinas para determinar quiénes tienen apellidos que comienzan con la letra S. Normalmente, se utilizan las técnicas MapReduce para lograr esto.
Por otra parte, no se puede hacer una consulta de todos los apellidos que comienzan con la letra S, sino de todos los miembros de un grupo determinado (obtener todos los inscritos de una organización específica). Aquí es donde la indexación y la búsqueda secundaria en un conjunto de datos distribuidos, se convierte en un reto clave.
Los patrones clave de acceso directo en una base de datos de documentos, requieren acceder a los datos a través de una sola clave y navegar a otro documento a través de una clave relacionada. Por ejemplo, puede activar un cierto orden con una identificación de la orden, luego navegar a los datos de los clientes o de la cuenta usando la identificación de la cuenta. A diferencia de una base de datos relacional, es poco probable que un objeto dado esté disperso en varios nodos y que se requiera de una costosa unión en una arquitectura sharded escalable, solo para recrear ese objeto.
Sin embargo, se necesita una clave para acceder a todos los datos a través de índices secundarios, y para buscar los datos que estén distribuidos en el clúster. Usar una técnica MapReduce es una exageración, ya que se requiere la participación de cada uno de los nodos en la ejecución de la búsqueda.
Desafíos futuros
Como industria basada en arquitecturas sharded scale out, necesitamos resolver los patrones de acceso que se requieren para recuperar los objetos relacionados, además de los datos de consulta para soporte a través de la indexación secundaria. Aunque las técnicas de MapReduce han sido útiles en la construcción de la primera generación de soluciones, surgen retos interesantes en la construcción de la siguiente generación de estas innovaciones.
En el campo de los algoritmos distribuidos se ha logrado completar una buena cantidad de trabajo que es relevante para avanzar hacia el procesamiento distribuido de consultas y hacia los optimizadores de consultas para las grandes arquitecturas scale out. El futuro de la gestión de grandes conjuntos de datos va a ver innovaciones importantes en las estrategias de indexación y optimización de búsquedas y consultas.
A pesar de estos desafíos, las arquitecturas scale out están ganando más fuerza todos los días. El scaling out tipo RDBMS se vuelve cada vez menos práctica, ya que el volumen de datos aumenta. Y cuando falla una arquitectura scale out que se encuentra por debajo de un gran conjunto de datos, probablemente se convierta en un gran punto central de falla.
Internet es un clásico ejemplo de clústers de ultrascala y shared nothing; es decir, sistemas distribuidos muy grandes que trabajan en tándem. En muchos aspectos, los sistemas de bases de datos deben aprender de este ejemplo y construir sistemas de bases de datos ultrascalables y distribuidos siguiendo los mismos principios.
New Tech Forum, InfoWorld (EE.UU.)