El resultado fue SQL, presentado por primera vez al mundo en 1974. Durante las siguientes décadas, SQL demostraría ser inmensamente popular. A medida que las bases de datos relacionales como System R, Ingres, DB2, Oracle, SQL Server, PostgreSQL, MySQL (y otras más) se apoderaron de la industria del software, SQL se estableció como el lenguaje preeminente para interactuar con una base de datos, y se convirtió en la lengua franca de un ecosistema cada vez más concurrido y competitivo.
(Lamentablemente, Raymond Boyce nunca tuvo la oportunidad de presenciar el éxito de SQL. Murió de un aneurisma cerebral 1 mes después de dar una de las primeras presentaciones de SQL, con sólo 26 años, dejando atrás a una esposa y una hija pequeña.)
Durante un tiempo, parecía que SQL había cumplido con éxito su misión. Pero entonces ocurrió Internet.
Parte 2: NoSQL contraataca
Mientras Chamberlin y Boyce desarrollaban SQL, lo que no sabían es que un segundo grupo de ingenieros en California estaba trabajando en otro proyecto en ciernes que más tarde proliferaría ampliamente y amenazaría la existencia de SQL. Ese proyecto era ARPANET, y el 29 de octubre de 1969 nació.
Pero en realidad SQL estaba bien hasta que apareció otro ingeniero e inventó la World Wide Web, en 1989.
Como una mala hierba, Internet y la Web florecieron, alterando masivamente nuestro mundo de innumerables maneras, pero para la comunidad de datos creó un dolor de cabeza particular: nuevas fuentes que generaban datos a volúmenes y velocidades mucho mayores que antes.
Como Internet siguió creciendo y creciendo, la comunidad de software descubrió que las bases de datos relacionales de la época no podían manejar esta nueva carga. Hubo una perturbación en la fuerza, como si un millón de bases de datos gritaran y se sobrecargaran de repente.
Entonces dos nuevos gigantes de Internet hicieron avances, y desarrollaron sus propios sistemas distribuidos no relacionales para ayudar con esta nueva avalancha de datos: MapReduce (publicado en 2004) y Bigtable (publicado en 2006) de Google, y Dynamo (publicado en 2007) de Amazon. Estos documentos seminales dieron lugar a más bases de datos no relacionales, como Hadoop (basada en el documento MapReduce, 2006), Cassandra (muy inspirada en los documentos Bigtable y Dynamo, 2008) y MongoDB (2009). Al tratarse de nuevos sistemas escritos en gran parte desde cero, también evitaron el SQL, lo que dio lugar al surgimiento del movimiento NoSQL.
Y vaya si la comunidad de desarrolladores de software se tragó el NoSQL, adoptándolo posiblemente de forma mucho más amplia de lo que pretendían los autores originales de Google/Amazon. Es fácil entender por qué: NoSQL era nuevo y brillante; prometía escala y potencia; parecía el camino rápido hacia el éxito de la ingeniería. Pero entonces empezaron a aparecer los problemas.
Los desarrolladores pronto descubrieron que no tener SQL era en realidad bastante limitante. Cada base de datos NoSQL ofrecía su propio y único lenguaje de consulta, lo que significaba: más lenguajes que aprender (y que enseñar a tus compañeros de trabajo); una mayor dificultad para conectar estas bases de datos a las aplicaciones, lo que conducía a toneladas de frágil código de cola; la falta de un ecosistema de terceros, lo que obligaba a las empresas a desarrollar sus propias herramientas operativas y de visualización.
Estos lenguajes NoSQL, al ser nuevos, tampoco estaban completamente desarrollados. Por ejemplo, se había trabajado durante años en las bases de datos relacionales para añadir las características necesarias a SQL (por ejemplo, los JOINs); la inmadurez de los lenguajes NoSQL implicaba una mayor complejidad a nivel de aplicación. La falta de JOINs también condujo a la desnormalización, lo que llevó a la hinchazón y rigidez de los datos.
Algunas bases de datos NoSQL añadieron sus propios lenguajes de consulta «similares a SQL», como el CQL de Cassandra. Pero esto a menudo empeoró el problema. Utilizar una interfaz casi idéntica a algo más común en realidad creaba más fricción mental: los ingenieros no sabían qué era compatible y qué no.
Algunos en la comunidad vieron los problemas con NoSQL desde el principio (por ejemplo, DeWitt y Stonebraker en 2008). Con el tiempo, a través de las cicatrices duramente ganadas por la experiencia personal, más y más desarrolladores de software se unieron a ellos.
Parte 3: El retorno del SQL
Inicialmente seducida por el lado oscuro, la comunidad de software comenzó a ver la luz y a volver a SQL.
Primero llegaron las interfaces SQL sobre Hadoop (y más tarde, Spark), lo que llevó a la industria a «retrocronizar» NoSQL a «No sólo SQL» (sí, buen intento).
Luego llegó el auge de NewSQL: nuevas bases de datos escalables que abrazaban completamente SQL. H-Store (publicada en 2008) de investigadores del MIT y Brown fue una de las primeras bases de datos OLTP escalables. Google volvió a liderar el camino de las bases de datos georreplicadas con interfaz SQL con su primer trabajo Spanner (publicado en 2012) (entre cuyos autores se encuentran los autores originales de MapReduce), seguido de otros pioneros como CockroachDB (2014).
Al mismo tiempo, la comunidad de PostgreSQL comenzó a revivir, añadiendo mejoras críticas como un tipo de datos JSON (2012), y un popurrí de nuevas características en PostgreSQL 10 (mejor soporte nativo para el particionamiento y la replicación, soporte de búsqueda de texto completo para JSON, etc.) y PostgreSQL 11 (añadió capacidades de definición de datos en paralelo, introdujo la complilación justo a tiempo, etc.), con aún más por venir en PostgreSQL 12. Otras compañías como CitusDB (2016, ahora propiedad de Microsoft) y su servidor (TimescaleDB, lanzado en 2017 ) encontraron nuevas formas de escalar PostgreSQL para cargas de trabajo de datos especializados.
De hecho, nuestro viaje desarrollando TimescaleDB refleja estrechamente el camino que ha tomado la industria. Las primeras versiones internas de TimescaleDB contaban con nuestro propio lenguaje de consulta tipo SQL llamado «ioQL». Sí, nosotros también estuvimos tentados por el lado oscuro: construir nuestro propio lenguaje de consulta se sentía poderoso. Pero aunque parecía el camino más fácil, pronto nos dimos cuenta de que tendríamos que hacer mucho más trabajo: por ejemplo, decidir la sintaxis, construir varios conectores, educar a los usuarios, etc. También nos encontramos buscando constantemente la sintaxis adecuada a consultas que ya podíamos expresar en SQL, para un lenguaje de consulta que habíamos escrito nosotros mismos!
Un día nos dimos cuenta de que construir nuestro propio lenguaje de consulta no tenía sentido. Que la clave estaba en adoptar SQL. Y esa fue una de las mejores decisiones de diseño que hemos tomado. Inmediatamente se abrió todo un mundo nuevo. Apenas unos meses después de nuestro lanzamiento oficial en 2017, los usuarios pudieron utilizarnos en producción y obtener todo tipo de cosas maravillosas fuera de la caja: herramientas de visualización, conectores a ORM comunes, una variedad de herramientas y opciones de copia de seguridad, una abundancia de tutoriales y explicaciones de sintaxis en línea, etc.
Pero no tome nuestra palabra. Toma la de Google.
Está claro que Google lleva más de una década a la vanguardia de la ingeniería e infraestructura de datos. Nos corresponde prestar mucha atención a lo que están haciendo.
Echa un vistazo al segundo documento importante de Google sobre Spanner (Spanner: Becoming a SQL System, mayo de 2017), y verás que refuerza nuestros hallazgos independientes.
Por ejemplo, Google comenzó a construir sobre Bigtable, pero luego descubrió que la falta de SQL creaba problemas (el énfasis en todas las citas es nuestro):
«Aunque estos sistemas proporcionaban algunos de los beneficios de un sistema de base de datos, carecían de muchas características de bases de datos tradicionales en las que los desarrolladores de aplicaciones suelen confiar. Un ejemplo clave es un lenguaje de consulta robusto, lo que significa que los desarrolladores tenían que escribir código complejo para procesar y agregar los datos en sus aplicaciones. Como resultado, decidimos convertir Spanner en un sistema SQL completo, con la ejecución de consultas estrechamente integrada con las otras características arquitectónicas de Spanner (como la fuerte consistencia y la replicación global).»
Más adelante, en el documento, recogen los motivos de su transición de NoSQL a SQL:
La API original de Spanner proporcionaba métodos NoSQL para búsquedas puntuales y escaneos de rango de tablas individuales e intercaladas. Mientras que los métodos NoSQL proporcionaron un camino simple para lanzar Spanner, y continúan siendo útiles en escenarios de recuperación simples, SQL ha proporcionado un valor adicional significativo en la expresión de patrones de acceso a datos más complejos y empujando la computación a los datos.
El documento también describe cómo la adopción de SQL no se detiene en Spanner, sino que en realidad se extiende por el resto de Google, donde múltiples sistemas comparten hoy un dialecto SQL común:
El motor SQL de Spanner comparte un dialecto SQL común, llamado «Standard SQL», con varios otros sistemas en Google, incluyendo sistemas internos como F1 y Dremel (entre otros), y sistemas externos como BigQuery…
Para los usuarios dentro de Google, esto reduce la barrera de trabajo entre los sistemas. Un desarrollador o analista de datos que escribe SQL contra una base de datos de Spanner puede transferir su comprensión del lenguaje a Dremel sin preocuparse por las sutiles diferencias en la sintaxis, el manejo de NULL, etc.
El éxito de este enfoque habla por sí mismo. Spanner ya es la «fuente de la verdad» para los principales sistemas de Google, incluyendo AdWords y Google Play, mientras que «los clientes potenciales de la Nube están abrumadoramente interesados en usar SQL»
Considerando que Google ayudó a iniciar el movimiento NoSQL en primer lugar, es bastante notable que esté abrazando SQL hoy. (Lo que lleva a algunos a preguntarse: «¿Ha enviado Google a la industria de los Big Data a una falsa cabeza de 10 años?»)
Lo que esto significa para el futuro de los datos: SQL como interfaz universal
En las redes informáticas, existe un concepto llamado «cintura estrecha», que describe una interfaz universal.
Esta idea surgió para resolver un problema clave: en cualquier dispositivo en red, imagine una pila, con capas de hardware en la parte inferior y capas de software en la parte superior. Puede haber una gran variedad de hardware de red; del mismo modo, puede haber una gran variedad de software y aplicaciones. Se necesita una forma de garantizar que, independientemente del hardware, el software pueda seguir conectándose a la red; y que, independientemente del software, el hardware de red sepa cómo manejar las solicitudes de red.
En la red, el papel de la interfaz universal lo desempeña el Protocolo de Internet (IP), que actúa como capa de conexión entre los protocolos de red de nivel inferior diseñados para la red de área local, y los protocolos de aplicación y transporte de nivel superior. (Aquí hay una buena explicación.) Y (en una amplia simplificación), esta interfaz universal se convirtió en la lingua franca de los ordenadores, permitiendo que las redes se interconectaran, que los dispositivos se comunicaran y que esta «red de redes» creciera hasta convertirse en la rica y variada Internet de hoy.
Creemos que SQL se ha convertido en la interfaz universal para el análisis de datos.
Vivimos en una era en la que los datos se están convirtiendo en «el recurso más valioso del mundo». Como resultado, hemos visto una explosión cámbrica de bases de datos especializadas (OLAP, series temporales, documentos, gráficos, etc.), herramientas de procesamiento de datos (Hadoop, Spark, Flink), buses de datos (Kafka, RabbitMQ), etc. También tenemos más aplicaciones que necesitan apoyarse en esta infraestructura de datos, ya sean herramientas de visualización de datos de terceros (Tableau, Grafana, PowerBI, Superset), frameworks web (Rails, Django) o aplicaciones basadas en datos construidas a medida.
Al igual que las redes, tenemos una pila compleja, con la infraestructura en la parte inferior y las aplicaciones en la superior. Normalmente, acabamos escribiendo mucho código de cola para que esta pila funcione. Pero el código de cola puede ser frágil: necesita ser mantenido y atendido.
Lo que necesitamos es una interfaz que permita que las piezas de esta pila se comuniquen entre sí. Idealmente algo ya estandarizado en la industria. Algo que nos permita intercambiar varias capas con una fricción mínima.
Ese es el poder de SQL. Al igual que IP, SQL es una interfaz universal.
Pero SQL es de hecho mucho más que IP. Porque los datos también son analizados por humanos. Y fiel al propósito que los creadores de SQL le asignaron inicialmente, SQL es legible.
¿Es SQL perfecto? No, pero es el lenguaje que la mayoría de la comunidad conocemos. Y aunque ya hay ingenieros por ahí trabajando en una interfaz más orientada al lenguaje natural, ¿a qué se conectarán entonces esos sistemas? SQL.
Así que hay otra capa en la parte superior de la pila. Y esa capa somos nosotros.
SQL ha vuelto
SQL ha vuelto. No sólo porque escribir código para unir herramientas NoSQL es molesto. No sólo porque volver a entrenar a las fuerzas de trabajo para aprender una miríada de nuevos lenguajes es difícil. No sólo porque los estándares pueden ser algo bueno.
Sino también porque el mundo está lleno de datos. Nos rodea, nos une. Al principio, confiábamos en nuestros sentidos humanos y sistemas nerviosos sensoriales para procesarlos. Ahora nuestros sistemas de software y hardware también se están volviendo suficientemente inteligentes para ayudarnos. Y a medida que recopilamos más y más datos para dar un mejor sentido a nuestro mundo, la complejidad de nuestros sistemas para almacenar, procesar, analizar y visualizar esos datos sólo seguirá creciendo también.
O podemos vivir en un mundo de sistemas frágiles y un millón de interfaces. O podemos seguir abrazando el SQL. Y restaurar el equilibrio de la fuerza.
¿Te gusta este post y estás interesado en saber más?
Consulta nuestro GitHub, únete a nuestra comunidad de Slack y apúntate a la lista de correo de la comunidad que aparece más abajo. ¡También estamos contratando!
Lectura sugerida para aquellos que quieran aprender más sobre la historia de las bases de datos (también conocido como programa de estudios para la futura clase de introducción a las bases de datos de TimescaleDB):
- Un modelo relacional de datos para grandes bancos de datos compartidos (IBM Research, 1970)
- SEQUEL: un lenguaje de consulta estructurado en inglés (IBM Research, 1974)
- Sistema R: enfoque relacional para la gestión de bases de datos (IBM Research, 1976)
- MapReduce: Simplified Data Processing on Large Clusters (Google, 2004)
- C-Store: A Column-oriented DBMS (MIT, otros, 2005)
- Bigtable: A Distributed Storage System for Structured Data (Google, 2006)
- Dynamo: Highly Available Key-value Store de Amazon (Amazon, 2007)
- MapReduce: Un gran paso atrás (DeWitt, Stonebreaker, 2008)
- H-Store: A High-Performance, Distributed Main Memory Transaction Processing System (MIT, Brown, otros, 2008)
- Spark: Cluster Computing with Working Sets (UC Berkeley, 2010)
- Spanner: Google’s Globally-Distributed Database (Google, 2012)
- Early History of SQL (Chamberlin, 2012)
- How the Internet was Born (Hines, 2015)
- Spanner: Convirtiéndose en un sistema SQL (Google, 2017)