NoSQL y Documentos
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.
1 2 3 4 5 6 7 8 9 10 |
Estos documentos muchos casos se definen con estructuras de tipo JSON { _id: 1, cliente: "pedro" facturas: [ { id: 'A', importe: 100, lineas: {...} }, { id: 'B', importe: 200, lineas: {...} } ] } |
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 .
Trackbacks/Pingbacks
[…] el siguiente articulo para mis amigos de cantabriatic intento realizar una introducción sencilla al mundo de las […]