Es sin duda uno de los temas más provocativos y que más me está llamando la atención del análisis de la tendencia que está suponiendo el fenómeno Big data en los estamentos empresariales: la enorme dificultad para entenderlo sin bajar hasta la sistemática que lo sustenta. Un tema sin duda relevante: mientras se intente explicar Big data «recetando» como fórmulas mágicas los informes de analistas como Forrester, McKinsey, Gartner, etc. o recurriendo a casos de aplicación, el directivo medio no será capaz de entender lo que realmente subyace detrás de este mundo, y mucho menos, sus posibilidades.
¿De qué hablamos realmente? Para mí, la mayor dificultad inherente a entender la diferencia que supone Big data es hacerse a la idea de lo que supone pasar del esquema de base de datos que todos conocemos a distintos niveles, a la idea de bases de datos no relacionales o NoSQL. Un mundo que suele definirse en negativo, por «lo que no es», lo que añade todavía más dificultad conceptual.
Suena intimidatorio, pero espera, no desconectes todavía :-) Vamos a intentar aproximarnos al concepto: las bases de datos basadas en SQL (Structured Query Language, o lenguaje de consulta estructurado) es lo que la gran mayoría de los usuarios conocen. Lo pueden conocer a muy diferentes niveles: desde quien opera con ellas, maneja el lenguaje como tal, entiende las reglas de normalización de una base de datos convencional o es capaz de analizar sus limitaciones; hasta quienes simplemente se las imaginan como un gran sistema electrónico de archivos a modo de cajones y carpetas de un archivador. Una base de datos relacional basada en SQL, típicamente gestionadas con sistemas como Oracle, MySQL, DB2, Informix, Microsoft SQL Server, Sybase, PostgreSQL, etc, supone una operativa que nos resulta, por así decirlo, «natural»: sigue las reglas ACID (Atomicity, Consistency, Isolation y Durability, o Atomicidad, Consistencia, Aislamiento y Durabilidad), lo que permite que las instrucciones puedan ser consideradas una transacción, y responden a una visión sencilla, en la que un dato se almacena de una manera inequívoca y con unas relaciones definidas. La visión de tablas con filas y columnas en las que una consulta siempre devuelve los mismos campos.
¿Qué pasa si extendemos el concepto para dar cabida a otro tipo de realidades cada vez más frecuentes en la operativa habitual en nuestros días? ¿Acaso todo dato tiene claras estas estructuras? ¿O simplemente estamos dejando fuera de nuestros análisis todo aquello que nuestra operativa de bases de datos no es capaz de recoger? Las bases de datos NoSQL (Not Only SQL, no supone que SQL esté muerto o no deba usarse, sino que hay soluciones mejores) suponen relajar muchas de las limitaciones inherentes a las bases de datos convencionales y a la forma de trabajar con ellas. Colecciones de documentos con campos definidos de manera laxa, en lugar de tablas con filas y columnas, que permiten análisis mucho más rápidos y eficientes y, sobre todo, no limitados a la estructura convencional. La idea es almacenar datos de manera masiva, lo que responde muy bien a la enorme riqueza de datos que genera el mundo actual, y analizarlos sin seguir necesariamente unos estándares que no necesariamente se adaptan a ellos. Donde las bases de datos relacionales resultan costosas y lentas, la alternativa NoSQL resulta mucho más eficiente y barata para manipular datos sin tener necesariamente que adaptarlos a una estructura rígida. En puridad, un sistema de este tipo no es siquiera una base de datos entendida como tal, sino un sistema de almacenamiento distribuido para gestionar datos dotados de una cierta estructura, estructura que además puede ser enormemente flexible.
¿El problema? Para la mayoría de la gente, la dificultad de «pensar» en un sistema así. Nuestros esquemas mentales se adaptan a un sistema rígido, con normas claras y estructuras marcadas. Los paralelismos con los almacenes divididos en estanterías, archivadores y carpetas son algo que nos funciona mentalmente. Sin embargo, ¿cómo gestionar con un sistema de este tipo, por ejemplo, búsquedas enormes en bases de datos que contienen referencias completamente heterogéneas entre sí y con relaciones de todo tipo, no necesariamente únicas? En muchos casos, hablamos de sistemas que han sido precisamente desarrollados por empresas como Google, Yahoo!, Facebook y similares para gestionar sus propias operativas, usando casi siempre código abierto, con el fin de obtener una estructura que, con un coste y un rendimiento razonables, les permita tratar enormes cantidades de datos con muchísimas relaciones muy complejas entre sí.
En cierto sentido, para entender el tema es preciso «desaprender». Pero la necesidad de hacerlo es evidente, dada la adaptación de este tipo de estructuras a las problemáticas de operar en el mundo en que vivimos actualmente. Pero no es sencillo: durante algún tiempo, muchas empresas seguirán o bien torturando sus sistemas de bases de datos relacionales hasta el infinito y más allá con costes y rendimientos sencillamente absurdos, o directamente perdiéndose un mundo analítico que no son capaces ni de plantearse cómo recoger. Un mundo del que van a surgir muchas de las ventajas competitivas que veremos en el futuro.
Estimado Enrique:
Ya es la segunda vez que leo con sorpresa en un post tuyo de BigData las siglas ACID. Dichas siglas se corresponden a propiedades de las transacciones, y por lo tanto tienen sentido únicamente en un sistema transaccional (donde estemos hablando de modificación de datos y no de su análisis).
Como yo tenía la idea de que en BigData lo realmente problemático era precisamente el análisis, te agradecería si tienes un rato que nos aclararas cuál puede ser mi error y si alguno de los frameworks a los que te refieres soporta cualquier tipo de actualización.
Gracias de antemano. Saludos,
Enrique, mi sensación, desde una perspectiva muy técnica, es que te estás metiendo en un berenjenal. Las bases de datos relacionales son una tecnología muy madura, ni lenta ni costosa (hay una magnífica oferta de productos gratuitos de código abierto) y que se adapta como anillo al dedo para la mayoría de los proyectos de la mayoría de las empresas.
Es cierto que existe un nicho en que resulta más conveniente renunciar a las enormes ventajas que ofrecen las bases de datos relacionales y tiene sentido decantarse por otro tipo de productos ad hoc. Y ocurre que un puñado de empresas han ocupado ese nicho, reducido pero lucrativo, con sus productos. Nada que objetar.
Sin embargo, lo que está ocurriendo con el «movimiento» No-SQL (que caritativamente traduces como «not only», cuando no era ésa la intención original) es que esos fabricantes están promoviendo una ingeniosa campaña publicitaria, en que se venden sus productos como una «revolución» contra el «orden establecido», intentando expandir su clientela a las aplicaciones normales que están muy bien surtidas con la actual oferta de bases de datos relacionales, argumentando que No-SQL es más «moderno» o «rápido».
Este enfoque tiene varios problemas, empezando porque los productos No-SQL tienen un grado de madurez muy problemático. Te aconsejo que hagas una búsqueda en sitios técnicos sobre las malas experiencias que muchas empresas están teniendo con su implantación.
En este embrollo los técnicos somos a la vez culpables, siempre dispuestos a probar el último «juguete», y víctimas, pues después somos los que tenemos que rompernos la cabeza para lidiar con las tremendas limitaciones de No-SQL, tanto en madurez como en diseño.
Si tienes una base de datos «tradicional» (entre comillas porque el modelo de No-SQL es exactamente lo que existía hace 40 años y afortunadamente fue desplazado por el modelo relacional), mi consejo es resistirse a toda costa a estos cantos de sirena. Una pista: si tienes dudas sobre si No-SQL es adecuado para tu empresa, la respuesta es NO.
Excelente articulo enrique,
Sabe que es lo mas preocupante de este tema, es el hecho de que aparentemente nadie sabe que tiene la necesidad de tratar de entenderlo y del impacto directo que tiene sobre su negocio conocerlo o no. Creo que ahi es donde esta el key del asunto.
Saludos.
La forma de pensar en este tipo de bases de datos, es pensar como lo hacemos en el mundo real y no en el mundo digital. Si yo soy deteective y quiero hacer un dossier sobre «Emilio Botin», primero recabaré toda la indformación a mi alcance en la que aparezca «Emilio Botin» y luego haree un estudiio de las palabras que aparecen más repetidamente en esos documentos, por ejemplo «Banco de Santander» y «Ana Paticia Botín»m obteiendo por estadística en cada lote de documentos que tiene esas palabras «clave» otras palabras que ser+am el nexo entre Bitin y esos nodos, por ejemplo «Presidente» en el grupo de dcumentos que dice «Banco de Santander» e «Hija» en los que aparece «Ana Patricia Botín» (entre otros que aparecerán))
Iteraré el método utilizando como semillas las palabras obtenidas en el primer ciclo «Bamco de Santander», «Ana Patricia Botin», etc, y ganaré un nuevo circulo de relaciones y nexos entre ellos, de forma que con cada nuevo nivel, tendré una capa más amplia de las reelaciones potenciales de Botín y el motivo por las que ezisten.
No es muy difícil de concebir el sistema, captar los documentos mediante buscadores tipo Googlees y un posterior análisis del contenido de los documentos por frecuencia de conceptos, para obtener nodos y nexos de unión de la red de intereses del sujeto sometido a estudio,
Luego es fácil seguir que intereses tiene Botín en el mercado Inmobiliario, o cual es la mejor conexión entre Botín y las carreras de galgos. Como ha descubierto Facebookm todo esta en 4,75 niveles como media. Este sistema te indicaría por donde va el camino más corto,
Genial, me has ahorrado algo de tiempo para prepararme la siguiente clase de sistemas de datos distribuidos a mis alumnos. les dirigiré a este artículo para empezar a hablar de NoSQL. Un ejemplo claro de sistemas donde los nuevos paradigmas tienen cabida es en los que utilicen geo localización. Las relaciones entre puntos de interés no están fijadas sino que van creciendo con el uso y van mas allá de la proximidad. Es el caso de Foursquare y la integración con Facebook y otras redes sociales. Enhorabuena.
Sin ser un experto en base de datos, encuentro cierto parecido en tu formulación de la idea con el paradigma de la lógica difusa. ¿Big data=Fuzzy Databases?
#001: Jose Manuel, fíjate en el uso que doy al acrónimo, porque lo uso exactamente en el mismo sentido que tú: que las bases de datos NoSQL que se plantean en Big data son precisamente bases de datos que no buscan como finalidad proveer garantias ACID (salvo excepciones). Y que, de hecho, no suelen proporcionarlas. Eso, sin embargo, no quiere decir que no soporten actualización, porque una de las principales habilidades de este tipo de bases de datos es la capacidad de soportar cargas pesadas de procesos de lectura y escritura, como los que se usan en tareas de indexación masivas (motores de búsqueda) o en clasificaciones algorítmicas complejas, como el rankeado dinámico en filtros de presentación. Las garantías de consistencia suelen ser débiles (de nuevo, salvo excepciones), pero la eficiencia para aquellos procesos adecuados es enormemente superior.
Gorki: Pues yo también razonaría así pero lo que me parece nos dice Enrique es algo más complejo que relacionar palabras claves (en este caso Botín), indexarlas, y extraer conclusiones. Un dossier así elaborado te podría arrojar como los familiares famosos del Sr. Emilio a los «Sobrinos de Botín», solamente por la cantidad de referencias que uno encuentra en la red sobre este establecimiento. De tal manera que para obtener conclusiones fiables habría que ampliar el análisis a toda la data existente, además del propio término de interés, para que una simple «guía de restaurantes» ajena a tu búsqueda principal, te sirva para descartar el error evidente; y mientras más data disponible mejor.
Un análisis matemático o estadístico tiene limitaciones que el procesamiento de datos puede superar, por ejemplo, no sólo decirte cuánta gente podría comprar el producto X sino también cuánto lo desean o lo valoran o qué tan importante es para ellos. Pero para lograr esto tendrías que meterte en la mente de las personas, conocer su comportamiento pasado para predecir su comportamiento futuro, extraer algo más que palabras claves como son las actitudes, malhumores, prejuicios y demás rasgos de la personalidad que tan generosa e inadvertidamente vertemos en la red. De allí la obsesión casi enfermiza de que toda la vida del ser humano deje una huella digital, desde un like en FB hasta la ubicación de un peatón a través de 4SQ o lo que tienes o no en una refrigeradora con conexión a internet.
Yo creo que las pymes, tan sumamente presentes en nuestra economía, aún no están preparadas para el cambio. Es aún en muchas grandes en empresas y se sigue usando lo tradicional. Cambiar las estructuras y modelos de trabajo supone tiempo y coste, y ahora creo que no es el mejor momento para emplearlos, por lo creo que tardará en llegar la innovación en este sentido.
Las bases de datos sql, seguirán teniendo mucho camino, sólo sitios enormes les puede hacer falta bases de datos nsql, no tiene gran sentido para proyectos pequeños y medianos, es lo que entiendo después de oír a gallir en un podcast de daboblog.
#008 Mario
En este tipo de búsquedas se utilizan estadísticas bayesianas, basadas en probabilidad de acierto, más que en certezas, Los resultados están sujetos a error, por lo que es posible que hagan a Botín «restaurador de un meson» pero es poco probable, porque no solo utilizan el término «Botín» sino ademas «Emilio», «banco» o «banca», «finanzas» etc., debidamente ponderados cada término, de forma que si la suma de los términos que aparecen en un documento multiplicados por su indice superan un valor umbral, el elemento se da como válido y si no, no.
No te puedo hablar en exceso sobre las estadísticas bayesianas, porque no las he utilizado nunca. Es la estadística que se utiliza principalmente en IA en cosas como identificar caras, OCR, visión artificial y cosas por el estilo.
Tengo que dar las gracias a Enrique por este artículo,ya qué aunque no consigue aclararme en
qué consiste big data, a dado pie a Gorky a darnos una gran lección.
Creo qué es un error tratar de explicar en qué consiste un sistema diferente al comunmente utilizado sin describir el problema qué resuelve mejor qué los sistemas relacionales.
Gracias por tu aportación Gorky.
Un tema bastante complejo e «intimidatorio». Y leyendo algunos comentarios da incluso la sensación de que pocos saben de que se habla aunque hasta discutan entre ellos acerca de lo que suponen. Aunque, eso sí, sin intimidarse nada ante el desafío.
#010 «sólo sitios enormes les puede hacer falta bases de datos nsql, no tiene gran sentido para proyectos pequeños y medianos, es lo que entiendo después de oír a gallir».
Pues parece que eso tampoco es del todo cierto.
«Aunque esta tecnología surgió de unas necesidades muy concretas, su difusión y algunos proyectos para encapsular sus funcionalidades y hacerlas más amigables a desarrolladores acostumbrados a SQL está provocando que también se usen en proyectos de pequeño tamaño.»
http://www.opiniontecnologica.com/aplicaciones-informaticas/130-bases-de-datos-nosql-y-escalabilidad-horizontal.html
Recientemente he estado evaluando MongoDB, una de tantas bases de datos no-sql. He utilizado además un driver para C# con bastante buen resultado. En una hora tenía la base de datos montada y un sencillo ejemplo que insertaba y leía documentos (documentos en el sentido definido para esta base de datos). Mi opinión es que este tipo de bases de datos van a tener un largo recorrido, pero tenemos que enfocar viejos problemas de otra forma diferente, al igual que ocurre a menudo en el desarrollo de software. Por poner un ejemplo, el CMS Drupal tiene ya extensiones que usan MongoDB y, si no me equivoco, sistemas de búsqueda de indexación como Solr también usan bases de datos no-sql, vamos, que ni es algo nuevo y todos los días indirectamente en cuanto abrimos varias webs usamos bases de datos no-sql.
Hola enrique,
coincido con el comentario numero #2. Hay muchas compañias tecnologicas de gran calado que han optado por soluciones No-SQL , algunas por necesidad, otra simplemente por querer ir «por delante» usando y/o probando cualquier cosa nueva que permita a la compañia ser mas «cool». Sinceramente, creo que desde tu posicion de profesor no conoces bien las implicaciones de un proyecto enorme basado en SQL (funcional, estandar y con solo algun problema de volumen) y de las trabas administrativas que implican las soluciones NoSQL (llevar desde codigo la integridad referencial, la madurez de dichas soluciones..etc).
En mi experiencia, no hay nada que no se pueda hacer con otras soluciones sin tener que recurrir a casi «betas» de todo lo que hay No-SQL, y para mi, insisto, desde la experiencia, no baso nada de mis productos en No-SQL pues los he probado y al final necesito mas horas de ingenieria (o mas gente para mantenerlo) que unos buenos wrappers sobre la base de datos relacional normal.
Dicho sea de paso, probar es gratuito, pero creo que no dominas el tema y te has metido en un charco (con todos mis respetos) que te viene grande.
#015: Puedes estar de acuerdo o en desacuerdo, y bienvenidas sean ambas posturas. Pero el juicio de valor final sobra, es absurdo. ¿Me conoces? ¿Sabes si tengo o no preparación para hablar de este tema? ¿Sabes si a lo mejor tengo un doctorado en sistemas de información en una de las mejores universidades del mundo y si me he pasado horas y horas estudiando normalización de bases de datos, sistemas de gestión y todo lo relacionado con el tema, leyendo literatura academica para preparar un major field exam y estudiando las alternativas de los diferentes vendors? No sé a cuanta gente conocerás que haya leído, escrito y estudiado más de ese tema que yo, pero plantéate que a lo mejor, no es tanta. Estoy hasta los mismos de que cada vez que alguien no está de acuerdo con algo venga y te suelte con condescendencia eso de «uy, te has metido en un charco…», como si no existiese la posibilidad de que uno estuviese preparado para escribir sobre lo que escribe, y como si el hecho de que llevase ocho años escribiendo sobre tecnologia públicamente y teniendo cada vez más éxito fuese casual, fruto de algún tipo de fenómeno de alucinación colectiva, de ser capaz misteriosamente de llevar a cabo esa misión imposible de engañar a mucha gente durante mucho tiempo. Si escribes «con todos mis respetos», el respeto empieza por no llamar ignorante al que tienes al otro lado. Opiniones, las que quieras. Descalificaciones, por favor, las justas. Tu último párrafo, sencillamente, sobra.
Pues yo estoy de acuerdo con #2. Lo del NoSQL es en buena medida marketing. Las bases de datos NoSQL son buenas herramientas que tienen su aplicacion en un nicho (bastante pequeño) de mercado, aunque puede darse la circunstancia por variados motivos de que terminen ocupando mas espacio de lo que le corresponde.
Por un lado se esta banalizando el aprendizaje de lo relacional. El codigo SQL se considera «boilerplate» y se evita utilizando herramientas como Hibernate, que no es que afinen mucho precisamente, o frameworks CRUD que automatizan funcionalidades enteras a costa de eficiencia. Tampoco se optimizan los diseños de bases de datos. Hay una verdad escrita en piedra que es lo que sale de la herramienta de dibujitos, y proponer una desnormalizacion para mejorar el rendimiento es ganarse la excomunion. Hacer un explain de una sentencia se considera trabajo del DBA. Incluso escribir un procedimiento almacenado es en muchos sitios trabajo para el DBA…
Si a que las cada vez mayores necesidades de datos añades que la solucion SQL cada vez es peor porque se trabaja menos, es normal que por poco ruido que metan los del NoSQL se les escuche, pero no deja de ser una vuelta atras, porque NoSQL es lo que se tenia antes y se abandono porque para cosas que no sean sencillas (que no quiere decir que no sean importantes. La BD de Twiter no debe ser muy complicada) degenera en un carajal donde a la larga no hay manera de encontrar nada. Al que haga un Datawarehouse con NoSQL $DEITY le castigara cuando haga el Dataminning.
NoSQL es un revival del pasado, es como volver a los pantalones de campana. Hay a quien le sientan muy bien y se puede morir si ellos (sitios con un trafico enorme) pero cuidado con proponerlo como la bala de plata. Relacionar dos facturas usando clave-valor en un MongoDB debe ser un infierno para una pyme.
PD: ACID trata de transacciones, no de como se organice la informacion. Las NoSQL pueden ser ACID, pero como eso lleva trabajo, seran mas lentas y perderan la (unica) ventaja que tienen con el SQL. El SQL es mas lento porque hace mas cosas, como llevar transacciones. Hay una base de datos SQL llamada MySQL que es rapida si no tiene ACID y como las demas si lo tiene.
#017: Es que ese es el punto, NoSQL no sustituye a SQL. Infinidad de procesos se seguirán llevando a cabo mediante BBDD de toda la vida, perfectamente normalizadas y con sus herramientas conocidas. En algunos casos, bien por volumen, por eficiencia, por coste o, y me interesa especialmente esto, por posibilidades analíticas diferenciales, se optará por NoSQL. En ocasiones veremos cómo algunos procesos van pasando de SQL convencional a estructuras destinadas a optimizar su rendimiento mediante shards y elementos similares, y posiblemente a terminar en NoSQL, pero dejando una parte, la transaccional pura y dura, en un núcleo SQL con ACID. O veremos cómo algunas herramientas NoSQL incorporan ACID – ya las hay – pero al hacerlo, se desmarcan de otras que no lo hacen y que ofrecerán mejores ventajas para otro tipo de procesos. La cuestión, y a lo que iba la entrada, es a que resulta difícil o imposible explicar Big data si no nos metemos en el tema de las bases de datos con un cierto nivel de profundidad.
Hola Enrique,
Después de leer el artículo y de haberme entretenido también con los comentarios, justamente me disponía a preguntar -desde la ignorancia- lo que respondes en el último comentario (018), que «NoSQL no sustituye a SQL».
Sabiendo esto, aprovecho para profundizar un poco más en este tema. Me pregunto si el NoSQL va a proporcionar soluciones cada vez más accesibles al desarrollador en lo que pueda evolucionar la arquitectura de la información; y si esto va a suponer un cambio de paradigma en las bases de datos o se trata más bien de una simple y lógica ampliación tecnológica -si es que es posible hacer una predicción aproximada-.
Aclaro que no soy un experto ni informático. Programé bases de datos en Access, y hace solamente un año que empecé a tocar SQL para trabajar en proyectos web.
Desde ya, muchas gracias.
Hay que tener cuidado de no perder el norte. La mayoría de las empresas ni necesitan NoSql ni necesitan BigData.
» La idea es almacenar datos de manera MASIVA, lo que responde muy bien a la enorme riqueza de datos que genera el mundo actual, y analizarlos sin seguir necesariamente unos estándares que no necesariamente se adaptan a ellos. »
Lo dicho, la mayoría de las empresas no necesitan almacenar datos masivos. Miedo me da que algún iluminado se ponga a crear presupuestos para webs NoSql + hadoop como requisitos para una web con tráfico estándar. Todo lo contrario, ACID es una gran ventaja, no prescindas si puedes evitarlo. Facebook usa Mysql como storage principal por ejemplo.
Con NoSql prescindes de todo un modelo relacional con lo que necesitas tener código para cosas que antes facilitaba la propia base de datos.
# 020 lector
Tampoco hay que pensar que todo absolutamente todo pasa por gigantescas bibliotecas de datos y poderosas máquinas de búsqueda.
Por poner ejemplos cutres, unas solas alertas en Google pudieran considerarse como procesos Big Data, ( o Data Mining. que se llamaba en mis tiempos), otro cutre-ejemplo es por ejemplo los programas (de pago, pero baratos), que ordenan los los twit de las personas que sigues por relevancia, de forma que puedes seguir a 4000 personas que te interesan y leer solo cien que serán los que contienen, teóricamente y en el 80% de los casos en la práctica, la «chicha» de la información.
Del primer caso aquí tiene un servidor, ya jubilado que hace uso de ellos, del segundo caso conozco un pequeño industrial que lo hace, (se dice el pecado, pero no el pecador) y yo mismo estoy pensando en utilizarle, ante la avalancha de twits que ecriben las solo 49 personas que sigo´
Ciertament las necesidades de Iberia o El Corte Ingles son otras y el dinero que puede dedicar a resolverlas es mas abundante, que las necesidades que puede tener los Tranvías de Parla y un chino del «todo a 100», pero el ser pequeño no quiere decir que no se preocupe del tema en su modesta medida.
#20 Totalmente contigo (y con #17), aunque sin duda más de uno se debe haber dejado ya engañar por los vendemotos tecnológicos, que ante cualquier nuevo término con nombre chachi en inglés se lanzan con furia a estafar a incautos. La inmensa mayoría de las empresas e instituciones tienen más que de sobra con las BBDD tradicionales y no necesitan ni NoSQL ni gaitas.
Yo lo que todavía no entiendo es qué demonios pinta el ACID en todo esto. Circunstancialmente, en una base de datos con acceso masivo a datos y distribuída habrá que renunciar en general a la transaccionalidad si queremos unas prestaciones decentes, pero eso no es ninguna ventaja, sino un problema que no queda más remedio que aceptar (¡y que cada aplicación/sistema debe resolver de alguna forma!). Pero vamos, que esto no define en absoluto un esquema no relacional, es algo circunstancial y de hecho conceptualmente puede haber esquemas NoSQL transaccionales sin ningún problema.
Por último, hablar de que las bases de datos relacionales son «costosas» frente a las soluciones «baratas» NoSQL suena un poco raro cuando hay sistemas relacionales de software libre de instalación y uso triviales y buenísimos. Otra cosa es que en determinadas situaciones no valgan para un uso concreto, pero el precio no tiene nada que ver en ello.
Enrique’ de ves en cuando leo tus articulos. Algunos me paracen muy bueno. Otros excelentes. Pero este en particular me resulto inexacto. Con poco sustento en tus opiniones. Ausencias de puntos muy importantes sobre bbdd y sistemas de almacenamiento de informacion como nosql. La nube o otros similares.
Trabajo como dba desde 1994 formalmente. Pero desde 1986 tenia cpm y db2 en mi pc. En la escuela.
Pase por varias etapas en productos como clipper. Dbase 3+. Foxbase y luego oracle. Sql ser y mysql. Y ahora tambien experimento con nosql.
Te cuento todo esto porque creo que en tu post has omitido las opiniones de un dba con experiencia en varios entornos que te podria haber comentado mas cosas de las que has omitido.
Ahora sobre el tema. Un motor de bbdd hoy en dia es un componente de toda la solucion de «informacion» que te puede ofrecer oracle o sqlserver. Estoy certificado en ambos y por eso te lo certifico. Aunque seguramente db2 tambien lo haga. Pero no te lo pueda confirmar. La informacion se sigue guardando como desde que codd en ibm definio en los 80 el concepto rdbms. En estos ultimos 10 años la informacion que queremos almacenar crecio tanto y ademas queremos acceder a ella en todo mmento y ademas compartirla con muchos mas. Quizas millones. Entonces ante el problema de volumen y simultaneidad aparecen soluciones de almacenamiento que NO son rdbms. Creo que tu comparacion en tu post no deberia estar en esa linea. Porque es un error comparar peras y manzanas aunque parezac frutas ambas.
La solucion nosql es «algo» que nada tiene que ver con una bbdd y se parece mas a una carpeta con carpetas y documentos. Tecnicamente hablando.
El acceso esta pensado para ser rapido y masivo y replicado en varios sitios. Y esta bien que asi sea.
A las preguntas de » si no recibo tweet? Que pasa»
«si desaparecio una transferencia con mi nomina? Que pasa»
Ahi tienes el porque no se pueden comparar las cosas. Ni sus resultados. Ni sus metodos.
Hoy en dia los rdbms pueden almacenar «todo» igual que nosql. Simplemente que se enfocan en la pregunta dos.
Y no muestran que tambien dan soluciones a la primera pregunta.
Ese es el resumen
Perdon por los errores en escritura pero el texto lo tipee en un movil.
#jubete
comparto totalmente lo que has puesto. NoSQL es volver a los ficheros indexados, y a los 70. PERO con un marketing BRUTAL!.
no esta mal que exista la solucion, ni que se implemente, pero insisto que es comparar peras y bananas.
#GORKI
excelentes tus comentarios. todos.
#Sobre el comentario
«¿Sabes si a lo mejor tengo un doctorado en sistemas de información en una de las mejores universidades del mundo y si me he pasado horas y horas estudiando normalización de bases de datos, sistemas de gestión y todo lo relacionado con el tema, leyendo literatura academica para preparar un major field exam y estudiando las alternativas de los diferentes vendors? »
El doctorado lo puedo creer, pero eso no garantiza excelentes conocimientos sobre bases de datos, experiencia de muchos años y un «señority» en el tema.
sobre «si me he pasado horas y horas estudiando normalización de bases de datos» efectivamente esta claro que NO lo has hecho.
leyendo los demas posts, veo gente muchisimo mas experta que tu en el tema, un error que creo que cometes es pensar en «tu vision» con la «unica valida», cuando a entender de varios (yo incluido) es que esta un poquitin fuera de foco.
Me hace gracia ver que mucha gente no se ha molestado en leer el artículo de verdad, y se han conformado con una lectura en diagonal antes de comentar.
Hasta donde yo he leído -Enrique corríjeme si me equivoco- el objetivo del artículo no es dar una clase magistral sobre Big data, ni sobre bases de datos NoSQL, ni sobre las ventajas de un sistema sobre otro, o sobre si SQL está muerto o no. La idea que extraigo de este artículo es que esta tecnología no es algo de lo que se pueda permanecer ignorante sin sufrir consecuencias a medio plazo. Al contrario, la comprensión de esta tecnología nos permitirá añadirla a nuestra caja de herramientas mentales, y aplicarla de forma racional, más allá del marketing o del hype tecnológico del momento.
El volumen de información disponible en internet crece por minutos y cada día surgen posibilidades de análisis nuevas, y eso son nuevas oportunidades de negocio, que no pueden ser abordadas con los sistemas transaccionales tradicionales. La importancia de los resultados de estos análisis es evidente para los gigantes de internet, Google, Microsoft, Facebook, etc. Pero eso no significa que esta tecnología sea totalmente inútil para pequeñas y medianas empresas. Sólo hace falta que alguien comprenda realmente lo que le ofrece Big data, sea creativo, ate todos los cabos, y encuentre una manera de sacar beneficio del caos.
Y no, Big data no es sólo un retorno a los años 70. Las cosas nunca son tan simples.