WSOMBRERO YOSA CLOUD

DATABASE?
La idoneidad de la tecnologa de Algebraix
datos de Cloud Computing

Robin Bloor, Ph D

LIBRO BLANCO

 Copyright 2011, El Grupo de Bloor

Reservados todos los derechos. Ni esta publicacin ni ninguna parte de ella puede ser reproducida o
transmitida o almacenada en cualquier forma o por cualquier medio, ya sea sin el consentimiento previo
por escrito del titular de los derechos de autor o la emisin de una licencia por el titular de los derechos de
autor. El Grupo de Bloor es el nico titular de los derechos de autor de esta publicacin.
22214 Oban unidad Spicewood TX 78669 Te l: 512 - 524-3689

Correo electrnico de contacto:

info@bloorgroup.com w w w. L a V i r t u
a l C i r c l e. c o m
w w w. B l o o r G r o u p. c o m

WHITE PAPER

Resumen Ejecutivo

WSOMBRERO YOSA CFUERTE

DATABASE?

Este documento tcnico fue encargado por Algebraix Datos. El objetivo del documento es
proporcionar una definicin de lo que es una base de datos de la nube es, ya la luz de esa
definicin, examinar la idoneidad de la tecnologa de Algebraix datos para cumplir la funcin
de una base de datos de la nube.
Aqu es un breve resumen de los contenidos de este documento:

Nosotros definir una nube dbms (CDBMS) para ser una base de datos distribuida que
puede ofrecer un servicio de consulta a travs de mltiples nodos de bases de datos
distribuidas ubicados en mltiples centros de datos, incluidos los centros de datos
cloud. Consulta de fuentes de datos distribuidas es precisamente el problema que las
empresas se encontrarn como la computacin en nube crece en popularidad. Dicha
base de datos tambin tiene que ofrecer alta disponibilidad y atender a la recuperacin
de desastres.

En nuestra opinin, una CDBMS slo tiene que proporcionar un servicio de consulta.
SOA ya ofrece conectividad e integracin de sistemas transaccionales, por lo que no
vemos ninguna necesidad de un CDBMS para atender el trfico transaccional - slo
consultar el trfico. Un CDBMS necesita escalar a travs de grandes redes informticas,
sino que tambin tiene que ser capaz de abarcar mltiples centros de datos y, en la
medida de lo posible, atender a las conexiones de red lentas.

Revisamos bases de datos tradicionales, centrndose principalmente en las bases de

datos relacionales y almacenar bases de la columna, concluyendo que dichas bases de
datos, como ingeniera en la actualidad, no podan cumplir con el papel de un
CDBMS. Tienen arquitecturas centralizadas y este tipo de arquitecturas encontraran
un lmite de escalabilidad en algn momento, tanto dentro como entre los centros de
datos. Llegamos a la conclusin de que se necesita una arquitectura de punto a punto
distribuido para satisfacer las caractersticas CDBMS que hemos definido.

Nosotros pasar a examinar el entorno Hadoop / MapReduce y su idoneidad como

CDBMS. Tiene mucho mejor escalabilidad para muchas cargas de trabajo que
almacenar bases de datos relacionales o columna, debido a su arquitectura distribuida.
Sin embargo, no fue construido para cargas de trabajo mixtas o para estructuras de
datos complejas o incluso para la multitarea. En su forma actual hace hincapi en "la
tolerancia a fallos." Tiene xito como base de datos para grandes volmenes de datos,
pero no tiene las caractersticas de un CDBMS.

Finalmente, se analiza la tecnologa de Algebraix datos tal como se aplica en su A2DB

producto de base de datos. Nuestra conclusin es que tiene una arquitectura que es
adecuado para el despliegue como un CDBMS. Nuestro punto de vista es el siguiente:
-

La capacidad nica de A2DB reutilizar resultados intermedios de las consultas que

se ha ejecutado anteriormente, contribuyen a que ofrece un alto rendimiento en un
solo nodo.

Las mismas caractersticas de rendimiento pueden ser empleados para acelerar las
consultas que se unen informacin entre un nodo local y los nodos remotos, ya sea
en el mismo centro de datos o en un centro de datos remoto.
1

WSOMBRERO YOSA CFUERTE

DATABASE?

La tecnologa de Algebraix de datos es capaz de optimizacin global, el equilibrio

de los requisitos de rendimiento de ambas consultas globales y locales.

Adems la tecnologa puede ofrecer alta disponibilidad / operacin con tolerancia a fallos.

Somos conscientes de que Algebraix de datos no se ha implementado y probado su

A2DB base de datos en el papel de CDBMS ah nuestra conclusin no es que califica
como un CDBMS, pero que tiene una arquitectura que le permita a ensayar en este
papel.

La base de datos de la nube - En Concept

La computacin en nube es una importante tendencia de conduccin para TI. Ms del 36 por
ciento de las empresas estadounidenses ya ejecutar aplicaciones en la nube (encuesta
Mimecast, febrero de 2010) y los principales proveedores de la nube estn creciendo sus
ingresos y base de clientes rpidamente. Dadas las tendencias, muy pronto la mayora de los
departamentos de TI va a correr aplicaciones "en la nube", posiblemente usando ms de un
proveedor de la nube. As computacin corporativa inevitablemente convertido en mucho
ms distribuida de lo que actualmente es, que extiendan por mltiples centros de datos. Esta
gestin plantear, desafos arquitectnicos y de rendimiento - y fomentar la innovacin para
hacer frente a esos desafos.

La implementacin de la nube de transaccionales y de consulta Sistemas

Si pensamos nicamente en trminos de tecnologa de base de datos, la distribucin ms
amplia de los sistemas transaccionales, tales como los sistemas OLTP, aplicaciones de
comunicaciones y sistemas de flujo de trabajo, no va a ser un problema grave a nivel de datos.
El xito arrollador de Salesforce.com demuestra. Los problemas con los datos de poner su
sistema de CRM en la nube se resuelven con bastante facilidad por la transferencia regular de
los clientes y otros datos de la nube al centro de datos.
De hecho, el amplio xito de SOA demuestra la misma cosa. Sistemas de transaccin silo
acoplamiento sin apretar juntos funciona bien en cuanto al flujo de trabajo entre los sistemas
transaccionales. Debido a que el volumen de datos que se pasa entre las aplicaciones dentro
de una SOA es baja, es muy poco probable que los relativamente lentas velocidades de
Internet ser prohibitivo para la colocacin de algunas de estas aplicaciones en la nube. Habr
excepciones, pero en principio funcionar bien la mayor parte del tiempo.
Para las cargas de trabajo de consulta tipificados por las aplicaciones de BI, la distribucin de
los datos a travs de mltiples centros de datos es ms problemtico. Hay tres razones
principales para esto:
1. Las velocidades de Internet son generalmente lentos en comparacin con las
velocidades de red de centros de datos y esto limita considerablemente el
rendimiento. Este problema puede abordarse a travs de conexiones directas de alta
velocidad, pero esto se hace caro muy rpidamente.
2. Las cargas de trabajo de consulta no son tan predecibles como las cargas de trabajo
transaccionales. Nosotros puede predecir las cargas de trabajo transaccionales
precisin razonable, pero no podemos predecir fcilmente especficamente lo
cuestiona un usuario podra desear preguntar - por lo tanto, somos menos capaces de
predecir la carga de trabajo. Esto tiene profundas implicaciones arquitectnicas para la
distribucin de los sistemas de consulta. En pocas palabras: no sabemos dnde es
mejor para localizar los datos antes de tiempo, porque no sabemos qu conjuntos de
usuarios de datos pueden desear unirse.
3. Incluso si logramos una distribucin eficiente de los datos, las cargas de trabajo de
consulta implican el movimiento de volmenes mucho mayores de datos que las
cargas de trabajo transaccionales. Ese movimiento de datos ser inevitablemente ms
lento que si los datos se encuentra en un solo centro de datos.
Este conjunto de restricciones sugiere que puede ser mejor para centralizar las cargas de
trabajo de consulta en una ubicacin fsica. Esta es la forma en que tradicionalmente se han
2

construido la mayora de los dominios de BI, alrededor de un almacn de datos grande con
subconjuntos de datos extrados a servir aplicaciones de BI individuales. Pero en ltima
instancia, que el enfoque no pasa la prueba de la escalabilidad. Una arquitectura centralizada
escalas mal sobre un gran nmero de nodos. Los cuellos de botella eventualmente surjan.

TACIA una base de datos de la nube

Por el momento, vamos a dejar de lado el hecho de que hay muchos desafos en la
implementacin de una arquitectura distribuida para cargas de trabajo de consulta mayora de
los centros de datos, y proporcionar una visin de lo que es una base de datos de nube se
vera as.
Nosotros puede definir un DBMS en la nube (CDBMS) como una base de datos distribuida que
proporciona un servicio de consulta a travs de mltiples nodos distribuidos de bases de
datos ubicados en mltiples centros de datos distribuidos geogrficamente, ambos centros de
datos corporativos y centros de datos cloud. As que pensar en trminos de una organizacin
con algunas aplicaciones que se ejecutan en la nube. Quizs Salesforce.com adems de
algunos

Usuario
CDBMS

Datos

Pregunta

Datos
Datos
Datos
Datos

CDBMS
Nodo - 7

CDBMS
Nodo - 1

Datos

Nube Data Center 2

Internet

Nube Data Center 1

CDBMS
Nodo - 2

Datos

CDBMS
Nodo - 3

CDBMS
Nodo - 4

Datos
Datos

CDBMS
Nodo - 5

DataData

Data Center 1

CDBMS
Nodo - 6

Datos
Datos

Data Center 2

Figura 1. Un CDBMS
alojado aplicaciones transaccionales web en algn centro de datos remoto ms aplicaciones
locales, incluyendo las aplicaciones de BI dividen entre dos centros de datos. Esta situacin se
ilustra en la Figura 1. Es la situacin tpica que las empresas tendrn que hacer frente a
medida que avanzamos.
En la prctica, una consulta puede originarse en cualquier parte; desde un PC dentro de la
corporacin, que est conectado por una lnea de rpido acceso al centro de datos local, desde
un PC en el hogar a travs de una lnea de VPN, desde un ordenador porttil a travs de una

conexin Wi-Fi, o desde un telfono inteligente a travs de una conexin 3G o 4G . Por eso
representamos una consulta aqu como viniendo "a travs de Internet" lo que implica que la
respuesta ser, posiblemente, viajar a travs de la red de Internet.
El CDBMS no se concentrar todo el trfico de bsqueda a travs de un solo nodo. Una
arquitectura peer-to-peer ser mucho ms escalable - con cualquier nodo nico capaz de
recibir cualquier consulta. En tales

una disposicin, cada nodo tiene que tener un mapa de los datos almacenados en cada nodo y
conocer las caractersticas de rendimiento de cada nodo. Cuando un nodo recibe una consulta
su primera tarea es determinar qu nodo es ms capaz de responder a la consulta. A
continuacin, pasa la responsabilidad para la consulta a ese nodo. Ese nodo ejecuta la
consulta y devuelve el resultado directamente al usuario.
Figura 1muestra ms de un nodo CDBMS en algunos de los centros de datos. En la prctica,
probablemente ser necesario configurar ms de un nodo por cada centro de datos para
distribuir la carga de trabajo dentro de la base de datos del centro de datos, as como entre los
centros de datos.
Considere la figura 2. Se ilustra
la estrategia probable que sera
utilizado por un nodo CDBMS
en el acceso a los datos
almacenados en bases de datos
o
archivos
transaccionales
locales. Si los datos se llev a
cabo en una base de datos, la
CDBMS puede obtener ya sea
en los datos directamente (a
travs de ODBC, por ejemplo) o
acceder a un almacn de datos
duplicado. Slo ser necesaria
la replicacin si el acceso de
lectura a los datos impone
demasiado grande un impacto
en el rendimiento. Los sistemas
crticos a menudo tienen un
stand- caliente por en su lugar
listo para ir si el
sistema principal falla, en el que
casethestand-bysystems

CDBMS
Nodo x

App
1

App
2

DBMS
Nodo
Dato
s
DBMS
Dato
s

Repl.
Dato
s

Exp
Exedie
ped
nte

Figura 2. Un CDBMS Nodo

base de datos podra ser utilizado como una fuente de datos. Los datos tambin podra ser
tomada de funcionamiento almacenes de datos o almacenes de datos, con el mismo tipo de
estrategia de replicacin que se emplea.
Donde los datos de aplicacin se mantiene en un archivo, el CDBMS probablemente ser
capaz de acceder directamente a los datos. Para los datos no de base de datos, la CDBMS
mantendra un mapa metadatos del archivo para que pudiera identificar a los elementos de
datos en los registros ledos en el archivo.
Por ltimo, el CDBMS mantendr su propia tienda de los datos que constan de datos que se
utilizan con frecuencia extrados de las fuentes de datos a los que accede. sta sera
probablemente la mayor parte de los datos del nodo CDBMS era responsable, con acceso
directo a los almacenes de datos que se utiliza principalmente para la actualizacin de datos.

Datos locales y de datos distribuidos

En el tratamiento de datos locales, el CDBMS acta como un almacn de datos operativos.

Cuenta con datos de seguimiento hasta la fecha y responde a consultas utilizando esos datos.
Mientras que las bases de datos de BI, como un almacn de datos o grande mercado de datos,
se podran incluir, la base de datos de nube podra sustituir en lugar de complementar esos
almacenes de datos.
Ya Est es un problema de escalabilidad aqu. Si consideramos un gran centro de datos con
muchos terabytes de datos, no importa cun eficiente es el nodo CDBMS es, probablemente
no ser capaz de hacer frente a todo el trfico de consultas. En cada centro de datos es
probable que haya varios nodos de base de datos. Y si el trfico de consultas creci, como
suele ocurrir, la CDBMS necesitara para crear instancias de nodos adicionales para manejar la
mayor carga de trabajo.

WSOMBRERO YOSA CFUERTE DATABASE?

Cuando la carga de trabajo se
expande, el nodo A
instancia un nuevo nodo, A '
Red

Ex
pe
die

DBMS
A2

DBMS
A3

Dato
s

Dato
s

A2

A3

CDBMS
Nodo
La

CDBMS
Nodo A
'

Nodo
La
Dato
s

Nodo
A'
Dato
s

DBMS
A4

Dato
s
A4

Ex
pe
die

Figura 3. Base de datos de la nube Nodo Particin

Considere la situacin se ilustra en la Figura 3, donde el nodo A del CDBMS es gestionar las
consultas de archivos A1, A5 y bases de datos A2, A3 y A4. Si la carga de trabajo se vuelve
demasiado grande para los recursos a su alcance, a continuacin, suponiendo que hay otro
servidor disponible para su uso, se podra dividir como una ameba que se indican. El nodo
original podra asumir la responsabilidad de archivo y bases de datos A1 A2 y A3, mientras
que el nodo recin creado A 'asume la responsabilidad de A4 y A5.
Con el fin de hacer esto, el nodo A tendra que tener mantener un historial completo del
trfico de consulta de modo que sera capaz de calcular la divisin ptima ya que divide en
dos. Del mismo modo sera necesario para ser un procedimiento inverso que fusion dos
nodos locales en el caso de que la carga de trabajo de consulta disminuida.
En concepto, que se encarga de las consultas que slo acceden a los datos locales que el nodo
A tiene la responsabilidad de. Sin embargo, no necesariamente habr consultas que abarcan
mltiples nodos.

Consultas distribuidas
Considere las principales entidades que una empresa posee como datos: cliente, producto,
transaccin de venta, miembro del personal, proveedores, transaccin de compra y as
sucesivamente. Ellos surgen en muchas aplicaciones. En consecuencia, muchas consultas que
buscan informacin sobre estas importantes entidades inevitablemente abarcar varios nodos
de una CDBMS. Incluso si pudiramos encontrar una manera conveniente de distribuir y
agrupar las aplicaciones en torno a estas entidades, no habra muchas consultas que se
extendi por varios nodos.
La mayora de las bases de datos de consulta orientada, almacenar bases de columna o bases
de datos relacionales tradicionales, puede ser configurado para atender las consultas de nodo
nico. Tcnicamente, el reto fundamental para la CDBMS es manejar consultas distribuidas de
manera efectiva.
Una consulta distribuida que tiene acceso a mltiples nodos de la CDBMS puede ser pensado
como una fusin (unin) de varias consultas que acceden a diferentes estaciones de una
CDBMS. Esto se ilustra en la figura 4. Obsrvese que la resolucin de una consulta de esta
manera podra dar lugar a ms de un conjunto de resultados de cada nodo como se ilustra.

Una vez calculadas las respuestas, la CDBMS tiene que determinar qu nodo se unirn a ellos
juntos.
5

WSOMBRERO YOSA CFUERTE DATABASE?

El nodo que recibe la
consulta descompone.
Respuesta

Pregunta

Unirse

Sub
Consult
a1

Sub
Consult
a2

CDBMS
Nodo - 2

Sub
Consult
a3

Sub
Consult
a4

CDBMS
Nodo - 5

CDBMS
Nodo - 8

Datos

Datos

Data Center 1

Data Center 2

Datos

Nube
Data Center 1

Respu
esta
SQ-1

Respu
esta
SQ-2

Respu
esta
SQ-3

Respue
sta
SQ-4

El costo de nodo ms
eficaz realiza la
combinacin.

Figura 4. CDBMS: consultas distribuidas

El mejor nodo de elegir es la que es "menor costo" en relacin con el tiempo. Eso puede
depender de muchos factores fsicos, no slo el volumen de datos que se necesita transmitir,
pero las velocidades de red y cunto tiempo tomar cada nodo para llevar a cabo su trabajo.
Incluso podra depender de qu nodo es actualmente ms ocupado. El reto es encontrar la
solucin ms rpida, pero el problema no es trivial.

Otros problemas de base de datos de la nube

Hay otras cuestiones que un CDBMS debe abordar. Una primaria es alta disponibilidad. Esta
es una necesidad ms que un agradable-a-tener. El CDBMS tiene que ser capaz de recuperarse
de la falla de cualquier nodo y, en el extremo, la falta de un centro de datos entero. Sin
embargo, es alcanzable por cualquier base de datos distribuida que es capaz de replicarse sus
nodos.
Hay Tambin los temas tradicionales de seguridad de base de datos y los temas ms amplios
de calidad de los datos y la gestin de datos. Sin embargo, estos no se muestran tapones. El
CDBMS tiene que ser capaz de ensamblar un mapa de metadatos completa de todos los
nodos. Por esa razn, los problemas de seguridad de datos, calidad de datos y de control de
datos pueden ser manejados como si los CDBMS eran una sola base de datos.
Ya Est es tambin la necesidad de proporcionar apoyo para una variedad de interfaces de
acceso de datos. En ltima instancia, estos incluirn las interfaces habituales de SQL (ODBC,
JDBC, ADO.NET), interfaces web de servicios (HTTP, REST, SOAP, XQuery, etc.) y cualquier
otra interfaz especializadas como MDX (para cubos de datos.)
Todas estas caractersticas son a la vez necesaria e importante, pero catering para ellos no es
ah donde radica el principal reto CDBMS. El mayor reto de ingeniera es en la optimizacin

de las cargas de trabajo variadas de consulta a travs de un espacio de recursos ampliamente

distribuidos de una manera que realiza consistentemente bien.
6

WSOMBRERO YOSA CFUERTE

DATABASE?

Puede un tradicional Bases de datos Evolve ser un CDBMS?

Bases de datos surgieron hace ms de 40 aos a causa de las limitaciones de los sistemas de
archivos. Eran un mecanismo ms eficaz para el almacenamiento de datos, por muchas
razones. El principal fue que hicieron los metadatos (datos de definicin de datos) disponible,
por lo que muchos programas diferentes pueden utilizar el mismo almacn de datos. La
situacin mejor an ms con la aparicin de un lenguaje de acceso de datos estndar; SQL.
Esto significaba que, en su mayor parte, el programador ya no es necesario pensar en cmo se
almacenan los datos.
Naturalmente, cuando aparecieron por primera vez las bases de datos, una esperanza surgi
que con el tiempo ser posible almacenar todos los datos de una empresa en una sola base de
datos. Era una esperanza vana.

Relacional Evolucin de base de datos

Bases de datos relacionales (RDBMS) se convirti en el tipo dominante de la base de datos tan
pronto como hardware era lo suficientemente rpido como para permitir su uso para OLTP.
La base de datos relacional se consideraba originalmente como una base de datos ms
apropiado para cargas de trabajo de consulta, y as fue. Pero en el tiempo que fue diseado
para ser adecuado para OLTP.
Una vez que las bases de datos se haban normalizado en torno a un modelo de datos
(relacional) y un lenguaje de acceso (SQL), la esperanza de que sera posible implementar una
nica base de datos corporativa para su uso por todos los programas de fortalecimiento.
Haba muchas razones por qu esto no ocurri. Las ms importantes fueron:

Productos RDBMS podran atender a muchas estructuras de datos diferentes, pero

nunca se ocuparon de cada estructura de datos posible. El modelo relacional no era un
modelo universal de datos y para agravar este problema, SQL no era un lenguaje de
acceso de datos universal que podra acceder a cualquier tipo de estructura de datos.

En la prctica esto significaba que RDBMS era simplemente no aptos para el

almacenamiento de algunos tipos de datos. En concreto, RDBMS no atienden
adecuadamente para muchos tipos de datos importantes (por ejemplo, texto, tipos de
datos compuestos, etc.) Por lo tanto otro tipo de base de datos surgieron (por ejemplo,
las bases de datos de objetos, bases de datos de texto, bases de datos de contenido,
etc.)

A pesar de que RDBMS se basaron en el uso de una estructura de dos dimensiones (la
mesa) nunca se ocuparon de estructuras de una dimensin superior. Esto significaba
que no atienden a los cubos de datos en 3D o cubos de datos de dimensiones
superiores. En consecuencia bases de datos especficas surgieron para hacer frente a
este tipo de estructuras (bases de datos OLAP.) Lo ms importante, RDBMS no
atienden directamente a la dimensin del tiempo y de datos de series de tiempo.

Mientras RDBMS podra servir tanto a las cargas de trabajo OLTP y de consulta, que
nunca tuvo la capacidad de rendimiento para atender a ambos tipos de carga de
trabajo al mismo tiempo. Desde una perspectiva de la ingeniera que hizo mucho ms
sentido tener dos instancias de base de datos, uno que fue configurado para OLTP y
otro, alimentado desde la primera, que fue configurado y ajustado para el trfico de
consultas.

La mayora de los productos RDBMS pagan derechos de licencia, proveedores de

software de manera independiente (ISV) rara vez los utilizan. Pero incluso cuando los
productos RDBMS de cdigo abierto se convirti disponible sin cargo, la mayora de

WSOMBRERO YOSA CFUERTE

DATABASE?

los proveedores de software independientes continuaron haciendo caso omiso de

ellos, prefiriendo sus estructuras de archivos propios.

La industria de TI ni siquiera trat de ponerse de acuerdo sobre un formato de archivo

estndar que expone los metadatos de un archivo. As, los sistemas operativos comnmente
utilizadas nunca proporcionan un tipo tal archivo. Este
7

WSOMBRERO YOSA CFUERTE

DATABASE?

significaba que no haba alternativa para ISVs pero inventar constantemente nuevos tipos de
archivos, e incluso nuevos tipos de datos, por los datos que almacenan.

Esto nos ha llevado a la situacin en la que la industria comenz a aceptar una realidad de facto:

Ya Est fueron los datos estructurados; los datos almacenados en bases de datos con sus metadatos
disponibles.

Ya Est Fue datos no estructurados; los datos contenidos en los archivos de varios
tipos donde estaba disponible o incompletos los metadatos.

Escala y Escalabilidad
A la luz de estas limitaciones, las bases de datos han evolucionado en dos direcciones. Por un
lado, las bases de datos alojados algunos datos no estructurados - por extensiones al modelo
relacional, la implementacin de alguna versin de un modelo objeto-relacional. Por otro lado,
el sueo de una nica base de datos de las empresas continu - pero slo para el trfico de
consultas - dando lugar a la idea del almacn de datos.
En la prctica, los almacenes de datos fueron un intento de ampliar mediante el
almacenamiento de todos los datos en una sola instancia de una base de datos. Pero en la
prctica nunca lo hicieron escalar. De los usuarios primer momento se vieron obligados a
subconjuntos de datos de tiendas en mercados de datos. Centrndose todas las cargas de
trabajo de consulta en el almacn de datos habra paralizado. Debido a las limitaciones del
modelo relacional, algunos de los mercados de datos eran las bases de datos OLAP que
sostienen los cubos de datos multidimensionales.
La impresionante marcha de la Ley de Moore, que vaporiza problemas de rendimiento en
muchas reas de TI, nunca estuvo cerca de solucionar este problema de escalabilidad - y
todava no lo ha hecho. Datos flua de los sistemas operativos, a travs de programas de ETL y
de calidad de datos en un almacn de datos para posterior extraccin en un mercado de datos
para su uso eventual. Este fue un proceso lento. En consecuencia, el software diseado para
atajo esa ruta peatonal surgi, llamada Enterprise Information Integration software (EII).
Herramientas EII crearon "Tiendas datos operativos", que no eran ms que "data marts
acelerados".
RDBMS no escalar y poco esfuerzo se puso en eso. As que cuando la talla de Yahoo y Google
se reunieron grandes centros de datos con miles de servidores, no haba la tecnologa de base
de datos en todo lo que poda escalar a travs de estas grandes redes informticas. Esto dio
lugar a un enfoque completamente diferente a la ampliacin hacia fuera para grandes
volmenes de datos, que fue por el nombre de MapReduce y que dio lugar a Hadoop, un
marco de programacin para la implementacin de MapReduce a travs de grandes redes de
servidores.

La llegada de la Columna tienda

Como idea de base de datos, la tienda columna es muy viejo. Se remonta a la dcada de 1970.
Edward Glaser, desarrollador principal del proyecto MIT MULTICS, propuso por primera vez
la idea y fue utilizado por IBM en una base de datos llamada APLDI. Se volvi a poner de
moda a travs de Sybase and Sand Tecnologa cuando las limitaciones de escalabilidad de las
estructuras de datos indexados que RDBMS utilizados se hicieron ms evidentes. Bases de
datos de columna tiendas volvieron cada vez ms popular entre la aparicin de nuevas
empresas de base de datos de nueva creacin como Vertica y ParAccel que tuvieron este
enfoque.
Las tiendas de las columnas eran RDBMS en el sentido de que emplean SQL como lenguaje de
acceso a datos primarios y que tenan datos en tablas, pero a un nivel fsico que almacenan

WSOMBRERO YOSA CFUERTE

DATABASE?

columnas en lugar de tablas, hicieron gran uso de la compresin de datos y no se usan

ndices. El simple hecho es que, mientras que la velocidad a la cual los datos pueden ser ledos
desde el disco haba sido

WSOMBRERO YOSA CFUERTE

DATABASE?

creciente rpidamente durante los aos, la velocidad del movimiento de la cabeza de lectura /
escritura a travs del disco no haba aumentado mucho. En consecuencia, a travs de ndices
de acceso a los datos en el disco se haba convertido en un pasivo. Caus movimiento de la
cabeza del disco y fren todo. Se haba convertido en mucho ms rpido para leer los datos en
serie desde el disco.

Pregunta

La consulta se
descompone en una
sub-query
para cada nodo

Base de
datos
Mesa

Sub
Consult
a1

Sub
Consult
a2

Server 1

Server 2

La base de datos
columnar escalas
arriba y hacia fuera
mediante la adicin de
ms servidores
Server 3

Los datos se comprimen

despus se reparti en
el disco por columna y
por rango

UPC

UPC

UPC

UPC

UPC

Como
Mucho

Como
Mucho

Memoria
posible

Memoria
posible

Data
D
Data
D ata
D
ata
Datos
ata

Data
D
DDD
ataata
Datos
ata
ata

UPC

Como
toda la
memoria
posible

Data
D ata
DDD
Datos
ataata
ata

Figura 5. Columna DBMS Tienda Escalabilidad

Esto dio lugar a la escalabilidad enfoque se ilustra en la Figura 5. Esto representa el enfoque
general de los DBMS tienda columna a la escalabilidad. En primer lugar, los datos se
comprimen cuando se carga, lo que resulta en un volumen mucho ms pequeo de los datos una vigsima parte de los datos en bruto original es alcanzable. A continuacin, los datos se
almacenan en columnas. Las columnas tambin pueden ser divididos entre los discos y entre
servidores. Esto asegura un buen paralelismo. Una consulta puede tener que leer la totalidad
de una columna de una tabla, por ejemplo, por lo que si la columna se divide entre 12 discos
que se dividen entre dos servidores, entonces la recuperacin de datos puede ser 12 veces ms
rpido.
Por otra parte, los servidores lo ms probable es ser configurados para un alto nivel de
memoria de modo que una buena parte de los datos ya estn en la memoria. Los algoritmos
de cach probablemente se repartirn una buena cantidad de la memoria en partes iguales

WSOMBRERO YOSA CFUERTE

DATABASE?

entre los discos para "equilibrar la carga de trabajo promedio." Adems de esto, varios
procesos se ejecutan y que sern distribuidos entre mltiples ncleos en la CPU en cada
servidor.

WSOMBRERO YOSA CFUERTE

DATABASE?

El rendimiento global de la tienda columna DBMS depender de lo bien que el software

equilibra la carga de trabajo cuando se procesan varias consultas. Esta solucin tiene la ventaja
de que usted puede simplemente aadir ms servidores ya que el volumen de datos se
expande y el equilibrio de la carga de trabajo entre 3 y luego 4 y luego 5 servidores
normalmente funciona bien. Esta solucin escalas a cabo en varios servidores con ms eficacia
que el RDBMS tradicional - que es precisamente por eso que se ha vuelto popular.

Por desgracia, llegar a un lmite en algn momento. Es evidente que ese lmite depender de
la estructura de los datos y la variedad de consultas que se est procesando. A pesar de que se
escala a cabo de manera ms eficaz, todava es una arquitectura centralizada. A medida que la
carga de trabajo aumenta un cuello de botella de mensajera desarrollar de forma natural en
el nodo principal de la base de datos de almacn de la columna y en ltima instancia, lo que
limita el nmero de servidores que puede ampliar en.

Hadoop y Mapa / Reducir: una arquitectura distribuida

El marco de desarrollo Hadoop MapReduce para ha atrado una gran atencin por dos
razones. En primer lugar, no escalar a cabo a travs de grandes redes de ordenadores y en
segundo lugar es el producto de un proyecto Open Source, por lo que las empresas pueden
probarlo a bajo costo. MapReduce es una arquitectura paralela diseada por Google
especficamente para la bsqueda y anlisis de datos de escala grande. Es muy escalable y
obras
de una manera distribuida. El
MapPartitionCombineReduce
entorno Hadoop es un marco
MapReduce que permite la BackUp
/
adicin de componentes de
Recov
Programa
software de Java. Tambin
dor
BackUp
proporciona HDFS (el sistema
/ Recov
Nodo i + 1
de
archivos
distribuidos
Proceso
Hadoop) y se ha ampliado
de
para incluir HBase, que es
Reducci
BackUp
una especie de base de datos
/ Recov
de almacn de columnas.
Figura
6muestra
cmo
Nodo 1
Hadoop
trabaja. Bsicamente, una
asignacin
de
funcin
particiones de datos y luego
se lo pasa a una funcin de
reduccin, que calcula un
resultado. En el diagrama que
mostramos muchos nodos
(servidores) con nodos 1 a i
que ejecutan el proceso de
asignacin y los nodos i
1 a k ejecutar el proceso de
reduccin. El medio ambiente
es (diseada para recuperarse
del fracaso de cualquier nodo.
El HDFS mantiene una copia
redundante de todos los

datos
, por
lo
que
si un
nodo
falla,
los
mis
mos
datos
estar

disp
onibl
e a

Procesotravs
de
Asignacde otro

HDFS

BackUp
/ Recov

Nodo yo
Proceso
de
Asignaci

HDFS

Proceso
de
Reducci

Nodo j

Nodo k

WSOMBRERO YOSA CFUERTE

DATABASE?
BackUp
/ Recov
Proceso
de
Reducci

BackUp
/ Recov

Figura 6. Hadoop MapReduce y

10

WSOMBRERO YOSA CFUERTE

DATABASE?

nodo. Cada servidor registra lo que est haciendo y se puede recuperar utilizando su archivo
de respaldo / recuperacin, si falla. Debido a eso, Hadoop / MapReduce es bastante lento en
cada nodo, pero compensa esta escalando a lo largo de miles de nodos. Se ha utilizado de
manera productiva en las redes de ms de 5.000 servidores. Fallo de nodo es un hecho
cotidiano cuando se tiene que muchos servidores bsicos trabajando juntos, por lo que a esa
escala, su recuperabilidad es una ventaja.

Con MapReduce, todos los registros de datos consiste en un sencillo par "clave y valor". Un
ejemplo podra ser un archivo de registro, que consiste en cdigos de mensajes (la clave) y los
detalles de la condicin que est siendo informado (el valor). En aras de ilustrar el proceso de
MapReduce, imaginemos que tenemos un archivo de registro de gran tamao de muchos
terabytes contienen mensajes y cdigos de mensaje y simplemente queremos contar cada tipo
de registro de mensaje. Se podra hacer de la siguiente manera:
El archivo de registro se carga en el sistema de archivos HDFS. Cada nodo mapeo leer algunos de los
registros. Los cartgrafos se ver en cada registro que leen y salida de un par de valores clave que
contiene el cdigo del mensaje como la clave y "1" como el valor (el recuento de citas). El reductor (s) se
ordenar por la llave y agregar los conteos. Con repetidas reducciones eventualmente llegar al
resultado; un mapa de teclas distintas con sus recuentos totales de todas las entradas.
Aunque este ejemplo es muy simple, si tuviramos una mesa muy grande hecho del tipo que
podra residir en un almacn de datos, podramos ejecutar consultas SQL de la misma
manera. El proceso de la hoja sera el SELECT de SQL y el proceso de reducir simplemente
podra ser la seleccin y combinacin de resultados. Usted puede agregar cualquier tipo de
lgica que sea el mapa o la de reducir el paso y usted tambin puede tener un mapa mltiple
y reducir los ciclos de una nica tarea.
Tambin, mediante el despliegue de HBase que es posible tener una gran base de datos de la
columna de la tienda masivamente paralelo que preside petabytes de datos y ms de lo que
pueden ser actualizados con regularidad.
La CDBMS
En ltima instancia, ni almacenar bases de datos de columna ni Hadoop (con Hbase)
actualmente tienen las capacidades necesarias para funcionar como un CDBMS.
Columna-tienda DBMS son (en la mayora de los casos) las bases de datos centralizadas que
se encontrar con lmites de escalabilidad como volmenes y cargas de trabajo de datos de
aumento. En ltima instancia, todas las arquitecturas centralizadas sufren ese destino no
importa cun esplndida la ingeniera subyacente. Por eso algunos de los vendedores
columna tiendas estn integrando con Hadoop y la mejora de varias maneras.
Debido Hadoop ofrece un entorno totalmente distribuida es poco proclive a encontrar un
lmite escalabilidad del tipo que hara piso una arquitectura centralizada. Hadoop fue
deliberadamente diseado para presidir mesas masivas y, en ese papel, puede ser til,
especialmente para aquellas organizaciones que se ejecutan en los lmites de escalabilidad con
bases de datos de almacn de columnas. Sin embargo, en su forma actual se procesa una sola
carga de trabajo a la vez - que no tiene capacidad de multiprocesamiento en absoluto.
Adems, no funciona bien con estructuras de datos complejas, incluso cuando slo contienen
datos estructurados. Grandes mesas, "s"; pero un montn de pequeas mesas de gran
cantidad de bases de datos de todos con diferentes estructuras de datos, decididamente "no".
Tampoco est equipado Hadoop para distribuir fcilmente las cargas de trabajo a travs de
redes complejas que funcionan a distintas velocidades. Hadoop espera un ambiente limpio de
servidores de tamao similar todos conectados en red a la misma velocidad de una manera
ordenada. Su ingrediente secreto es la homogeneidad en todo lo que hace.

WSOMBRERO YOSA CFUERTE

DATABASE?

A CDBMS tiene que ser capaz de manejar la heterogeneidad en cada nivel.

11

Algebraix Base de datos de datos y la nube

WSOMBRERO YOSA CFUERTE

DATABASE?

A2DB de Algebraix de datos es, nicamente, una base de datos algebraico. Como tal, es capaz
de representar cualquier tipo de datos en una forma algebraica y gestionar en consecuencia.
Muchas bases de datos (RDBMS y productos derivados) estn limitadas por el modelo
relacional de datos, incapaz de manejar los datos que no encajan en ese entorno limitado.
A2DB no est limitado de ese modo. Su naturaleza algebraica le permite representar
jerarquas, listas ordenadas, estructuras de datos recursivas y objetos de datos compuesto de
ningn tipo. (Para una explicacin matemtica ms detallada de cmo se logra esto, lee el
libro blanco Bloor Grupo: Hacer las matemticas).

Algebraico Optimizacin y el uso de los resultados intermedios

A entender cmo la tecnologa de Alegbraix datos podra implementar un CDBMS, es
necesario entender la estrategia de optimizacin que aplica. Las tiendas de productos A2DB
todos los conjuntos se calcula, incluyendo todos los conjuntos de resultados intermedios para
su posible reutilizacin.
Considere una consulta bastante simple que accede a algunas filas y columnas de una tabla y
luego se une a ellos a algunas filas y columnas de otra tabla. La mayora de las bases de datos
seleccionarn los datos de la primera tabla, seleccinelo de la segunda tabla y luego unir las
dos tablas resultantes juntos para proporcionar la respuesta. A2DB se comporta de la misma
manera, pero con el matiz adicional que almacena la primera seleccin y la segunda seleccin
y el resultado unido, para su posible uso posterior. Si las consultas posteriores hacen la misma
seleccin o hacer una seleccin de un subconjunto de cualquiera de las dos selecciones
almacenados, entonces A2DB reutilizar esos resultados. Una vez A2DB ha procesado
muchas consultas que ha reunido a un razonablemente grande poblacin de estos resultados
intermedios.
No slo almacenar cada una de esas conjunto de datos, tambin almacena su representacin
algebraica. As que cuando se procesa una consulta nueva, simplemente examina su tienda de
representaciones algebraicas y selecciona aquellos que pueden contribuir a la resolucin de la
consulta. A continuacin, se resuelve que de ellos tiene el menor costo en trminos
de los recursos de uso,
y
utiliza
esos
conjuntos
para
resolver la consulta.
La grfica adyacente
ilustra
cmo
el
desempeo de A2DB
mejora
cuando
el
mismo
tipo
de
consulta se repite.
La primera vez que se
ejecuta una consulta,
la respuesta es lenta.
Pero mejora con cada
repeticin hasta que el
tiempo de respuesta
cae a un nivel muy
bajo. Esto sucede con
toda

tipos de consulta. El
uso

WSOMBRERO YOSA CFUERTE

DATABASE?
Figura 7. Las curvas de rendimiento A2DB Optimizer

12

WSOMBRERO YOSA CFUERTE DATABASE?

Consultas
Consult
asConsult
as

Fuentes de
datos

Aplica
Aplica
Aplic
ciones
ciones
acio
nes

Expe
Expe
Expediente
dient
dient
ee

Arc
Arc
Arc
Arc
hivo
hivo
hivo
hivo
de
ssde
de
ssregi
de
regi
regi
regi
stro

Carg
Carg
Carg
Carg
ar
ar
ar
ar
archi
archi
archi
archi
vos
vos
vos

Universo
Gerente

XSN
Traductor

(Modelo
algebraic
o)

Administra
dor de
recursos

Optimizer

(CPU /
ncleos,
memoria,
disco)

LGICO

Acceso
Local

Conjunto
Procesad
or
Storage
Manager

Resultado Local Conjuntos

resultados remotos

Conjuntos de

FSICA

Respuest
as
Respue
stas

De
acceso
remoto

Mgt
datos

CDBMS
Nodo
yo

CDBMS
Nodo k

CDBMS
Nodo j

CDBMS
Nodo l

Aplica
Aplica
Aplica
Aplicaciones
ciones
ciones
ciones

DDBBM
MSS
DDBBM
MSS

DBMS
DBMS
DBMS
DBMS
Dato
Datos
Dato
Dato
s
ss

Local
Data Center

A
distancia
del Centro
de Datos

Figura 8. Tecnologa de Algebraix de datos en una operacin distribuida

de conjuntos de resultados intermedios resulta valioso en un entorno distribuido y un
entorno de nube. La Figura 8 ilustra esto. La arquitectura distribuida es peer-to-peer, por lo
que podra ser muchos de estos nodos, incluso miles - de todo el funcionamiento de la misma
manera. A la izquierda del diagrama son las fuentes de datos que este nodo en particular
toma la entrada desde y es responsable. Con el fin de cargar el nodo de base de datos slo es
necesario para crear archivos de carga de las bases de datos fuente. La base de datos no se
carga inmediatamente los datos, slo carga los metadatos de esos archivos. La forma en que la
tecnologa funciona es que no hay carga de datos per se. Como consultas llegan se hace
referencia a los archivos de carga (o archivos u otros archivos de datos de registro) y se
acumula gradualmente conjuntos de resultados intermedios, que constituyen su almacn de
datos administrados - como se ilustra.
Utiliza mecanismos fsicamente eficientes para almacenar estos datos, las mismas tcnicas que
la base de datos tpica tienda de la columna; sin ndices, compresin de datos y particin de
datos. Hay una separacin completa entre la representacin lgica de los conjuntos de datos
almacenados y el almacenamiento fsico de los conjuntos de datos. Funciona de la siguiente
manera:

El XSN traductor traduce una consulta en una representacin algebraica que se corresponde
con los conjuntos algebraicos definidos a nivel lgico en el Administrador Universo. (XSN
significa Extended notacin Set.) El Gerente Universo tiene un modelo lgico de todos los
conjuntos de la base de datos y sus relaciones.
El Optimizador trabaja primero qu conjuntos almacenados podran participar en una
solucin. Se puede deducir que tiene que ir a la fuente de datos (archivos de carga) para la
totalidad o parte de los datos solicitados por la consulta.
13

WSOMBRERO YOSA CFUERTE

DATABASE?

En cualquier caso, la bsqueda de alternativas producir una o ms soluciones posibles. El

Optimizador ahora asesora al Administrador de recursos y pone a prueba cada una de sus
soluciones algebraicas contra informacin fsica realizada por el Administrador de recursos.
Armado con informacin precisa de costos, el optimizador resuelve el costo fsico de cada
solucin algebraica y elige el ms rpido. El Administrador de recursos sabe si los datos est
en el disco o en la memoria cach y sabe cmo se organiza fsicamente. Una vez que el
optimizador ha decidido por una solucin, que pasa al conjunto de procesadores, que lo
ejecuta.

La consulta distribuida
Ahora considere lo que ocurre si la consulta pide algunos datos que no est en este nodo de
base de datos. Cmo sabe qu hacer? Por su diseo, el Administrador Universo no slo
contiene un mapa de datos locales, sino que tambin tiene un mapa mundial que identifica a
todos los dems nodos de bases de datos y los datos que son responsables.
Cuando describimos cmo la base de datos maneja una consulta, omitimos para discutir la
forma en que maneja una consulta que se extiende por ms de un nodo. Dicha consulta ser
naturalmente implicar una combinacin de algn tipo con una o ms partes de la operacin
de unin referencia a datos remotos.
El modo de funcionamiento de la tecnologa de Algebraix de datos es esencialmente el
mismo, pero ligeramente ms complejo. El Optimizador siempre comprueba para ver si
alguno de los datos solicitados es parte del "universo remoto" en lugar de "universo local." Si
se descubre que algn elemento en los datos remotos referencias de consulta, que deconstruye
la consulta en varias partes, como de la siguiente manera:

Una subconsulta de este nodo

Una subconsulta para cada nodo remoto que est involucrado

Una consulta principal que une todos los resultados de todas las subconsultas

Se calcula qu nodo es el mejor nodo para ejecutar la consulta maestra mediante la estimacin
del costo de los recursos de transporte de datos de resultados desde un lugar a otro. Si decide
pasar esa responsabilidad a otro nodo entonces se comporta de la siguiente manera:

Pasa el resto de subconsultas a los nodos donde tienen que ejecutar.

Tambin informa a cada nodo en el que para entregar el resultado de su subconsulta.

A continuacin, ejecuta su propia subconsulta y pasa el resultado al nodo principal

cuando el procesamiento local completa. En ese momento se ha terminado con esa
consulta.

Si se ha determinado que es, en s, el mejor nodo para ejecutar la consulta maestra, se

comporta de la siguiente manera:

Pasa el resto de subconsultas a los nodos donde tienen que ejecutar.

Se da a s misma como la direccin de retorno de los resultados de esas subconsultas.

Se ejecuta su propia subconsulta.

Cuando se recibe todos los conjuntos de resultados remotos, ejecuta la consulta maestra.

Finalmente se distribuye el resultado final al programa que envi la consulta.

Tenga en cuenta que en la realizacin de una consulta como la base de datos distribuida rene
algunos conjuntos de resultados remotos en el nodo que domina la consulta distribuida. Se
ahorrar estos resultados como "nmero remoto

WSOMBRERO YOSA CFUERTE

DATABASE?

14

WSOMBRERO YOSA CFUERTE

DATABASE?

conjuntos "de la misma manera que se ahorra conjuntos de resultados locales, de modo que
cuando ms bsquedas de ese tipo venir en ella pueden ser capaces de resolver esas consultas
localmente en lugar de en una manera distribuida.

Conmutacin por error

Con Hadoop, el fracaso de cualquier nodo pueden ser atendidas. Lo mismo es cierto de la
tecnologa de Algebraix de datos. Es bastante fcil de configurar espejos de nodos completos
para que un nodo en espera puede hacerse cargo de inmediato si un nodo activo falla. Sera
sin embargo econmico ms utilizar una SAN en cada centro de datos, y slo los datos de
espejo que se escriben en el disco (los resultados intermedios). Entonces, si un nodo falla, ser
posible recuperar el nodo de la SAN. Esto inyecta un mayor retraso en el proceso de
recuperacin, ya que la base de datos recuperada tendra que recrear el ltimo estado
conocido del nodo que ha fallado.
En la prctica, la tecnologa de Algebraix datos puede ejecutarse en servidores de los
productos bsicos. Aunque puede parecer que tiene un requisito sustancial para el
almacenamiento de datos, a causa de su estrategia de almacenar resultados intermedios, en la
prctica esto no es el caso. Esto se debe a que, una vez transcurrido un tiempo adecuado, la
base de datos elimina los resultados intermedios que no vuelva a utilizar. La base de datos
rara vez requiere el despliegue de almacenamiento adicional (como NAS o un SAN). Para
cargas de trabajo atpicas configuraciones especiales se pueden implementar para cualquier
nodo dado.

La divisin de nodos
La divisin de nodos resulta necesario cuando la carga de la consulta para un nodo se vuelve
demasiado grande. La necesidad se hace evidente cuando el rendimiento del nodo comienza
a declinar. Sin embargo, la divisin de nodos es fcil de lograr:
Un nodo de rplica se crea del nodo y las fuentes de datos que el nuevo nodo ser responsable
de se definen - eliminando aquellos que no ser responsable de desde el Administrador
Universo. La tecnologa puede estimar lo que es probable que sea de un anlisis de las cargas
de trabajo de consulta ltimos la mejor divisin. Tambin puede reconocer que los resultados
intermedios se derivan de que los archivos de origen o bases de datos. As que reclasifique
esos resultados intermedios como a distancia en lugar de local. La configuracin del nodo
original est configurado de la misma manera, la eliminacin de las fuentes de datos que ya
no es responsable. La naturaleza de los cambios estn a continuacin, transmite a todos los
nodos de la CDBMS.

Crecimiento de Datos
La mayora de los datos de origen consistirn en bases de datos que son a su vez que se aade
a sobre una base regular. Ese crecimiento de los datos es mejor tratado por la alimentacin de
las imgenes de archivo de registro de base de datos a la base de datos. Para otras aplicaciones
que simplemente utilizan sistemas de archivos, es mejor para alimentar el equivalente de una
pista de auditora para la actualizacin de la base de datos. Hay una razn especfica para ello.
La tecnologa de Algebraix datos no est pensado para los datos actualizados de la manera
ms bases de datos hacen.
Typically, actualizaciones de la base de destruir datos sobre-escritura de un valor a otro. Esta
tecnologa de base de datos es diferente. Se trata actualizaciones como (es decir nuevo) datos
adicionales. En efecto, se convierten en cambios no destructivos, con un registro de los valores
previos restantes. Para borrado, simplemente marca el conjunto de datos o un elemento de

WSOMBRERO YOSA CFUERTE

DATABASE?

datos como "ya no es actual." Para lograr esto, la base de datos aade una marca de tiempo a
todos los datos, ya que llega y se utiliza (si un sello tal vez no existe en los datos de origen.)
Todas las consultas a la base de datos especificar el momento en que se aplica, por lo que el
resultado tiene una "correspondiente a la fecha / hora" u omitir el tiempo, en cuyo caso la
corriente

15

WSOMBRERO YOSA CFUERTE

DATABASE?

se aplica fecha y hora. As que todos los cambios se tienen en cuenta cuando los datos
asociados se procesa de acuerdo con sello de tiempo. Debido a esto, todas las tablas de
resultados intermedios tambin tienen un "correspondiente a la fecha / hora" asociados con
ellos.
La base de datos est configurado en cada nodo para aceptar los nuevos datos sobre la base de
un interruptor temporizado. No es aconsejable colocar el interruptor de tiempo para un
perodo demasiado corto ya que esto aumenta rpidamente el nmero de juegos en poder del
Administrador Universo - y esta actuacin, a su vez, podra afectar.

La Economa de A2DB
En cualquier base de datos y, sobre todo, en cualquier base de datos distribuida, siempre es
posible plantear preguntas que tendrn mucho tiempo para responder. Esta tecnologa no
tiene ese problema de repente desaparece. Por ejemplo si se inscribe en dos mesas con
terabytes juntos que estn en diferentes nodos, un terabyte de datos debe pasar a travs de la
red. Si se trata de una lnea de red lenta, la consulta podra tomar un tiempo muy largo. Si
una consulta de este tipo se pasan con frecuencia, la base de datos va a resolver este problema
de rendimiento determinado de forma natural por la celebracin de una de las mesas terabyte
como un resultado intermedio.
Si usted tiene un petabyte o incluso varios petabytes de datos que desea consultar
regularmente, entonces la base de datos podra ser utilizado para la tarea por su despliegue
de un nmero suficiente de nodos. En tales circunstancias, podra parecer muy similar a
Hadoop (con HBase). Sin embargo ese no es el requisito primordial de un CDBMS. Un
CDBMS tiene que ser capaz de manejar cargas de trabajo heterogneas algunos de los cuales
tienen acceso a las estructuras de datos complejas, y hay que hacerlo con la economa y con la
velocidad. Eso es lo que hace la tecnologa de Algebraix Datos.
En el entorno distribuido es ayudado por el hecho de que los usuarios y los programas que
solicitan datos normalmente no plantean preguntas que tienen respuestas terabytes de largo.
Plantean preguntas que tienen respuestas muy cortas - unos pocos megabytes o menos. Una
excepcin es cuando los usuarios estn descargando un extracto de datos de gran tamao
para un anlisis ms detallado, pero este tipo de descargas son relativamente raros.
Este enfoque distribuido tiene la virtud de que se localiza de forma natural datos para
adaptarse al trfico de consultas. En cada nodo se localiza los datos que se consulta con
frecuencia en la memoria. En un entorno distribuido con mltiples nodos que ser, a travs de
sus mecanismos de funcionamiento natural, localizar gradualmente los datos para adaptarse
al trfico de consultas locales y globales. Si los volmenes de consulta se elevan demasiado a
un determinado nodo, el nodo puede dividir como una ameba para atender la carga de
trabajo en aumento.
Si el trfico de consultas cambia con, por ejemplo, un tipo de consulta no se plantea con tanta
frecuencia y un nuevo conjunto de consultas previamente desconocidos cada vez ms comn
la base de datos slo tiene que ajustar, mediante el ajuste de los resultados intermedios que
contiene. Despus de tres o cuatro preguntas de cada nuevo tipo de consulta ser restablecido
su funcionamiento natural.
La naturaleza de esta tecnologa, junto con el hecho de que puede ser configurado para alta
disponibilidad, lo califica como adecuado para el despliegue como un CDBMS.

WSOMBRERO YOSA CFUERTE

DATABASE?

16

WSOMBRERO YOSA CFUERTE

DATABASE?

Sobre el Grupo de Bloor

El Grupo de Bloor es una empresa de consultora, investigacin y analista de la empresa que se
centra en la investigacin y el anlisis de las nuevas tecnologas de la informacin en todo el espectro
de la industria de TI de calidad. La investigacin de la firma se centra en la comprensin tanto de las
caractersticas tcnicas y el valor de negocio de las tecnologas de la informacin y la forma en que se
implementan con xito dentro de los entornos informticos modernos. Informacin adicional sobre El
Grupo Bloor se puede encontrar en www.TheBloorGroup.com y www.TheVirtualCircle.com. El Grupo
de Bloor es el nico titular de los derechos de autor de esta publicacin.
22214 Oban unidad Spicewood TX 78669 Te l: 512 - 524-3689

w w w. L a V i r t u a l C i r c l e. c o m w
w w. B l o o r G r o u p. c o m
17