En el articulo anterior que desarrolle sobre el mundo de Big Data introduje los problemas con los que hoy en día nos encontramos a la hora de almacenar la información. En esta articulo voy a introducir uno de los tipos de bases de datos mas habituales en el mundo NoSQL, las bases de datos documentales.

 ¿Que es un documento?

Normalmente cuando en un entorno TIC nos referimos a un documento … suele ser un documento word,excel,pdf etc . Así pues hay tendencia para la gente que empieza con estos temas de NoSQL a entender que las bases de datos NoSQL orientadas a documentos almacenan este tipo de información . Lamentablemente es un concepto erroneo. Ahora bien ¿Que es un documento? . Vamos a intentar explicarlo apoyandonos en la relación que existe entre las tablas de cliente ,factura ,linea de factura del articulo de BigData.

Si tenemos 1000 clientes y cada uno dispone de media de 2 facturas y cada factura tiene 10 lineas y queremos sacar por pantalla todas las lineas de todos los clientes .Estaremos seleccionando 20mil registros.

1000 clientes x 2 facturas x=10 lineas =20mil lineas;

Ahora bien la consulta SQL que deberemos realizar será del estilo de la siguiente

select * from factura ,lineafactura,linea where  cliente.dni= factura.cliente_dni and factura.id= lineafactura.factura_id

Acabamos de realizar una operación de Join con filtrado pero aún así la base de datos ha tenido que ejecutar un par de productos cartesianos  (combinatoria). En concreto ha hecho lo siguiente.

1000 clientes existentes x 2000facturas existentes x 20mil lineas existentes= 40 mil millones

Esto suena extraño ¿tantas combinaciones tiene que realizar la base de datos? La realidad será bastante distinta ya que irá haciendo los productos cartesianos uno a uno . Por ejemplo

1000 clientes x 2000facturas= 2 millones

2 millones + aplicamos filtro (cliente.dni= factura.dni)= 2000 facturas_y_clientes  (esto esta mucho mejor)

Una vez hecho esto volverá ha realizar un producto cartesiano

2000 facturas_y_clientes x 20 mil lineas existentes=40 millones

40 millones +aplicamos filtro (factura.id= lineafactura.factura_id)= 20mil facturas_y_clientes_y_lineas (nuestro resultad0)

Todo mucho mas razonable ,recordemos que se usarán indices etc para mejorar el acceso . Aún asi podemos ver que cuantos mas productos cartesianos tengamos mas complejo es para el motor de la base de datos gestionar los datos, sobre todo si no filtramos de forma clara. ¿Como  podemos enfocar con NoSQL  estas casuísticas?

NoSQL Objetos y Documentos

¿Pódria ser una solución en vez de almacenar registros almacenar objetos ?

Si revisamos la idea nos encontramos ante la misma situación ya que cada tipo de objeto estaría en una tabla .Ahora bien que pasaría si un objeto cliente incluyera varias facturas y estas a su vez varias lineas de factura.

Este es otro tipo de estructura en la cual toda la información estrechamente relacionada este agrupada en una única estructura . Esta estructura se denomina  DOCUMENTO. Cuando trabajamos con bases de datos NoSQL orientadas a documentos trabajamos siempre con Tablas (Colecciones) que almacenan n documentos .Cada documento puede tener subcolecciones de elementos dentro.

Con esta estructura de información ,cuando hagamos una consulta pidiendo los clientes con las facturas y sus lineas unicamente tendremos que seleccionar los 1000 clientes de la tabla . No hará falta realizar ningun producto cartesiano o filtro. Así pues es lógico que este tipo de bases de datos tengan un rendimiento muy superior a las relacionales en algunas casuisticas . Recordemos sin embargo que cada tipo de base de datos tiene su hueco y las bases de datos relacionales hoy por hoy cubren una gran parte de las necesidades que tenemos .

Post By Cecilio Álvarez Caules (32 Posts)

Oracle Certified Master, Java EE Enterprise Architect .Experto en la plataforma JEE y Trainer. Autor del libro Arquitectura Java Sólida Dueño del blog sobre JEE Arquitectura Java

Website: →

Connect

BigData, NoSQL