NoSQL vs. NewSQL

Abel Arce, Carlos Avilán y Krystle Salazar

Agosto de 2015

Universidad Central de Venezuela

Facultad de Ciencias

Escuela de Computación

Bases de Datos NoSQL

2

Tabla de contenido

Introducción ............................................................................................................................... 3

Antecedentes .............................................................................................................................. 4

NoSQL ........................................................................................................................................ 6

NewSQL ...................................................................................................................................... 7

Características .......................................................................................................................... 7

Arquitectura ............................................................................................................................. 8

Clasificación .......................................................................................................................... 10

Casos de estudio ....................................................................................................................... 14

Google Spanner ...................................................................................................................... 14

NuoDB ................................................................................................................................... 17

VoltDB ................................................................................................................................... 18

Conclusiones ............................................................................................................................. 21

Referencias Bibliográficas ...................................................................................................... 22

3

Introducción

En los últimos años han surgido nuevos tipos de bases de datos impulsadas por

diversas razones, entre las más importantes se encuentra el auge de la internet y los teléfonos

móviles inteligentes que han promovido la producción de una inmensa cantidad de datos y

aplicaciones que exigen mayores requisitos día a día.

El primer movimiento que surgió fue llamado NoSQL, para referirse a sistemas que no

siguen el modelo relacional y proporcionan escalamiento sencillo, con mayor rendimiento que

los sistemas de bases de datos tradicionales. Estos sistemas han sido desarrollados por las

principales compañías de Internet, como Google, Amazon, Facebook y Twitter, que han

tenido que enfrentarse a desafíos que los sistemas tradicionales ya no podían solucionar. Se

dieron cuenta cuenta que en algunos casos el rendimiento, y sus propiedades en tiempo real

era más importante que la coherencia, a la cual las bases de datos relacionales tradicionales

dedicaban una gran cantidad de tiempo de proceso.

NoSQL resolvió algunos de estos problemas, sin embargo, aún quedaban aplicaciones

que no podían renunciar a las propiedades ACID por las garantías de consistencia débil

(propiedades BASE) de NoSQL y necesitaban de igualmente de poder escalar. Así surge

NewSQL, un movimiento que está apenas en sus inicios pero tiene como objetivo suplir los

puntos débiles de NoSQL manteniendo todas sus ventajas.

En lo sucesivo estaremos dando más detalle de qué traen consigo estos movimientos,

cuáles son las características de los nuevos tipos de bases de datos haciendo una comparación

de las mismas con los SMBD tradicionales, y mostraremos algunos casos de estudio del

último tipo (NewSQL).

4

Antecedentes

Históricamente, el procesamiento de transacciones en línea (OLTP) era realizado por

clientes que presentan las transacciones tradicionales para un SMBD relacional. Las grandes

empresas pueden tener decenas a cientos de estos sistemas. Invariablemente, las empresas

querían consolidar la información en estos sistemas OLTP para el análisis del negocio, venta

cruzada, o algún otro propósito. Por lo tanto, procesos de Extracción-Transformación-y-Carga

(ETL) eran utilizados para convertir los datos OLTP a un formato común y cargarlos en un

almacén de datos. La actividad del almacén de datos rara vez compartía recursos de máquina

con el OLTP debido a la contención de bloqueo en el SMBD y porque las consultas de

inteligencia de negocios (BI) eran tan de recursos-pesados que se interponían en la entrega de

respuestas oportunas a las transacciones. (Stonebraker, 2011).

Esta combinación de un conjunto de sistemas OLTP, conectados a procesos ETL, y

conectados a uno o más almacenes de datos es el estándar de oro en la informática

empresarial. Sin embargo, como se ha podido apreciar, el auge de Internet ha cambiado los

requisitos de los OLTP, aunado a otras razones como mejoras en el desarrollo de hardware,

con discos duros más rápidos, más baratos y más grandes, el surgimiento de nuevas

tecnologías de almacenamiento, los discos duros de estados sólido, a la par que se han

desarrollado mejores procesadores. Son estos avances de hoy en día los que abren las puertas

un abanico de posibilidades.

Los sitios web con el nuevo tipo de sistemas parecen estar impulsados por dos

requisitos del cliente:

i. La necesidad de mucho más rendimiento OLTP. Considere la posibilidad de

nuevas aplicaciones basadas en la Web, tales como juegos de multijugadores, sitios de redes

5

sociales y redes de juego en línea. El número total de interacciones por segundo se ha

disparado por las páginas web de éxito en esta categoría. Además, el crecimiento explosivo de

los teléfonos inteligentes ha creado un mercado para las aplicaciones que utilizan el teléfono

como un sensor geográfico y prestan servicios basados en la localización. Una vez más, las

aplicaciones exitosas están experimentando un crecimiento explosivo en los requisitos de

transacción. Por lo tanto, la web y los teléfonos inteligentes están impulsando el volumen de

interacciones con un SMBD hasta el techo, y los desarrolladores de los nuevos sistemas OLTP

necesitan mucho mejor rendimiento y escalabilidad mejorada en los SMBD.

ii. La necesidad de análisis en tiempo real. Entremezclado con una ola de cambios

está la necesidad de una capacidad de consulta. Por ejemplo, un sitio Web quiere saber el

número de usuarios actuales jugando su juego, o un usuario de smartphone quiere saber "¿Qué

hay a mí alrededor?" Estas no son las típicas peticiones de BI a datos consolidados, sino más

bien consultas en tiempo real a datos actuales. Por lo tanto, el nuevo OLTP requiere una

capacidad de consulta en tiempo real.

Por lo que se espera que el Nuevo OLTP sea un área de aplicación sustancial,

impulsada por las aplicaciones web como las primeras en adoptarla, pero seguidas de los

sistemas empresariales.

En la actualidad han surgido nuevos tipos de bases de datos para suplir estas

necesidades, que en lo sucesivo iremos explicando y comparando.

6

NoSQL

Ha habido una variedad de nuevas empresas en los últimos años que se hacen llamar

vendedores NoSQL (Negando querer toda relación con SQL al principio para luego pasar a ser

“Not only SQL” -No solo SQL- abriendo la posibilidad de integrarlo). La mayoría afirman

ofrecer escalabilidad extrema y alto rendimiento, logrado a través del relajamiento o la

eliminación del soporte de transacciones y de regresar a una interfaz de SMBD de bajo nivel,

eliminando de este modo SQL.

Estos vendedores tienen graves problemas cuando se presentan con los nuevos

sistemas OLTP. En primer lugar, los sistemas empresariales manejan datos de alto perfil que

quieren ACID real. Reemplazando el ácido verdadero con ningún ACID ó "ACID lite"

simplemente lleva los problemas de consistencia a las aplicaciones, en donde son mucho más

difíciles de resolver. En segundo lugar, la ausencia de SQL hace que las consultas lleven

mucho trabajo, la falta de un estándar implica realizar inversiones extra en capacitación

humana para manejar los distintos lenguajes de las bases de datos NoSQL y hace casi

imposible realizar migraciones entre los distintos sistemas manejadores.

Sin embargo se ha visto que estas bases de datos han tenido una buena acogida en

aplicaciones específicas. Resultan ser especialmente apropiadas para sistemas no

transaccionales o para registrar transacciones individuales que son conmutativas, es decir, que

no importa el orden de ejecución de las transacciones, el resultados siempre será el mismo.

Entonces, debido a las carencias que presenta NoSQL para los nuevos sistemas de

OLTP surgen los sistemas NewSQL, una evolución natural.

7

NewSQL

El término fue usado por primera vez por el analista Matthew Aslett de The 451 Group

en el reporte “How will the database incumbents respond to NoSQL and NewSQL?”,

refiriéndose a sistemas modernos de manejo de bases de datos relacionales que tratan de

conseguir el mismo rendimiento escalable de sistemas NoSQL para el procesamiento de

transacciones en línea, manteniendo las propiedades ACID de un sistema de base de datos

tradicional.

En ese reporte también exponen una de las razones del surgimiento de esta nueva ola

de SMBD: la compra de MySQL, la principal base de datos de código abierto enfocada a

aplicaciones web, por Oracle, en el año 2009. En el reporte señalan que MySQL era la joya de

la corona de las bases de datos de código abierto gracias a su enfoque en las aplicaciones

web, su arquitectura ligera y sus capacidades de lectura rápida, lo que le daba un potencial

complemento tecnológico frente a todos los otros vendedores bases de datos establecidos

(Oracle, IBM, Hewlett-Packard, etc.). No es secreto tampoco que grandes empresas como

Facebook, Twitter y Google implementaran esta base de datos para sus operaciones en la web,

hasta la adquisición de la misma por Oracle, esto deja un vacío en el mercado, que luego

empieza a ser inundado con nuevas bases de datos de código abierto, arquitectura ligera

enfocadas en la web, buscando suplir esa necesidad.

Características

Según Stonebraker (2011) para que un SMBD sea considerado NewSQL debe cumplir las

siguientes características:

1. SQL como mecanismo de interacción primario.

2. Soporte para transacciones ACID.

8

3. Un mecanismo de control de concurrencia de no bloqueo. El bloqueo en estos sistemas

provoca un altos niveles de overhead, que se traduce en menos tiempo de trabajo útil.

4. Una arquitectura que proporciona un rendimiento mucho mayor por nodo que los

SMBDR tradicionales.

5. Una arquitectura shared-nothing capaz de funcionar con un gran número de nodos sin

cuellos de botella.

Arquitectura

La arquitectura de las bases de datos NewSQL suele ser variadas dependiendo de la

implementación de los desarrolladores, la gran mayoría concuerdan en una arquitectura

distribuida con un nodo maestro, el cual se encarga de distribuir la consulta SQL desde la

aplicación, existen gran variedad de bases de datos NewSQL, estas bases de datos diseñadas

para funcionar en un clúster distribuido shared-nothing, en el que cada nodo posee un

subconjunto de los datos. Aunque en muchas de las nuevas bases de datos se han usado

diferentes enfoques de diseño, cada una con su propia arquitectura y diferentes características.

Un ejemplo de esta es ScaleDB.

ScaleDB es una base de datos NewSQL basada en Mysql, de almacenamiento masivo

para gestionar el procesamiento de transacciones en línea (OLTP) y almacén de datos (DW).

ScaleDB se despliega como un clúster de servidores que operan en los datos compartidos,

ofreciendo alto rendimiento y servicios de alta disponibilidad para una amplia gama de

aplicaciones, o servicios en la nube. ScaleDB, posee una arquitectura “tradicional” dentro de

las bases de datos NewSQL, descritos anteriormente.

9

Fig. 1 Arquitectura ScaleDB.

Específicamente en ScaleDB, la capa de aplicación es la encargada de enviar la

consulta SQL realizada por el usuario, evaluar la sintaxis de la sentencia SQL y enviarla a

nodo maestro, los nodos básicamente el motor de Mysql para procesar las consultas, está

representado como “MySQL Server”, el cual se encarga de procesar la consulta, realizar el

plan de ejecución y demás procesos, luego de esto, el resultado es enviado a la capa inferior,

representado en la figura como “ScaleDB Engine”, los nodos ejecutan constantemente un

proceso (servicio o demonio) llamado “scaledb”, en caso de ser nodo maestro dicho proceso

se encarga de tomar la consulta pre-procesada por el motor Mysql Server, y seccionarlos en

“sub-consultas”, luego distribuirlos en los nodos que posean parte de los datos requeridos.

Aunque hablar de ScaleDB, es solo un ejemplo en concreto, como se hizo referencia

anteriormente, existen infinidad de bases de datos NewSQL, muchas en desarrollo y otras

experimentales sin embargo ninguna escapa de una arquitectura distribuida del tipo “shared-

nothing”.

10

Clasificación

En un sentido general podemos dividir las bases de datos NewSQL en 2 tipos:

Bases de datos de uso general: Estas mantienen la funcionalidad completa de bases

de datos tradicionales y el manejo de todo tipo de consultas. Estas bases de datos se escriben a

menudo a partir de cero con una arquitectura distribuida en mente, e incluyen componentes

como el control distribuido de concurrencia, el control de flujo, y el procesamiento de

consultas distribuidas. Entre ellas están Google Spanner, Clustrix, NuoDB y TransLattice.

Bases de datos en memoria: Aunque las bases de datos tradicionalmente utilizan la

memoria RAM, para almacenar pequeños subconjuntos de los datos que generalmente se

utilizan (cache), algunas bases de datos NewSQL llevan este enfoque un paso más adelante,

debido a que las solicitudes dirigidas por los sistemas NewSQL se caracterizan por tener un

gran número de transacciones de corta duración que tocan un pequeño subconjunto de datos

utilizando las búsquedas indexadas (es decir, no hay recorridos de tablas completos o grandes

joins distribuidos) y repetitivos (es decir, ejecutan las mismas consultas con diferentes

entradas). Estos sistemas NewSQL logran un alto rendimiento y escalabilidad al evitar que

gran parte de la arquitectura sea heredada del diseño original de los sistemas relacionales,

formen parte de estas, tales como los algoritmos de recuperación o de control de concurrencia.

Aunque esta no es la única característica que poseen las bases de datos en memoria, su

principal fuerte se encuentra en que gran parte de los datos sino todo, se encuentra en memoria

principal, esta se pone en contraste con los sistemas de gestión de bases de datos que emplean

un mecanismo de almacenamiento en disco. Bases de datos de memoria principales son más

rápidas que las bases de datos optimizados de disco ya que los algoritmos de optimización

internos son más simples y ejecuta menos instrucciones de CPU. Acceso a los datos en la

11

memoria elimina el tiempo de búsqueda al consultar los datos, lo que proporciona más rápido

y un rendimiento mucho más elevado que el almacenamiento en disco.

Sin embargo hay que tener en cuenta que este tipo de base de datos, es decir las

almacenadas en memoria principal o (IMDB) no nos engañe, podríamos suponer en un primer

momento que este tipo de base de datos representa una amenaza en cuanto a la persistencia de

nuestros datos, sin embargo los desarrolladores consideraron este tipo de inconvenientes para

de alguna manera garantizar la persistencia de los datos, existen varias técnicas para garantizar

dicha persistencia, entre estas tenemos:

Snapshots o checkpoints: El motor de base de datos realiza modificaciones en las

páginas de la base de datos en memoria, no escribe estas páginas en el disco después de cada

cambio. En su lugar, Motor de base de datos emite periódicamente un punto de comprobación

en cada base de datos. Un punto de comprobación escribe las páginas modificadas en memoria

actuales (denominadas páginas desfasadas) y la información del registro de transacciones de la

memoria en el disco y, además, registra información acerca del registro de transacciones.

NVRAM: Referida a veces por sus siglas en inglés NVRAM (Non-volatile random

access memory) es un tipo de memoria de acceso aleatorio que, como su nombre indica, no

pierde la información almacenada al cortar la alimentación eléctrica. En los routers se utiliza

para almacenar un archivo de configuración de respaldo/inicio. Hoy día, la mayoría de

memorias NVRAM son memorias flash ya que son muy usadas para teléfonos móviles y

reproductores portátiles de audio.

La necesidad de mantener los datos, incluso cuando cesa la alimentación, motivó el

surgimiento de diversos tipos de memorias ROM reprogramables: eléctricamente alterables -

EAROM, eléctricamente borrables - EEPROM, programables y borrables - PEROM y flash

12

EEPROM. Cada nuevo tipo mejora la facilidad de grabación y duración de los datos, pero

distan de poder utilizarse como memoria RAM.

EEPROM: EEPROM o E²PROM son las siglas de Electrically Erasable

Programmable Read-Only Memory (ROM programable y borrable eléctricamente). Es un tipo

de memoria ROM que puede ser programada, borrada y reprogramada eléctricamente, a

diferencia de la EPROM que ha de borrarse mediante un aparato que emite rayos ultravioleta.

Son memorias no volátiles. Las celdas de memoria de una EEPROM están constituidas por un

transistor MOS, que tiene una compuerta flotante (estructura SAMOS), su estado normal está

cortado y la salida proporciona un 1 lógico. Aunque una EEPROM puede ser leída un número

ilimitado de veces, sólo puede ser borrada y reprogramada entre 100.000 y un millón de veces.

Estos dispositivos suelen comunicarse mediante protocolos como I²C, SPI. En otras ocasiones,

se integra dentro de chips como microcontroladores y DSPs para lograr una mayor rapidez.

SSD: La unidad de estado sólido, dispositivo de estado sólido o SSD (acrónimo inglés

de Solid-State Drive) es un tipo de dispositivo de almacenamiento de datos que utiliza

memoria no volátil, como la memoria flash, para almacenar datos, en lugar de los platos o

discos magnéticos de las unidades de discos duros (HDD) convencionales. En comparación

con los discos duros tradicionales, las unidades de estado sólido son menos sensibles a los

golpes, son prácticamente inaudibles y tienen un menor tiempo de acceso y de latencia. Las

SSD hacen uso de la misma interfaz que los discos duros por lo que son fácilmente

intercambiables sin tener que recurrir a adaptadores o tarjetas de expansión para

compatibilizarlos con el equipo.

13

Características de RDBMS, NoSQL, NewSQL

Characteristics RBDMS NoSQL NewSQL

ACID compliance Yes No Yes

OLAP/OLTP Yes No Yes

Data analysis Yes No Yes

Schema rigidity Yes No Maybe

Data format flexibility No Yes Maybe

Distributed computing Yes Yes Yes

Scale up (vertical, Horizontal) Yes Yes Yes

Perfomance with growing data Fast Fast Very Fast

Perfomance overhead Huge Moderate Minimal

Popularity/Community Support Huge Growing Slowly growing

14

Casos de estudio

Google Spanner

Spanner es una base de datos escalable, distribuida globalmente, diseñada, construida y

puesta en marcha en Google. En el nivel más alto de abstracción, “es una base de datos que

fragmenta datos a través de muchos sets de máquinas utilizando el algoritmo de Paxos, en

centros de datos esparcidos alrededor de todo el mundo” (Google Inc, 2012). Se utiliza

replicación para tener disponibilidad global y el uso de datos locales dependiendo de la zona

geográfica; los clientes son automáticamente conmutados entre réplicas. Spanner

automáticamente refragmenta datos entre máquinas mientras el número de data o de servidores

cambia, y automáticamente migra datos entre máquinas (incluso entre centros de datos) para

balancear la carga y para responder a fallas. Spanner está diseñada para escalar a millones de

máquinas entre cientos de centros de datos y trillones de filas de bases de datos.

El énfasis principal de Spanner es administrar los datos replicados entre centros de

datos esparcidos, pero el equipo de Google también utilizó una gran cantidad de tiempo y

recursos diseñando e implementando características importantes de una base de datos común

como una capa superior a su infraestructura de sistema distribuido. Incluso a pesar de que

muchos proyectos felizmente utilizaron Bigtable, a la vez el equipo de Google recibió muchas

quejas de usuarios alegando que Bigtable puede ser difícil de usar para algunos tipos de

aplicaciones: Aquellas que tienen esquemas complejos, incluso evolutivos, o aquellos que

quieren alguna fuerte consistencia en presencia en una replicación de área muy ancha. Como

consecuencia, Spanner evolucionó de una versión similar a Bigtable con almacenamiento

clave-valor, a una base de datos con multiversión temporal. Los datos se almacenan en tablas

con esquemas semi relacionales; los datos están versionados y cada versión tiene

15

automáticamente una marca de tiempo que incluye el momento de su commit; versiones

antiguas de datos están sujetas a políticas configurables de recolectores de basura; aplicaciones

pueden leer data con antiguas marcas de tiempo. Spanner tiene soporte para transacciones de

propósito general y provee un lenguaje basado en SQL.

Implementación. Una instancia de Spanner es llamada un universo. Dado que Spanner

gestiona data globalmente, hay muy pocos universos corriendo. Al momento del paper que

hizo Google sobre esta base de datos queda dispuesto que para ese momento sólo poseían 3

universos: uno de pruebas, uno de desarrollo y finalmente uno de producción. Spanner está

organizado como un conjunto de zonas, donde cada zona es el análogo de una implementación

de los “servers” de Bigtable. Las zonas son la unidad de administración. El conjunto de zonas

también es el conjunto de ubicaciones donde está dicho cuáles datos pueden ser replicados.

Las zonas pueden ser añadidas o removidas de un sistema que ya está puesto en marcha, como

nuevos centros de datos recién colocados en un servicio o antiguos centros de datos que son

apagados, respectivamente. Las zonas también son la unidad de aislamiento físico: Puede

haber una o más zonas en un centro de datos, por ejemplo, si los datos de diferentes

aplicaciones deben ser particionados entre diferentes conjuntos de servidores del mismo centro

de datos. La figura ilustra los servidores en un universo Spanner. Cada zona tiene un maestro

de zona y entre cientos y miles de spanservers. Los proxies que posee cada zona son usados

por clientes para localizar los spanservers asignado para alojar su data. El maestro del universo

y el “placement driver” son instancias singleton. El maestro del universo es primariamente una

consola que muestra información referente al estado de todas las zonas para hacer un debug

interactivo. El “placement driver” maneja de manera automatizada movimientos de datos entre

zonas en escalas de minutos, el placement driver periódicamente se comunica con los

16

spanservers para encontrar datos que deben ser movidos, así sea para actualizarlos con una

réplica nueva o para balancear la carga.

Cada spanserver posee un líder de participantes, cada líder se encarga de mantener los

datos y de replicarlos en otros centros de datos. Estos participantes se comunican entre sí

utilizando el algoritmo de Paxos. Cada réplica se almacena en tablas, siendo la capa inferior a

ella el sistema de archivos implementado por Google (Colossus), así como está ilustrado en la

imagen anexa.

17

NuoDB

Definición. NuoDB es un sistema manejador de bases de datos distribuidos que se

enfoca en utilizar sentencias SQL y las propiedades ACID. A diferencia de las tradicionales

bases de datos que utilizan arquitecturas shared-disk o arquitecturas shared-nothing, NuoDB

es un nuevo enfoque distribuido, asíncrono y peer-to-peer.

La idea de la creación de NuoDB nació al momento del movimiento NewSQL, el

equipo desarrollador de NuoDB tomó algunas características importantes para desarrollar su

propia solución. Entre estas características claves, están proporcionar seguridad, agilidad al

momento de encarar fallos impredecibles en los centros de datos y soporte para aplicaciones

extensamente distribuidas. Para que estas aplicaciones extensamente distribuidas, en cambio,

utilicen servicios distribuidos que estén altamente disponibles y puedn proveer baja latencia.

Estos son los objetivos que definieron la arquitectura de NuoDB, que se diseñó con usos

globales y grandes desafíos en mente. Es un verdadero servicio SQL: Todas las propiedades

de transacciones ACID, estandares de soporte del lenguaje SQL y lógica relacional. También

fue diseñada desde cero como un sistema distribuido que posee alta disponibilidad sin ningún

punto de fallo.

Arquitectura. NuoDB no fue diseñada con un sistema operativo específico, modelo de

red, o modelo de virtualización en mente. Es una pieza de software general que explota los

recursos que se le han dado. Su arquitectura distribuida se divide en tres capas: Una capa

administrativa, una capa transaccional y una capa de almacenamiento.

18

Modelo tres capas. Encima de las dos capas referentes a la base de datos, se encuentra

una capa de administración, esta capa no es más que una colección de procesos pares. Estos

procesos son llamados agentes de administración y uno de ellos corre en cada host donde la

base de datos pueda estar activos. Para el almacenamiento NuoDB utiliza unos objetos

llamados Atoms. Todos los datos asociados con una base de datos, incluyendo la metadata

interna, está representada con Atom.

Control de carga Multi-Version. Los enfoques tradicionales como detención de

deadlock o bloqueo explícito se vuelven muy caros en recursos cuando se realiza una

implementación con unos pocas máquinas sin un reloj de sincronización. Para resolver este

problema, NuoDB usa MVCC para manejar conflictos y proveer un modelo más claro para

consistencia.

VoltDB

Definición. VoltDB es una base de datos en memoria creada por el pionero Michael

Stonebraker, en conjunto con expertos en computación de las universidades MIT, Yale,

Brandeis y Brown. VoltDB es definida como un increíblemente rápido sistema manejador de

19

base de datos (RDBMS) diseñado para ser implementado en infraestructuras modernas con

escalamiento horizontal. VoltDB está dirigida a aplicaciones de nueva generación que

requieran bases de datos de muy alta velocidad, un desempeño capaz de alcanzar la realización

de millones de operaciones por segundo, gran disponibilidad, tolerancia a fallos y durabilidad

y análisis de datos en tiempo real.

Arquitectura. VoltDB está diseñada para optimizar el diseño VLSI (Very Large Scale

Integration) de CPUs con múltiples núcleos. Además, saca el mayor provecho de topologías

de servidor cluster y toma ventaja de la abundancia de memoria para manejar rápido grandes

cargas de trabajo. VoltDB es una base de datos completamente ACID transaccional, evitando

que los desarrolladores deban escribir código personalizado para procesar transacciones y

rollbacks. VoltDB se aprovecha de los siguientes elementos de la arquitectura para realizar su

gran desempeño y escalabilidad:

● Almacenamiento en memoria para maximizar el desempeño, así evitando costosos

accesos a disco.

● Serialización de todos los accesos a datos, evitando así los overheads de las bases de

datos tradicionales, tal como el bloqueo.

● Aplicando particionamiento horizontal (visto en la figura).

● Manteniendo gran disponibilidad a través de replicación síncrona con múltiples

maestros (en la jerga de VoltDB, esto es llamado “K-safety”)

● Durabilidad a través de una combinación innovadora de logs y snapshots que

almacenan información de los estados recuperables en dispositivos persistentes

20

One thread, one task at a time. (Un hilo, una tarea a la vez) Hay muchas maneras

para disminuir el costo de la implementación de concurrencia, pero pocos cubrían las

necesidades del equipo de VoltDB. Para ir 10 veces más rápido, el costo debería ser eliminado

por completo. Como sólo hay una manera de realizar eso, la elección era obvia: Todas las

operaciones de datos en VoltDB poseen un solo hilo, ejecutando cada operación hasta su

finalización antes de empezar la próxima. Estructuras de datos elegantes como B-Trees y otras

que no utilizaban mecanismos de bloqueo, son reemplazadas por datos con una estructura

simple, sin costo de acceso concurrente. Esto no solo cubre necesidades de velocidad, es de

hecho más fácil de construir, probar y de modificar, un ganar ganar. Este enfoque es posible

solamente por el diseño en memoria, la latencia de leer y escribir por disco usualmente es

escondida por memoria compartida utilizando multi hilos, pero al utilizar sólo un hilo esa

latencia causaría que el CPU pasara más tiempo inactivo. Eliminando las esperas en disco

permiten mantener el CPU saturado. Aparte de esto, VoltDB utiliza su propia versión de

MVCC.

21

Conclusiones

Luego de leer toda esta información acerca del origen y de los usos e

implementaciones de las nuevas bases de datos denominadas NewSQL, podemos deducir que

se resolvió el problema de escalabilidad horizontal en los sistemas manejadores de bases de

datos tradicionales con esta nueva tendencia que no abandona el estándar de SQL. También, se

hace notar que existen las bases de datos NoSQL y están en la competencia con las grandes

compañías de bases de datos por su alta escalabilidad. Sería erróneo decir que una sola

tendencia o un solo sistema manejador de bases de datos podría resolver todos los problemas,

por lo que podemos concluir que a pesar de la evolución que han presentado las bases de datos

en los últimos años, no hay una solución definitiva, esto quiere decir que, al momento de

escoger una base de datos uno de los primeros factores que debe tomarse en cuenta es el

problema que quiera resolverse y dependiendo de las necesidades inherentes al problema,

hallar una base de datos que convenga en el manejo y uso eficiente de los datos. En lo posible

tener una mente abierta para considerar opciones fuera de lo ordinario pero sin perder la

perspectiva y la estabilidad conocida de SQL.

22

Referencias Bibliográficas

1. Michael Stonebraker (16 de junio de 2011). New SQL: An Alternative to NoSQL and

Old SQL for New OLTP Apps. Obtenido de http://cacm.acm.org/blogs/blog-

cacm/109710-new-sql-an-alternative-to-nosql-and-old-sql-for-new-oltp-apps/fulltext

2. Michael Stonebraker. s.f. OldSQL vs. NoSQL vs. NewSQL on New OLTP. VoltDB, Inc.

3. Matthew Aslett (4 de abril de 2011). How will the database incumbents respond to

NoSQL and NewSQL?. The 451 Group.

4. Matthew Aslett (6 de Abril de 2011). What we talk about when we talk about NewSQL.

The 451 Group blog. Obtenido de

https://blogs.the451group.com/information_management/2011/04/06/what-we-talk-

about-when-we-talk-about-newsql/

5. Google Inc. (2012) Spanner: Google’s Globally-Distributed Database. Obtenido de:

http://static.googleusercontent.com/media/research.google.com/es-

419//archive/spanner-osdi2012.pdf

6. NuoDB Core Team. (2013) The Architecture & Motivation For NuoDB. Obtenido de:

http://go.nuodb.com/rs/nuodb/images/Technical-Whitepaper.pdf

7. NouDB Inc. (2015) NuoDB official site. Obtenido de:

http://www.nuodb.com/explore/newsql-cloud-database-how-it-works

8. VoltDB Inc. (2015) VoltDB official site. Obtenido de:

http://voltdb.com/products/featuresbenefits/reasons-behind-voltdb-architecture

9. VoltDB Inc. (2013) VoltDB Technical overview. Obtenido de:

http://www.odbms.org/wp-content/uploads/2013/11/VoltDBTechnicalOverview.pdf

10. Wikipedia. NewSQL. Obtenido de: https://es.wikipedia.org/wiki/NewSQL