Bases de Datos ideadas para gestionar grandes volumenes

Con el crecimiento de internet, y de los proyectos web de mayor éxito, cada vez es más necesaria la utilización de bases de datos escalables y que sean capaces de gestionar con agilidad ingentes volúmenes de información.

Muchas veces las bases de datos tradicionales no cumplen con los requisitos de estos sistemas, o al menos no cumplen con un coste razonable, y así entran en juego proyectos de bases de datos open source especificamente orientadas a cubrir este vacío.

Un caso que ya hemos comentado es el de Cassandra DB, una base de datos distribuida de software libre que ya utilizan Digg, Facebook y Twitter.

Ahora acabo de encontrarme con otro proyecto que también promete bastante. Se trata de Hypertable, otro sistema de almacenamiento de datos Open Source y distribuido que anuncia un máximo rendimiento y escalabilidad para tratar grandes cantidades de datos. Tiene soporte comercial en www.hypertable.com y allí nos cuentan que ya lo utilizan buscadores como Baidu, Rediff.com o Zvents

Parece ser que el diseño de estos sistemas se inspira en el proyecto Bigtable, que creó Google para poder gestionar la gran cantidad de datos que mueven las aplicaciones y proyectos que van creando. Adjunto un pdf que proporciona Google con información sobre este proyecto.

Alguien ha probado Hypertable, o sabe algún caso más de utilización de este sistema de almacenamiento? Conocéis otras bases de datos o sistemas similares?

Adjunto también un documento de un test de rendimiento realizado por unos laboratorios de temas energéticos que se planteaban la sustitución de Oracle por Hypertable, y donde también se hace mención de Bigtable y GFS.

Qué interesante. Espero encontrar el momento para leer el adjunto, lo he mirado por encima y sin duda que merece una lectura detallada...

 

Respecto este tipo de base de datos, creo que su necesidad surge no tanto por los requerimientos de volumetría y escalabilidad como por el tipo de consultas que se realizan. Es decir, el tipo de queries que lanza Google, Facebook, Twitter o Digg son muy particulares, y no se asemejan a las consultas OLPT o las consultas OLAP a las que estamos habituados.... Por este motivo, nos necesarias estas bases de datos tan particulaes... Creo...

En respuesta a por Crono

Pues yo sigo pensando que la razón principal es poder obtener un buen rendimiento con grandes volúmenes de datos. Creo que el tipo de consultas, seguramente más simples, y sin necesidad de control transaccional es lo que permite desarrollar este tipo de soluciones orientadas a la eficiencia en las consultas sobre grandes volúmenes de datos. Por algo el proyecto de Google se llama Bigtable, no?

Yo veo en este sistema similitudes con los antiguos sistemas de almacenamiento en ficheros, antes de que aparecieran las bases de datos relacionales, y también con las estructuras OLAP. Son estructuras desnormalizadas, que se ordenan alfabéticamente por un campo clave para permitir el particionamiento físico de los datos, la distribución y las consultas eficientes, y que además incluyen un campo de fecha.

A mi me recuerdan mucho a una tabla de hechos de un Data Warehouse, y la siguiente pregunta que me viene a la cabeza es ¿qué pasaría si utilizáramos estos sistemas para soportar estructuras de DWH? Uno de los principales problemas que nos encontramos con gran parte de los proyectos de Business Intelligence, o al menos con los más grandes, es poder controlar el crecimiento de las tablas de hechos, y la escalabilidad suele estar limitada a la capacidad de los clústers que podamos crear en un CPD. Está claro que una solución distribuída de este tipo ampliaría mucho los límites físicos que nos hemos encontrado siempre en cuanto a volumetría.

¿Alguien sabe si ya se está haciendo? ¿Puede ser este tipo de arquitectura la que hay detrás de los sistemas Saas de Business Intelligence que van apareciendo?

 

Dejo una captura de la tabla que incluye el pdf con las características de algunas tablas de Bigtable que Google utilizaba en producción para varios de sus proyectos en el 2006. Las cifras ya eran impresionantes, y lo que habrán aumentado en 4 años de crecimiento..

Volumetría de Objetos Bigtable que soportan proyectos de Google en producción

 

Me parecen impresionantes también los datos que aportan en el apartado 7 sobre la evaluación de rendimiento que hicieron antes de poner el sistema en producción. Para el test utilizaron la friolera de 1786 máquinas con GFS, más los servidores del cluster de Bigtable:

 "We set up a Bigtable cluster with N tablet servers to measure the performance and scalability of Bigtable as N is varied. The tablet servers were configured to use 1 GB of memory and to write to a GFS cell consisting of 1786 machines with two 400 GB IDE hard drives each".

En respuesta a por Carlos

Ya he hecho la primera lectura del documento (y sin duda es necesario releerlo varias veces para entenderlo bien)...

 

Es evidente que el tamaño y los elevados requerimientos de rendimiento justifican por si solo una estructura de datos tan particular. Sin embargo, también el tipo de aplicación es muy particular, y no se trata de una solución de almacenamiento "multipropósito"..

 

Para empezar, se renuncia a la transaccionalidad, y admiten que sistemas tan distribuidos son vulnerables a muchos tipos de fallos (que serian fatales en otro tipo de aplicaciones...). A Google, por ejemplo, no debe importarle demasiado que se "pierdan" un porcentaje de sus rastreos (o de la sesiones de Google anlytics, o...). Otra desventaja evidente es sólo se puede acceder a la información a través del API (ni SQL ni nada parecido...), lo que dificultaría la ejecución de consultas ad-hoc tan habituales en sistemas BI....

 

Los tipos de consultas también son muy particulaes, aunque he de reconocer que el modelo de datos y el tipo de consulta de Google analytics no parece nada particular. Es decir, ¿Se podrían obtener resultados similares con DWH de Google Analytics más ortodoxo? Yo creo que sí (200Tb no son tantas... ¿no?)...

 

Respecto el modelo de datos, me quedo con la idea de que la BigTable no consiste en filas y columnas como estamos acostumbrados, sino que cada fila contiene información estructurada de un "hecho"... Es decir, cada celda puede contener listas de valores o estructuras más complejas (se parece, como dices, a los antiguos sistemas de almacenamiento en ficheros, tipo COBOL, o los más modernos XML...). De esta manera, por ejemplo, el registro de Google que contiene este comentario que estoy escribiendo contiene también todos los enlaces salientes y entrantes de esta páginas, y muy cerca están todas las páginas de DATAPRIX, y toda la información relativa a este dominio... En un sistema relacional clásico, esto no seria ni mucho menos así...

 

Preguntabas si estructuras parecidas se podrían emplear en DWH conveniconales, y evitaré contestarte porque me da la sensación que ya he especulado bastante en este comentario (mucho más que lo que me permite mi conocimiento sobre el tema)... :-)

 

Buenas, que bueno leer sobre NO-SQL esto en mi blog favorito de BI, para resumir BI es mi trabajo, y NO-SQL ues mi hobbie. Personalmente pienso que hay mucho potencial en las plataformas NO-SQL o bbdd orientadas a documentos. Entre los proyectos que revisé, además de CassandraDB pude ver que hay mucho desarrollo al rededor de couchDB y mongoDB.

  • Creo que el que mejores oportunidades ofrece es mongoDB ya que estube haciendo algunas pruebas y dejenme comentarles los mejores puntos:
  • Orientado a documentos: la orientación a documentos permite desarrollos rápidos, flexibles, y rápidamente adaptables a distintas situaciones. Está es claramente una ventaja para los desarrolladores en estas plataformas, que puede inclinar la balanza de manera importante frente a nuevos desarrollos.
  • Facilidad de uso: a 4 horas de haber leido el nombre en google, tenía un sharding (de maquinas virtuales) corriendo una base de datos en muchos shards al mismo tiempo.
  • Alta, alta, escalabilidad: la arquitectura de mongoDB esta pensada para no tener ningun cuello de botella.
  • Procesamiento distribuido: uno está más en control del procesamiento distribuido, gracias a la implementación de map reduce, en javascript
  • Lenguaje, y Objetos: basado en JavaScript (the world most popular lenguage) y orientado a objetos, es facil de aprender y de conceptos claros y solidos, muy aparejados a conceptos del mundo de la programación, lo que facilita su aprendisaje y compreension.

Realmente les recomiendo que le den una chance

Saludos

 

En respuesta a por picanteverde (no verificado)

Ya tenemos dos nuevas base de datos NO-SQL para examinar, gracias por tu aportación.

He echado un vistazo a mongoDB y la sensación es lo que comentas, que es fácil comenzar a trabajar con él. Me ha encantado el tutorial intereactivo que se han montado, te va explicando lo básico paso a paso, y debajo mismo de cada explicación puedes probar directamente en la misma linea de comandos, sencillo y eficiente.

Tutorial web por linea de comandos de MongoDB

Lo que estaría bien saber es si hay algún proyecto importante que lo esté utilizando, los casos de éxito siempre son una buena manera de hacerte una idea del alcance de los productos de software.

 

Aprovecho para añadir otra base de datos más a la lista. Se trata de HBase, otra base de datos open source distribuída y orientada a columnas que surgió inspirándose en la Bigtable de Google.

De hecho está dentro del proyecto Hadoop de la Apache Software Foundation, y se apoya en HDFS (Hadoop Distributed File System), el sistema de ficheros que se ha desarrollado en este proyecto ideado para sistemas que han de manejar grandes cantidades de información, y que también está inspirado en el GFS de Google.

En respuesta a por Carlos

Carlos revisando la página de casos de exito de mongo encontré que entre los más conocidos se pueden destacar:

sourceforge: estaría usando mongo db como solución completa de almacenamiento y no solamente para un sistema aislado

github: Muy conocida dentro del entorno de desarrolladores open source. estarían utilizandolo en una app de reportes.

EA y The New York Times: estarían haciendo pruebas en algunos sistemas aislados con grandes requerimientos de datos y estructuras no definidas.

 

Lo cual por pequeño que parezca tenemos que considerar que el sistema lleva solamente un año de desarrollo y su primer version estable lista para producción fue lanzada el 25 de marzo de 2010, asi es!!! 2010!!!.

Por lo que podemos esperar un rapido desarrollo y una comunidad altamente activa en torno al mismo.

Te comento que hice algunas pruebas con hadoop y terminaron en .... nada me fue realmente complicado levantar hadoop en una estructura de maq virtuales. por el contrario tuve un shard de mongodb de 6 maquinas corriendo en 4hrs

 

Saludos

En respuesta a por picanteverde (no verificado)

No había visto esta página. Realmente la lista es larga, y con nombres importantes, un buen comienzo si hace tan poco tiempo que se ha lanzado la primera versión estable.

Habrá que estar atentos a su evolución, seguro que dará mucho que hablar.

Y eso de que lo hayas montado en tan poco tiempo me está empezando a picar. Si encuentro el momento (o más bien las horas) a lo mejor hago algún intento..

En respuesta a por picanteverde (no verificado)

Para quienes se inician en el uso de MongoDB comparto con ustedes el vínculo del video tutorial MongoDB en 20 minutos https://www.youtube.com/watch?v=c8n6JsQuX2A

En este se explica desde su descarga, instalación, configuración, ejecución y uso. Es importante no solo instalarlo sino crear las carpetas data y db en el directorio raíz para empezar a operar, ya que esta es una omisión que puede hacer que no se avance cuando se está utilizando por primera vez (ver minuto 1:20)

Además de procedimientos prácticos incluye teoría clara y precisa. Se abordan los temas: crear bases de datos, crear colecciones, insertar documentos, eliminar colecciones, eliminar bases de datos, editar documentos, eliminar documentos, realizar consultas generales y específicas.

¡Herejes! Frank Codd se tiene que estar revolviendo en su tumba. ^_^

Me parece muy interesante el artículo, había oido hablar de este tipo de almacenamiento de información pero no había leído nada. No obstante, me da la impresión de que al final es como tener un gran tabla con toda la información desnormalizada que está organizada de manera jerárquica como las estructuras de inodos de los sistemas UNIX.

Hablo desde mi casi total desconocimiento de este tipo de repositorios que conste, he mirado MongoDb a raíz de los enlaces que habéis propuesto.

Lo tiene muy difícil contra el "Standard" Query Language, a parte de que las herramientas de explotación de datos tendrán que ser a medida claro. Con lo que la pasta que se ahorra uno en una licencia de un RDMS y en la herramienta de reporting se emplea en crear una herramienta de explotación de información desde cero, ¿me equivoco?

En respuesta a por cmateos

No creo que la intención de estos sistemas sea la de sustituir totalmente a los Gestores de Bases de datos Relacionales. Son una solución más adecuada bajo determinadas circunstancias, y su principal ventaja es la escalabilidad para soportar la gestión de muy grandes cantidades de datos.

El caso más claro es el de las grandes redes sociales, que están moviendo cada segundo cantidades de información que marean, y siguen creciendo.. Soportar esa escalabilidad con motores relacionales con licencia de pago puede llegar a salir muy caro, mucho más de lo que cuesta un desarrollo a medida.

Bajo mi punto de vista la discusión estaría en si en un entorno empresarial que mueva una cantidad importante de datos, pero no del nivel de redes sociales como Facebook o Twitter merece la pena optar por este tipo de soluciones NOSQL. 

Y aquí, respondiendo en parte a lo que comentas sobre herramientas, vemos que el Business Intelligence ya comienza a 'fijarse' en las plataformas de gestión de big data para soportar soluciones de BI. Pongo como ejemplo el caso de Pentaho de quienes justo hace unos días Stratebi publicaba en Dataprix el post Recursos sobre Pentaho y su integración con Apache Hadoop.

Si alguien conoce algún ejemplo más, que lo comparta, porque seguro que es un tema en el que vamos a ver muchas novedades a lo largo de este año.

hola buenas noches:

es muy interesenta todo este tema, sobre todos de los manejadores de BD, para tal cantidad de informacion, me intriga un parte de MongoDB, he escuchado muchas ventajas y bondades sobre ella, pero me surge la duda y que desventajas puede tener con la implantacion? otro tema que tengo duda he leido en articulos que las consultas suelen ser muy lentas .... al no tener Joins en MongoDB no existe ninguna posibilidad de que Joins como en una base de datos relacional. Esto significa que cuando se necesita este tipo de funcionalidad, es necesario hacer varias consultas y unirse a los datos de forma manual dentro de su código (que puede conducir a reducir la velocidad, el código disfuncional, y la reducción de la flexibilidad, cuando los cambios en la estructura)...

alguien puede compartirme mas sobre el tema? 

 

En respuesta a por ibett

Desventajas de MongoDB

  • Uso de la memoria. Como MongoDB almacena el nombre de la clave junto con cada documento, naturalmente consume más memoria. Además, como las consultas y uniones lentas no son posibles porque es necesario realizar una combinación dentro del código, a menudo debe tratar con datos duplicados.
  • No usa joins. Al igual que una base de datos relacional, las uniones simplemente no son posibles en MongoDB. Sin embargo, existe una alternativa que es $lookup
  • Es tecnología nueva. MongoDB no está tan ampliamente documentado o probado y también carece de la disponibilidad de soporte y expertos.
  • Seguridad. Falta de seguridad y regularidad. No ofrece integridad de la información

Respecto a tu comentario sobre los join, las bases de datos orientadas a documentos como MongoDB están diseñadas para almacenar datos desnormalizados. Idealmente, no debería haber relación entre colecciones. Si la misma información es requerida en dos o más documentos, debe repetirse. MongoDB 3.2 introduce el operador $lookup que puede realizar una operación parecida a un LEFT OUTER JOIN en dos o más colecciones.

$lookup solo se permite en operaciones de agregación, que son atributos adicionales para filtrar y agrupar un resultado. MongoDB $lookup no es un sustituto de la cláusula JOIN más poderosa que se ofrece en SQL. Tampoco MongoDB ofrece restricciones de integridad referencial.

Encontré este documento donde se comparan tiempos de ejecución entre Oracle (SQL) y MongoDB (NOSQL).
La base de datos NoSQL es más rápida que la base de datos SQL al actualizar y eliminar registros, es más flexible y puede almacenar grandes cantidades de datos con facilidad aunque también tiene sus desventajas.

 

Dentro de las alternativas de bases de datos podemos clasificarlas en bases de datos estructuradas o bases de datos SQL y bases de datos no estructuradas o bases de datos NoSQL.

Una base de datos estructurada puede definirse como:

Una colección de elementos de datos organizados en un conjunto de tablas formalmente descritas desde la que se puede acceder a los datos […] es un conjunto de tablas que contienen datos provistos en categorías predefinidas. Cada tabla (que a veces se llaman ‘relación’) contiene una o más categorías de datos en columnas. Cada fila contiene una instancia única de datos para las categorías definidas por las columnas. (TechTarget, 2015)

Las bases de datos no estructuradas también se denominan bases de datos NoSQL:

Las bases de datos NoSQL son sistemas de almacenamiento de información que no cumplen con el esquema entidad–relación. Tampoco utilizan una estructura de datos en forma de tabla donde se van almacenando los datos sino que para el almacenamiento hacen uso de otros formatos como clave–valor, mapeo de columnas o grafos. (Acens, s.f.)

Referencias:

Acens. (s.f.). Bases de datos NoSQL: qué son y tipos que nos podemos encontrar. Recuperado de https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf

TechTarget. (Enero de 2015). Base de datos relacional. Recuperado de https://searchdatacenter.techtarget.com/es/definicion/Base-de-datos-relacional

En respuesta a por Juan José Roja…

Hoy en día empieza a haber una tendencia alcista por la utilización de Bases de Datos No SQL, no obtante es muy importante en este punto insistir en que aunque parece que en estos momentos lo suyo es migrar a bases de datos NoSQL, debemos tener muy en cuenta antes de tomar esta decisión si las características de nuestra base de datos necesita una base de datos NoSQL o relacional.

Identifiquemos los siguiente:

  • SQL permite combinar de forma eficiente diferentes tablas para extraer información relacionada, mientras que NoSQL no lo permite o muy limitadamente.
  • NoSQL permite distribuir grandes cantidades de información; mientras que SQL facilita distribuir bases de datos relacionales.
  • SQL permite gestionar los datos junto con las relaciones existentes entre ellos; en NoSQL no existe este tipo de utilidades.
  • NoSQL permite un escalado horizontal sin problemas – por su capacidad de distribución-; mientras que escalar SQL resulta más complicado.

Las bases de datos SQL asemejan a la transmisión automática en los vehículos, y las NoSQL, a la manual. Una vez que se cambia a NoSQL, el usuario en el responsable de una gran cantidad de trabajo que en SQL, el sistema se encargaría de forma automática.

En la mayoría de las opiniones, una base de datos relacional puede ser usada los siguientes ámbitos:

  • Educación: para estructurar información, y aportar conocimiento lógico al estudiante.
  • Desarrollos web: para mantener jerarquía de datos, siempre y cuando la capacidad de concurrencia, almacenamiento y mantenimiento no sean de considerable dificultad y la información sea consistente.
  • Negocios: inteligencia y análisis de negocios, son temas que requieren el uso de SQL para facilitar el consumo de la información y la identificación de patrones en los datos.
  • Empresarial: porque tanto el software a la medida y el software empresarial, poseen la característica de mantener información con estructura consistente.

Mientras que básicamente NoSQL se utilizan en:

  • Redes sociales: casi obligatorio.
  • Desarrollo Web: debido a la poca uniformidad de la información que se encuentra en Internet; aun cuando también puede emplearse SQL.
  • Desarrollo Móvil: debido a la tendencia – en crecimiento- de Bring Your Own Device.
  • BigData: debido a la administración de grandísimas cantidades de información y su evidente heterogeneida.
  • Cloud (XaaS): “Everything as a service”; NoSQL puede adaptarse casi a cualquier necesidad del cliente, y sus particularidades.

 

Ampliando las referencias de bases de datos estructuradas y no estructuradas anexo dos tablas con alternativas comerciales y libres actuales:

Referencias:

Castillo Zúñiga, I. (s.f. a). Data Warehousing e Inteligencia de Negocios: Unidad I. Introducción a los sistemas de gestión de base de datos [Apuntes de curso]. Universidad Cuauhtémoc Aguascalientes.

Castillo Zúñiga, I. (s.f. b). Data Warehousing e Inteligencia de Negocios: Unidad II. Bases de Datos NoSQL [Apuntes de curso]. Universidad Cuauhtémoc Aguascalientes.

Si necesitas que tus datos se mantengan exactos y consistentes a través del tiempo, una base de datos SQL te lo garantiza. Esto es lo ideal en muchos sistemas intolerantes a las fallas, donde mientras menos aberturas dejes, mejor (por ejemplo la mayoría, quizá totalidad, del software bancario y empresarial). Aquí SQL te cuida las espaldas.

Pero también, que si tus estructuras de datos son propensas a cambiar, el SQL te puede perjudicar al imponer una estructura rígida (por ejemplo, si estas en las fases de prototipo o lanzamiento temprano de una app, donde los datos que guardas son más maleables).

Mientras que añadir llaves nuevas a un documento NoSQL suele ser muy fácil, modificar tablas SQL puede traer muchos inconvenientes si ya el sistema funciona con cierta estructura, y más aún si hablamos de introducir cosas como llaves primarias.

Esto último no es necesariamente malo, pues te obliga a pensar dos veces antes de cambiar las estructuras de datos, ahorrando bugs y modificaciones innecesarias en toda la DB.

Como podrán ver, SQL en general es más rígido y por ello puede dar garantías sobre losdatos, mientras que NoSQL da más libertades y comodidades sacrificando estas mismas garantías.

Con lo que:

  • Si se nececita que los datos se mantengan consistentes y las transacciones atómicas, disminuyendo los errores al máximo.
  • Si se tienen datos relacionados, y buscarás muchos datos en base a estas relaciones.
  • Si es necesario poder introducir gente al equipo de trabajo rápidamente.
  • Si es preferible algo ya probado y con abundantes herramientas y comunidades detrás.

Una buena opción a usar es una Base de Datos Relacional.

 

Mientras que:

  • La velocidad de lectura y escritura es más importante que mantener la consistencia.
  • No se sabe cómo se verá la estructura de los datos al final, y probablemente cambie mucho.
  • Es más fácil adquirir varias máquinas modestas a traves del tiempo que invertir en una sola muy potente.
  • Es preferible algo fácil de usar como programador, que no te exige compromisos y te deje almacenar casi cualquier cosa donde quieras.

NoSQL puede ser la solución.

 

Cada opción es una herramienta, y como toda herramienta, son buenos para ciertas cosas y para otras no tanto.

Un último factor que se debe tomar en cuenta es que ambos tipos de DB pueden coexistir en un mismo sistema: es sorprendente cuántas aplicaciones dejan sus datos más consultados en un almacenamiento NoSQL (para que las consultas sean rápidas), pero al momento de operaciones críticas como procesar pagos, llaman a una DB relacional para asegurarse de que nada salga mal.

En respuesta a por Jorge Sanchez

Bases de dates relacional y no relacional.

Es muy claro que hoy dia enfrentamos a dos grandes tipos de base de datos; a lo largo de este foro se ha  hablado mucho de la  necesidad de manejar grandes volumenes de datos en bases que Sean capaces  de ser escalables, gestionar con facilidad, que tengan un Maximo rendimiento, trazabilidad y algunos otros beneficios  adicionales.

Aunque se habla de  la existencia de nuevos softwares para  la gestion de grandes cantidades de datos por segundo  en el site de noticiasdelaciencia.com e  incluso  tambien se habla del process query system en el que se propone un nuevo paradigma algoritmico y de software que ofrecen una forma poderosa y genetica Para abordar Los desafios de procesamiento de eventos, no debemos perder de vista que  un apropiado  sistema de  gestión de datos nos puede  ayudar a tender un mejor manejo de los mismos a traves de  analizar y canalizar  la información por los mecanismos mas apropiados de acuerdo a su naturaleza.

Estoy de acuerdo con los comentarios anteriores referentes a MongoDB y yo pienso en que tienes que utilizar MongoDB dado que está liberada bajo licencia de software libre, guarda estructuras de datos BSON (una especificación similar a JSON “compilado”) con un esquema dinámico, haciendo que la integración de los datos en ciertas aplicaciones sea más fácil y rápida. aunado a lo anterior Mongo DB es un sistema de bases de datos no relacionales, multiplataforma e inspirada en el tipo de bases de datos documental y clave/valor. Dicha herramienta de base de datos es bastante rápida a la hora de ejecutar sus operaciones ya que está escrito en lenguaje C++.

 

les recomiendo estos dos libros para entender un poco más de MongoDB 

1.- Joseba Madrigal Marinas 2016 "MongoDB en Castellano".  

2.- Yohan Graterol. “Mongo DB en español”. Tomo 1 El principio.

En mi experiencia particular el mongoDB me ayudo a entender un poco más como se manejan las bases de datos NoSQL, ya que en la licenciatura lo único que se vimos fueron las bases de datos relacionales, más específicamente el SQL Server. Es muy sencillo de usar y sobretodo la instalación no genera tantos problemas como el SQL Server.

Sé que la novedad son las bases de datos tipo NoSQL y todo mundo quiere implementarlas sin siquiera considerar si la base de datos del software entra dentro de las circunstancias especiales para ser considerado Big Data. 

He estado buscando algunos parámetros exactos para saber cuándo la cantidad de información se puede comenzar a considerar Big Data, pero solo mencionan que es "cuando la base de datos contiene varios terabytes". Al final me he ido a la página de Oracle y me gusto la definición que ellos dan, donde menciona que tienen que ser grandes cantidades de información, pero hacen hincapié en que es información no estructurada y que por lo regular se considera como información basura.

Por otra parte, sería interesante ver una comparación de SQL Server y MongoDB, con las mejoras que implementó Microsoft el año pasado.

Les dejo las referencias, para consulta.

Microsoft. (03 de 11 de 2019). Sql Documentation. Obtenido de ¿Qué son los Clústeres de macrodatos de SQL Server?: https://docs.microsoft.com/es-es/sql/big-data-cluster/big-data-cluster-overview?view=sql-server-ver15

Oracle. (11 de Agosto de 2014). Oracle.com. Obtenido de What is Big Data?: https://www.oracle.com/big-data/guide/what-is-big-data.html