El debate eterno, ¿SQL, o Mongo?

El debate eterno, ¿SQL, o Mongo?

Nuestras queridas bases de datos, amadas veneradas y respetadas por todos los “Dateros” del mundo. Son, sin lugar a duda, el pozo de oro amorfo más valioso de nuestra era. Reiterados autores las describen como “los envases del recurso más preciado de que disponemos”. ¿Pero en qué quedan esas bases reducidas, si no llegan a estar bien administradas?

NoSQL Databases

Dentro de las grandes clasificaciones de las tipologías de bases de datos, encontramos las relacionales y las key-values. Las más antiguas y unas altamente veneradas entre los experimentados del mundo de la gestión de las bases de datos, dada su fiabilidad, recorrido histórico y estructura. Inicialmente, las siglas era SEQUEL, por su referencia a la posibilidad de hacer consultas en inglés a un conjunto de datos estructurados, ahora acortado a SQL. Ahí encontraremos los datos organizados en patrones formales entre ellos, y cuyas consultas son siempre referentes a “filas” o “columnas” de dicha estructura.

Pero para los rebeldes encontramos las bases de datos no estructuradas y orientadas a documentos, también conocidas como NoSQL. Uno de los logros que nos sorprendió en éste campo fue cuando durante la segunda mitad de la década de los 2000, un grupo de software empieza a entender la necesidad de mejorar la gestión de las bases de datos cuyo crecimiento es desproporcionado (e inclusive, exponencial en algunos casos). Delante de la abrumadora verdad de sus intenciones, y sabedores del hecho que no eran muy originales, cogieron del inglés “humongous” (enorme) y DB (siglas de “base de datos”), quedando en el ya tan conocido y usado MongoDB. Este se vale de su sistema jerárquico de colecciones en las que documentos contienen valores designados (o no) para cada caso dentro de dicho documento.

Todo el personal encargado de gestionar, analizar, guardar, tratar, trabajar… con datos, en algún momento de su transcurso laboral se hace la gran pregunta sobre su futuro: ¿Qué tipo de base de datos uso? Y, como la mayor parte del mundo, después de un análisis dedocrático, determinan que la mejor opción es esa que brilla más ante sus ojos.

Pero para el resto de los mortales curiosos, vamos a analizar (solo un poco) las dos opciones principales. Todos los conjuntos de bases de datos han nacido de un leguaje de programación y, como todos los lenguajes de programación, estos están pensados para un objetivo concreto en el que destacan por su gran ventaja respecto a los demás lenguajes de programación, ya sea en un proceso, campo de computación, sistema de cobertura y estructura de datos, u otros. De nuestros dos colosos salen dos premisas a tener en cuenta en adelante: en SQL todo son tablas en las que todos los campos contienen valores (incluyendo la opción del nulo), mientras que Mongo implica elementos (documentos) que mantienen patrones pero no todos tienen que contener todos los valores, ni tienen que contenerlos con el mismo formato ni condiciones.

NoSQL Databases

Basandonos en los estudios de IBM, Dimitry Dolgov y otros, vemos como algunas conclusiones emergen entre el caos. Benchmark (a grosso modo):

  • La mayor parte de los datos indizados o estructurados tienen mejor rendimiento con key values en dicho formato, decayendo en bases no estructuradas, para la extracción.
  • Las bases no relacionales se llevan mejor con las inserciones y eliminaciones de datos que las demás en casi todos los casos. (Exceptuando cuando PostgresSQL trabaja los datos con configuraciones o cláusulas de inserción, caso en el que bate récords).
  • En modificaciones de datos dentro de la base las no-estructuradas ganan por goleada (o “dateada”, en este caso).
  • En extracciones genéricas e inclusive con configuración, la relacionales contienen mejores parametrizaciones, pero en operaciones generales (contar todos los elementos, seleccionarlos todos con un fin computacional interno…) las no estructuradas rinden mejor.

Autor: Marc Vea

comments powered by Disqus