NoSQL · Modelos de datos · Comparativa SQL

NoSQL básico: modelos, comparación con SQL y cuándo usar cada uno

NoSQL no es un único tipo de base de datos y tampoco es un sustituto universal de SQL. Es una familia de modelos pensada para casos donde el modelo relacional no encaja con comodidad: documentos flexibles, datos distribuidos a gran escala, accesos rápidos por clave o relaciones muy conectadas.

Qué ha cambiado en el diseño NoSQL actual

Los sistemas relacionales escalan horizontalmente en más escenarios, mientras que bases documentales y distribuidas incorporan transacciones y motores de consulta más ricos. La etiqueta ya no determina por sí sola consistencia o escalabilidad: hay que comparar producto, despliegue y carga concretos.

  • Define patrones de acceso, límites transaccionales y objetivos de recuperación antes de elegir modelo.
  • Prueba índices y peores consultas con una distribución de datos realista, no solo la latencia media.
  • Incluye restauración, evolución de esquema, observabilidad, fallo regional y coste operativo.
  • Usa persistencia políglota solo si compensa la complejidad de sincronización y gobierno.

Respuesta rápida

Usa una base relacional cuando el dominio dependa de consistencia fuerte, joins, informes tabulares y un esquema estable. Considera NoSQL cuando el patrón de acceso, la escala o la forma del dato encaje mejor con un modelo clave-valor, documental, columnar o de grafos.

Los cuatro modelos NoSQL principales

Clave-valor

Guarda un valor detrás de una clave. Útil para sesiones, cachés, contadores y búsquedas directas rápidas.

Documental

Guarda documentos similares a JSON. Útil cuando la aplicación lee y escribe agregados completos.

Columnar

Optimizado para escrituras distribuidas y consultas diseñadas alrededor de patrones de acceso conocidos.

Grafos

Diseñado para relaciones. Útil en recomendaciones, redes, rutas de fraude y análisis de dependencias.

SQL vs NoSQL: la decisión práctica

PreguntaSuele encajar SQLSuele encajar NoSQL
Forma del datoTablas estables y relaciones bien definidas.Estructuras flexibles, agregados o grafos con muchas relaciones.
ConsultasMuchos joins, reporting y análisis ad hoc.Patrones de acceso conocidos y diseñados dentro del modelo.
ConsistenciaLas garantías transaccionales fuertes son centrales.La disponibilidad, partición o escala pueden pesar más.

Error habitual

El error no es elegir SQL o NoSQL. El error es elegir base de datos antes de saber cómo la aplicación va a leer, escribir y evolucionar sus datos. En NoSQL, el modelado parte de las consultas y de los límites del agregado, no solo de las entidades.

1. Comparison between SQL and NoSQL Databases and Their Relationship with Big Data Analytics

Realizada una lectura del artículo "Comparison between SQL and NoSQL Databases and Their Relationship with Big Data Analytics'' [1] he respondido las siguientes preguntas:

  • ¿Qué opinan los autores sobre cuál sería una solución adecuada de almacenamiento para un blog?

    Opinan que las base de datos NoSql pueden llegar a ser un 85% más rápido que aquellos blog con sistemas de gestión SQL. Esto es debido a que los sistemas NoSQL otorgan más importancia a la accesibilidad que a la coherencia de la información y, por lo tanto, pueden gestionar mejor documentos binarios como por ejemplo videos e imágenes.

  • ¿Es interesante usar bases de datos NoSQL en el desarrollo de aplicaciones móviles para la gestión de datos?

    En algunos casos sí. Según el texto, se ha demostrado que las operaciones de actualización Upsert son más simple y rápidas en las bases NoSQL que en las SQL. Es cierto que el uso de computación en la nube y NoSQL mejora el rendimiento de las plataformas móviles, especialmente en la capa de datos pero también necesitaremos más espacio de almacenamiento y las búsquedas en las bases de datos NoSQL "grandes" tardan más tiempo que en las RDBMS.

  • ¿Cómo se representan los enlaces entre nodos en las bases de datos orientadas en grafos?

    Gráficamente con las aristas y computacionalmente con un método de adyacencia sin índice, es decir, se crea con cada nodo un punto directo que apunta hacia los diferentes nodos vecinos.

  • Cuáles son las principales razones para pasar del uso de un sistema de persistencia relacional a un sistema NoSQL?

    La razón principal por la que necesitaría migrar a las bases de datos NoSQL es la necesidad de almacenar una gran cantidad de datos. Otras razones importante es la escalabilidad de estos sistemas, el rendimiento que ofrecen con grandes volúmenes de datos y la versatilidad para trabajar con datos de diversos tipos.

  • ¿Qué puedes decir comparando las bases de datos NoSQL con las relacionales al respecto del mantenimiento, la integridad y la escalabilidad?

    Las bases de datos relacionales tiene una mejor integridad de los datos debido a la estructura definida de la información y su fácil mantenimiento. Ahora bien, no es escalable, todo lo contrario, tiene muchas limitaciones técnicas en este sentido.

    Las bases de datos NoSQL son todo lo contrario, al no tener una estructura definida en los datos y gestionar grandes volúmenes de información el mantenimiento y la integridad son más difíciles de gestionar. Por otra parte, los sistemas son fácilmente escalable.

2. NoSQL Distilled

A partir de la lectura del libro NoSQL Distilled (Descarga) he respuesto las siguientes afirmaciónes:

  • Una característica común a todas las bases de datos NoSQL es el estar orientadas a ejecutarse sobre un clúster.

    Falso.

    However, not all NoSQL databases are strongly oriented towards running on clusters. Graph databases are one style of NoSQL databases that uses a distribution model similar to relational databases but offers a different data model that makes it better at handling data with complex relationships.

    Capítulo 1.5. The Emergence of NoSQL [2]

    Lo dice claramente el texto citado, no todas las bases de datos NoSQL están fuertemente orientadas a la ejecución en clústeres. Las bases de datos orientadas a grafos son una variedad NoSQL que utiliza un modelo de distribución similar a las bases de datos relacionales, pero ofrecen un modelo diferente con el propósito de manejar datos con relaciones complejas. Neo4j es un ejemplo de bases de datos NoSQL no orientadas a ejecutarse sobre un clúster sino orientada a simplificar la interpretación de los datos.

  • Se dice que las bases de datos relacionales no presentan el problema de la impedancia (impedance mismatch) porque la forma de representar la información en el modelo relacional y en las estructuras de datos que se usan en memoria es idéntica y no se requiere realizar ningún proceso de traducción entre ambos modelos.

    Falso.

    Relational databases provide many advantages, but they are by no means perfect.[...]For application developers, the biggest frustration has been what’s commonly called theimpedance mismatch: the difference between the relational model and the in-memory data structures.The relational data model organizes data into a structure of tables and rows, or more properly,relations and tuples. In the relational model, a tuple is a set of name-value pairs and a relation is aset of tuples. (The relational definition of a tuple is slightly different from that in mathematics andmany programming languages with a tuple data type, where a tuple is a sequence of values.) Alloperations in SQL consume and return relations, which leads to the mathematically elegant relationalalgebra.This foundation on relations provides a certain elegance and simplicity, but it also introduces limitations. In particular, the values in a relational tuple have to be simple—they cannot contain anystructure, such as a nested record or a list. This limitation isn’t true for in-memory data structures,which can take on much richer structures than relations. As a result, if you want to use a richer inmemory data structure, you have to translate it to a relational representation to store it on disk.

    Capítulo 1.2. Impedance Mismatch [2]

    Como ya se ha avanzado, la afirmación es falsa. Las bases de datos relacionales no son perfectas, existen limitaciones como por ejemplo el problema de la impedancia. En las bases de datos comentadas una tupla relacional debe ser simple: no puede contener ninguna estructura, como un registro anidado o una lista. Esta limitación no es cierta para las estructuras de datos en memoria, que pueden asumir estructuras mucho más ricas que las relaciones. Como resultado, si desea utilizar una estructura de datos in memory más rica, debe traducirla a una representación relacional para almacenarla en el disco.

    Es decir, las bases de datos relacionales presentan el problema de la impedancia (impedance mismatch).

  • Si se conoce claramente la forma en la que se van a consultar los datos, es mejor utilizar un modelo que ignore las agregaciones, es decir un modelo en grafo o relacional.

    Falso.

    Relational databases have no concept of aggregate within their data model, so we call them aggregate-ignorant. In the NoSQL world, graph databases are also aggregate-ignorant. Being aggregate-ignorant is not a bad thing. It’s often difficult to draw aggregate boundaries well, particularly if the same data is used in many different contexts. An order makes a good aggregate when a customer is making and reviewing orders, and when the retailer is processing orders. However, if a retailer wants to analyze its product sales over the last few months, then an order aggregate becomes a trouble. To get to product sales history, you’ll have to dig into every aggregate in the database. So an aggregate structure may help with some data interactions but be an obstacle for others. An aggregate-ignorant model allows you to easily look at the data in different ways, so it is a better choice when you don’t have a primary structure for manipulating your data

    Capitulo 2.1.2.Consequences of Aggregate Orientation. [2]

    Como indica el texto citado, las bases de datos relacionales y las orientadas a grafos no tienen un concepto de agregación dentro de su modelo de datos. Esta característica les permite ver fácilmente los datos de diferentes maneras, por lo que es una mejor opción cuando no tiene una estructura principal para manipular sus datos.

    Dicho esto, al conocer claramente la estructura en la que se van a consultar los datos, la mejor opción sería un modelo agregado.

  • El uso de agregados facilita que las bases de datos puedan operar sobre clusters pues el concepto de agregado se convierte en una unidad natural para la replicación y la distribución.

    Verdadera.

    Dealing in aggregates makes it much easier for these databases to handle operating on a cluster, since the aggregate makes a natural unit for replication and sharding. Aggregates are also often easier for application programmers to work with, since they often manipulate data through aggregate structures.

    Capítulo 2.1. Aggregates. [2]

    Como dice el texto los agregados hace que sea mucho más fácil el funcionamiento en un clúster, ya que esta estructura constituye una unidad natural de replicación y fragmentación.

  • Debido a que las bases de datos relacionales disponen de un esquema de datos fijo, no se produce el problema de las tablas dispersas (sparse table - aquellas que tienen muchas columnas nulas o que tienen columnas que no tienen significado).

    Falso.

    As well as handling changes, a schemaless store also makes it easier to deal with nonuniform data: data where each record has a different set of fields. A schema puts all rows of a table into a straightjacket, which becomes awkward if you have different kinds of data in different rows. You either end up with lots of columns that are usually null (a sparse table), or you end up with meaningless columns like custom column 4. Schemalessness avoids this, allowing each record to contain just what it needs—no more, no less.

    Capítulo 3.3. Schemaless Databases [2]

    Refiriéndose a las bases de datos relacionales, el documento de estudio nos advierte que estos sistemas deben rellenar todas las filas de una tabla obligatoriamente, lo que resulta incómodo si tiene diferentes tipos de datos en diferentes filas. O terminas con muchas columnas que generalmente son nulas (sparse table) o terminas con columnas sin sentido. La ausencia de esquema evita esto, permitiendo que cada registro contenga justo lo que necesita, ni más ni menos.

    La conclusión es clara, la afirmación es falsa.

  • Las bases de datos basadas en grafos hacen que el recorrido por las relaciones durante las operaciones de consulta no sea tan costoso, dado que el coste del cálculo de la navegación impacta principalmente durante la inserción de los datos.

    Verdadera.

    Once you have built up a graph of nodes and edges, a graph database allows you to query that network with query operations designed with this kind of graph in mind. This is where the important differences between graph and relational databases come in. Although relational databases can implement relationships using foreign keys, the joins required to navigate around can get quite expensive — which means performance is often poor for highly connected data models. Graph databases make traversal along the relationships very cheap. A large part of this is because graph databases shift most of the work of navigating relationships from query time to insert time. This naturally pays off for situations where querying performance is more important than insert speed.

    Capítulo 3.2. Graph Databases. [2]

    Una vez que se ha creado un grafo con sus nodos y sus aristas podemos consultar su estructura utilizando algoritmos basados en grafos. Estos sistemas se puede recorrer velozmente las relaciones entre los diferentes nodos debido a que están muy optimizados para ello. Su estructura interna penaliza la inserción de nuevos elementos a favor de permitir recorridos sobre la red más veloces, es decir, prima el rendimiento de las consultas sobre la inserción.

    Por lo tanto, la afirmación es correcta.

3. Ejemplo de Agregados.

El servicio de reparto a domicilio de un supermercado necesita gestionar la información de los pedidos que recibe. Los gestores del supermercado muestran interés para resolver las siguientes consultas:

  • Conocer las compras realizadas y los clientes que las realizaron, por cada mes y tipo de producto. En particular, quieren obtener, para cada mes y categoría de producto, los clientes (dni, nombre y apellidos) que compraron productos de esa categoría, así como, para cada cliente, la lista de los productos que compraron de esa categoría. De cada producto, se quiere obtener su identificador y la cantidad comprada.

    1 Representación 1

    Se propone un agregado que represente la información por meses. Cada agregado estará compuesto por un campo mes, ano y las diferentes categorias. Por su parte, categorias estará compuesto por nombrecat (un texto o número que permitirá identificar la categoría, ya que, sin estar especificado en el enunciado, he considerado útil añadir este campo) y el agregado de clientes.

    Continuando con el análisis de la estructura, los clientes estarán compuestos por los campos dni, nombre y apellidos y los diferentes productos adquiridos. El agregado producto está compuesto por un id y la cantidad de productos comprados.

  • Conocer por cada zona de reparto, y en función de su fecha de reparto (año, mes y día), los pedidos servidos. Para cada pedido interesa obtener su identificador, los datos del cliente que realizó el pedido (dni, nombre y apellidos) y la lista de productos comprados. De cada producto se quiere obtener su Identificador y la cantidad comprada.

    2 Representación 2

    Se propone un agregado que represente la información por zonas. Cada zona estará compuesta por un campo nombrezona como elemento descriptivo y las diferentes fechas de entrega. Cada agregado fecha estará compuesto por un campo dia, mes, ano y los diferentes pedidos. Por su parte, los pedidos estarán compuesto por id, el agregado de cliente y los agregados de producto.

    Continuando con el análisis de la estructura, los clientes estarán compuestos por los campos dni, nombre y apellidos.Por cada producto obtendremos un id y la cantidad de elementos entregados.

4. IEEE/ACM Transactions on Computational Biology and Bioinformatics

  • Problema de persistencia de datos que se ha resuelto.

    El caso de aplicación escogido ha sido una investigación publicada en IEEE/ACM Transactions on Computational Biology and Bioinformatics el año 2012 con el título A fast ranking algorithm for predicting gene functions in biomolecular networks [3]

    Realmente me ha parecido un ejemplo interesante debido a la importancia otorgada a la organización de los datos y cómo beneficiarse de ello. Es un artículo científico en el que se describe una nueva técnica para la clasificación de biomoléculas a partir de la disposición en grafos de sus componentes. Los algoritmos propuesto para este fin, denominados algoritmos de ranking, utilizan grafos cargados íntegramente en la memoria principal (utilizando estructuras de datos como matrices o listas de adyacencia) para que posteriormente puedan catalogar los genes no identificados, de acuerdo con el grado de pertenencia a una clase de los genes con los que está relacionado. Estos métodos nos proporcionan como resultado un valor de probabilidad respecto a la relación de pertenencia que existe entre un determinado gen y una clase.

    En el artículo, han propuesto un enfoque nuevo dónde, en vez de utilizar estas matrices cargadas en bases de datos tradicionales, proponen la utilización de kernels con grafos y así poder explotar las relaciones directas e indirectas entre genes, teniendo en cuenta la topología general de la red. Su método de clasificación es rápido y escalable, ya que no se requiere aprendizaje de modelos, sino solo un cálculo de puntuaciones, aproximadamente lineal al número de genes.

    Para ello el texto ha comparado su enfoque con varios métodos de clasificación genética de última generación [4] , mediante la integración de múltiples fuentes de datos biomoleculares en el contexto de un problema de clasificación genética en el organismo modelo de la levadura.

  • Razones por las que no es recomendable el uso de una base de datos relacional.

    Según el texto, las investigaciones realizadas utilizando tecnologías biomoleculares de alto rendimiento destacaron que la mayoría de las funciones biológicas se basan en relaciones complejas entre numerosos componentes biomoleculares como proteínas, ADN, ARN y muchas otras moléculas pequeñas.

    Por lo tanto, la predicción de características genéticas en diferentes especies o la asociación gen-enfermedad, el número de genes que deben tomarse en consideración, y en consecuencia el tamaño del grafo con el que trabajamos, crece exponencialmente. Por esta razón, los algoritmos de ranking clásicos se vuelven computacionalmente muy costosos o incluso inaplicables y, por lo tanto, se tienen que desarrollar nuevos algoritmos que le permiten escalar mejor la información manteniéndola en un almacenamiento secundario o distribuyendo la carga de trabajo entre varias máquinas.

    Además, si analizamos los lenguajes actuales o los ordenadores en los que podemos aplicar los algoritmos, solo pueden manejar una matriz de tamaño limitado. Otra característica de estas matrices es que, por su naturaleza, se encuentran dispersos y es difícil que un elemento tenga arcos con todos los otros elementos del grafo. Por lo tanto, esto lleva a que la matriz memorice una gran cantidad de valores iguales a 0 que no resultan útiles para el cálculo final.

    Por último, las bases de datos relacionales son muy difíciles de gestionar y requieren un nivel avanzado para aplicar algoritmos complejos. En cambio las bases de datos como Neo4J simplifican mucho las cosas y permiten que técnicos iniciados en la informática poder realizar tareas más fácilmente.

  • Razones por las que es recomendable la base de datos que se ha utilizado como solución.

    La primera y más importante de las justificaciones es la facilidad de gestión y consultas que nos ofrece una base de datos orientadas a grafos.Si buscamos diferentes representaciones al problema explicado en el documento nos encontramos que es más fácil de entender visualmente un grafo que no una tabla, por lo tanto, será más fácil implementar nuevos algoritmos o técnicas sobre este sistema

    El segundo motivo es el rendimiento. Si recordamos una base de datos orientada a grafos tiene un coste de inserción muy elevado pero, una vez se ha generado el grafo, el coste por consulta es reducido .

    Por último, el espacio, almacenar una matriz de adyacencia en un grafo reduce bastante la cantidad de memoria necesaria.

    Con todo ello, se ha conseguido obtener un mejor resultado en la clasificación de biomoléculas que los algoritmos previos a la publicación. Los ensayos sugieren que las estrategias propuestas en el texto podrían mejorar las técnicas actuales de clasificación genética, reducir sus costes computacionales y mejorar sus rendimiento y eficiencias.

Bibliografía

  • 1.Titulo
    Comparison between SQL and NoSQL databases and their relationship with big data analytics
    Autor
    Ali, Wajid and Shafique, Muhammad Usman and Majeed, Muhammad Arslan and Raza, Ali
    Publicacion
    Asian Journal of Research in Computer Science
    Url
  • 2.Titulo
    NoSQL distilled: a brief guide to the emerging world of polyglot persistence
    Autor
    Sadalage, Pramod J and Fowler, Martin
    Publicacion
    Url
  • 3.Titulo
    A fast ranking algorithm for predicting gene functions in biomolecular networks
    Autor
    Re, Matteo and Mesiti, Marco and Valentini, Giorgio
    Publicacion
    IEEE/ACM Transactions on Computational Biology and Bioinformatics
    Url
2026 © 1938.com.es 1938web@gmail.com

Politica de Privacidad